DEV Community: Wiktor Małyska

Virga: run anonymous Apex and SOQL from a VS Code tab with Ctrl+S

Wiktor Małyska — Tue, 20 Oct 2026 08:00:00 +0000

Most of the Apex I run by hand is throwaway. A few lines to check a query, a System.debug to see what a method returns, a quick look at some records. I wanted that to be one key press in VS Code, with the result readable at a glance and nothing left behind in the project afterwards.

So I built Virga, a free, MIT-licensed VS Code extension for Apex developers, and the first version is out. This post covers what it does and a few decisions behind it.

Install

VS Code: Visual Studio Marketplace, or code --install-extension WiktorMayska.virga
Cursor, VSCodium, Windsurf and other Open VSX editors: Open VSX
Any VS Code build: the .vsix from GitHub Releases, then Extensions: Install from VSIX...

You need VS Code 1.90 or newer, the Salesforce CLI (sf) on your PATH with an authorized org set as the project's default, and a Salesforce DX project. The Salesforce Extension Pack is recommended. It brings highlighting and the language servers that work inside scratches, and the local type completion, the signature checks and the snippets attach to its apex language, so those three need it. Scratches run without it, which is why Virga doesn't declare the pack as a dependency.

A scratch, from click to result

In a folder with sfdx-project.json, Virga adds two buttons to the status bar: ▷ Apex and SOQL. Each click opens a new tab (scratch-1.apex, scratch-2.apex, scratch-1.soql, ...). The script in the screenshot above is this:

List<Account> accounts = [
    SELECT Id, Name, Industry FROM Account
    WHERE Industry != null ORDER BY Name LIMIT 3
];
System.debug(accounts.size() + ' accounts with an industry');
for (Account a : accounts) {
    System.debug(LoggingLevel.INFO, a);
}
System.debug(LoggingLevel.WARN, Limits.getQueries() + ' of 100 queries used');

Press Ctrl+S (Cmd+S on macOS). An .apex scratch goes to sf apex run, a .soql scratch to sf data query. The org is the one sf itself would pick: the SF_TARGET_ORG environment variable, then target-org in the project's .sf/config.json, then your global config. Virga passes it to sf as --target-org, so the header of every result names the org the code really ran in.

The result goes to the Virga output channel. For Apex that means ✔ Compiled ✔ Executed, every debug line with its line number and log level, and the limits the run used. When something goes wrong, the output points at it. Here is a run that divides by zero:

System.debug('before');
Integer z = 0;
Integer i = 1 / z;

✔ Compiled  ✖ Exception: System.MathException: Divide by 0
  at AnonymousBlock: line 3, column 1

  3 │ Integer i = 1 / z;
    │ ^

  [line 1] DEBUG  before

  Limits  SOQL queries 0/100 · query rows 0/50000 · DML statements 0/150 · DML rows 0/10000
          CPU time 0/10000 ms · heap 0/10000000 bytes

A SOQL scratch prints the record count and a table. Relationship fields are flattened to dotted names, subqueries show as [2 rows], and long values are cut with …:

SELECT Id, Name, Account.Name, Account.Owner.Name, Email FROM Contact ORDER BY Name LIMIT 4

✔ 4 records
┌────────────────────┬──────────────┬────────────────────────┬────────────────────┬───────────────────────┐
│ Id                 │ Name         │ Account.Name           │ Account.Owner.Name │ Email                 │
├────────────────────┼──────────────┼────────────────────────┼────────────────────┼───────────────────────┤
│ 003Dm0000AbC011AAA │ Andy Young   │ Dickenson plc          │ OrgFarm EPIC       │ a_young@exampleco.com │
│ 003Dm0000AbC013AAA │ Arthur Song  │ United Oil & Gas Corp. │ OrgFarm EPIC       │ asong@abc.com         │
│ 003Dm0000AbC015AAA │ Ashley James │ United Oil & Gas, UK   │ OrgFarm EPIC       │ ajames@abc.com        │
│ 003Dm0000AbC017AAA │ Avi Green    │ United Oil & Gas Corp. │ OrgFarm EPIC       │ agreen@abc.com        │
└────────────────────┴──────────────┴────────────────────────┴────────────────────┴───────────────────────┘

Columns come from the SELECT list as well as from the records, so a relationship that is null in every row still keeps its own dotted columns.

What runs is what you see

A run uses exactly the text in the editor at the moment of Ctrl+S. Virga writes a copy of it to a temporary folder and hands that to sf, never the scratch file itself and never on the command line. Keys you type after Ctrl+S are not part of that run.

Saving never runs a scratch. Auto save doesn't, and Save All from another file doesn't either. Only Ctrl+S in the scratch, the ▶ button in its editor title, or Virga: Run Scratch does. A second Ctrl+S during a run is queued, and a newer Ctrl+S in the same tab replaces the queued text.

Closing without "save changes?"

Closing a scratch tab discards it, with no dialog. The trick behind it is small. Virga sets a short auto save, afterDelay with 100 ms, as the language default for apex-anon and soql. With a delay that short, VS Code treats the document as being saved: no dirty dot on the tab, and closing it never asks. If a background save fails because something else has the file locked, Virga keeps retrying it, with a pause that grows up to 5 seconds, until it goes through.

Since the run uses its own copy, a run saves nothing, and no format on save or whitespace trimming ever happens because of Ctrl+S.

The cost is that VS Code lets an extension set this default only per language, so other apex-anon files (for example scripts/apex/hello.apex) save themselves 100 ms after a change too. Classes and triggers are not affected. To switch it off:

{
  "[apex-anon]": { "files.autoSave": "off" },
  "[soql]": { "files.autoSave": "off" }
}

With that, closing a scratch with unsaved text asks again. Whatever you answer, the scratch file is deleted.

A scratch is a real file in .sfdx/virga-scratch/, which Salesforce DX projects already ignore in git. The language servers of the Extension Pack therefore complete and underline it like any other file. Tabs that VS Code restores after a restart are closed at startup, and two windows on the same project never delete each other's scratches.

If you use the IntelliJ IDEA keymap extension, where Ctrl+S is Save All, Virga's Ctrl+S still wins inside scratch editors, and only there.

Three smaller things for regular Apex files

Completion for types declared in the same file. The Apex language server doesn't offer an inner class, interface or enum by its simple name, even when it's declared a few lines below. Virga adds the types declared in the current file, inner ones at any depth, with a detail such as inner class of OrderIntake. It stays out of the way after a dot, in comments and strings, after @, and inside inline SOQL.

Signatures that break completion. A raw List in an @InvocableMethod parameter (and a few related shapes) makes the language server throw internally and stop suggesting members after . in the whole file. All you see is a syntax error. Virga marks the real cause and offers a quick fix that types the collection from the classes in your file. I measured which shapes do this on 274 signatures, and I'll write that up in a separate post.

Snippets the Extension Pack doesn't have. Annotations (type @, then Inv, and get InvocableMethod(...)), keywords and modifiers such as return, else if and with sharing, DML statements, and user mode: insert as user, Database.queryWithBinds with AccessLevel.USER_MODE, WITH USER_MODE. No Virga prefix is one the pack already uses, so a suggestion list never shows the same name twice.

Privacy

Virga has no telemetry and no network code. Runs call your local sf against the org you chose. sf has usage telemetry of its own, so Virga starts every run with SF_DISABLE_TELEMETRY=true. To turn it off for your own sf commands too:

sf config set disable-telemetry true --global

Why "Virga"

Virga is rain that evaporates before it reaches the ground. The code you try in a scratch never lands in your project either.

Feedback and contributions

The code is at github.com/wiktormalyska/virga. It has no runtime dependencies and no build step, and npm test runs the unit tests in plain Node. Issues and small pull requests with a test are welcome. If something behaves differently on your setup than described here, an issue with the Virga output attached helps most.

Salesforce, Apex and related marks are trademarks of Salesforce, Inc. Virga is an independent project and is not affiliated with or endorsed by Salesforce.

node --test only learned about globs in Node 21

Wiktor Małyska — Tue, 01 Sep 2026 13:00:00 +0000

My package declares support for Node 18 and up. Its own test suite could not run on two of the three versions I claimed to support. Everything passed on my machine.

The script

{
  "scripts": {
    "test": "node --test \"test/**/*.test.mjs\""
  },
  "engines": { "node": ">=18" }
}

That looks fine. It is quoted, so the shell does not expand it, which is what you want when a tool does its own glob handling. On my Node 22 it ran 35 tests and went green.

What CI said

The workflow was nine jobs: Ubuntu, Windows and macOS across Node 18, 20 and 22.

Could not find '/home/runner/work/pkg/pkg/test/**/*.test.mjs'
> node --test "test/**/*.test.mjs"
Error: Process completed with exit code 1

macOS 22 green. Ubuntu 18 red. Windows 20 red. The pattern was not the operating system, it was the Node version.

Why

Glob expansion in the Node test runner arrived in Node 21. Before that, a path argument is treated as a literal path. So on 18 and 20 the runner looks for a directory literally named **, does not find it, and dies before a single test executes.

It never even reached the tests. The suite was not failing; it was not running.

The fix

{
  "scripts": {
    "test": "node --test"
  }
}

With no path argument, the runner discovers test files itself using its default patterns, which include **/*.test.mjs and anything under a test/ directory. That behaviour has been there since Node 18, and it does not depend on the shell, so it works the same on Windows.

Same 35 tests, now on all nine jobs.

The part worth keeping

This is the entire argument for a build matrix, and it is not thoroughness for its own sake.

"Works on my machine" is a true statement about exactly one row of that matrix. I had declared support for a range I had never once executed. The matrix did not find a rare edge case; it found that two thirds of my stated support was fiction, about ninety seconds after I pushed the workflow.

If your package declares an engines range, run your tests across that range. Otherwise the range is a guess you are asking your users to verify for you.

https://github.com/wiktormalyska/mcp-secrets-runner

1Password's secret masking silently corrupts MCP servers

Wiktor Małyska — Sun, 30 Aug 2026 13:00:01 +0000

I added 1Password support to an MCP secrets runner and the first thing I had to do was turn one of its security features off. Here is why that was the right call.

What op run does

1Password's CLI resolves op:// references and hands the values to a child process:

op run --env-file=./mcp.env -- npx -y @stripe/mcp@latest

It also does something thoughtful on top. It watches the child's output and rewrites anything matching a resolved secret to <concealed by 1Password>. If your program accidentally logs a token, or you are screen sharing, the secret does not leave the machine.

For a normal CLI this is a good default. I would keep it on.

What an MCP server is

An MCP server on the stdio transport speaks JSON-RPC over stdout. Not log lines. A framed protocol stream, where the client parses every byte:

{"jsonrpc":"2.0","id":1,"result":{"tools":[...]}}

stdout is not a place for human-readable output. It is a wire.

The collision

Put those two together. Masking rewrites bytes in a stream that a parser is reading with exact expectations. If a secret value ever appears inside a frame, the frame changes length, and the parse fails.

What makes this genuinely nasty is where it fails. The MCP client reports a protocol error. Nothing in that error mentions 1Password, masking, or secrets. You would go and read your server's serialisation code, which is fine, for a long time.

So the provider passes --no-masking by default, and the README says why in as many words. There is an opt-in flag to turn masking back on for servers that do not use stdio.

The general shape

What I find worth writing down is that nothing here is a bug. Not in 1Password, not in MCP, not in my code.

A security feature assumes it may rewrite a child's output. A wire protocol assumes it owns stdout exclusively. Both assumptions are reasonable in isolation. The failure lives in the space between them, and it is silent, because neither component is in a position to notice the other exists.

Every integration you write has a few of these. They do not show up in either project's issue tracker, because from each side nothing is wrong. They show up in yours.

The practical takeaway: when you wrap a process that speaks a protocol on stdout, audit everything in the chain for the assumption that stdout is for humans. Log prefixes, colour codes, progress bars, and yes, secret masking.

https://www.npmjs.com/package/mcp-secrets-runner

Your .mcp.json probably has a live API key in it

Wiktor Małyska — Fri, 28 Aug 2026 13:00:00 +0000

Nearly every guide to setting up an MCP server tells you to do this:

{
  "mcpServers": {
    "stripe": {
      "command": "npx",
      "args": ["-y", "@stripe/mcp@latest"],
      "env": { "STRIPE_SECRET_KEY": "sk_live_51J..." }
    }
  }
}

That is a live production key sitting in a file that gets committed to repositories, synced between machines, screenshotted for tutorials and pasted into bug reports. I have seen sk_live_ keys in all four.

It is also, in my experience, the single biggest reason MCP stalls at a company's security review. Not the protocol. Not the tooling. The config file.

The obvious fix has its own failure mode

So you wrap the server in your secret manager's CLI instead:

"args": ["run", "--env=prod", "--", "npx", "-y", "@stripe/mcp@latest"]

Better. The key is gone from the file. But those CLIs authenticate with a developer session stored in your OS keyring, and that session expires.

When it does, every MCP server wrapped this way stops starting at the same moment. And the error surfaces in your MCP client, which knows nothing about secret managers or expired logins. You get a generic startup failure on ten servers at once and go looking in entirely the wrong place.

I lost an afternoon to this before the pattern clicked.

Machine identities do not expire

Every serious secret manager has a concept for unattended access: a credential meant for machines rather than humans, with no TTL of its own. Infisical calls it a machine identity, 1Password calls it a service account, Vault calls it AppRole.

The credential is long-lived; what it produces is short-lived. You exchange it for a token at process start, use the token, and never think about it again.

That is the whole idea behind mcp-secrets-runner. It sits between the MCP client and the server, authenticates with a machine credential, fetches the secrets and execs the real server:

{
  "mcpServers": {
    "stripe": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "mcp-secrets-runner", "--env=prod", "--path=/mcp",
               "--", "npx", "-y", "@stripe/mcp@latest"]
    }
  }
}

No secret values in the file. No session to renew. The same config works on every machine that has the machine credentials in its environment, which is what makes it safe to commit.

Three backends, three different shapes

The interesting part of building this was that the three supported backends work nothing alike:

Infisical mints a token over HTTPS, then hands off to the Infisical CLI.
1Password hands off to op run, which authenticates itself.
Vault reads the secret over the HTTP API and starts your MCP server directly, with no CLI involved at all.

A provider only has to answer one question: which child process do I start, and what environment does it get. That the three answers look so different is the best evidence I have that the interface is not overfitted to the first one I wrote.

When it does not work

"My MCP server won't start" is almost always one of four things, and an MCP client reports all four identically. So there is a doctor:

$ mcp-secrets-runner doctor --provider=vault

mcp-secrets-runner doctor (provider: vault)

  [ok  ] Node 22.14.0
  [ok  ] instance
         http://127.0.0.1:8200
  [ok  ] AppRole credentials present
  [ok  ] cached token available
  [ok  ] authentication succeeded
         token valid for 20 min

All checks passed.

Missing CLI, missing credentials, wrong instance URL, unreadable secret path. One line each, instead of one opaque failure.

Two details worth stealing

All diagnostics go to stderr. stdout belongs to the MCP protocol. One stray byte there corrupts the JSON-RPC stream and the client reports a parse error pointing nowhere useful.

It fails closed. If credentials are set but authentication fails, the runner exits. The alternative is worse than it sounds: a credential-less CLI invocation opens an interactive browser login, which hangs the MCP server on stdin forever while the client waits.

MIT, zero dependencies, Node 18+.

https://github.com/wiktormalyska/mcp-secrets-runner

Stop Hardcoding Your Portfolio Projects. I Built an API to Turn GitHub into a Headless CMS

Wiktor Małyska — Sun, 22 Mar 2026 13:27:32 +0000

Every time I finished a new side project, I faced the exact same annoying routine:

Open my portfolio repository.
Find the projects.json or hardcoded array.
Manually type in the new project name, description, and tech stack.
Download a screenshot, put it in the public folder, and link it.
Push changes and wait for the deployment.

As developers, we automate everything, yet we still update our portfolios like it's 2010. I got tired of this, so I built a solution: PortfolioAPI.

What is PortfolioAPI?

It’s a simple tool that turns your GitHub repositories into a Headless CMS for your portfolio. Instead of manually updating your frontend code, your portfolio fetches data directly from your GitHub repos via one fast API call.

Live Link: PortfolioAPI

How it works (It takes 2 minutes)

Step 1: Drop a meta.json in your repo
You just create a meta.json file in the root of any public GitHub repository you want to showcase.

{
  "name": "My Awesome Project",
  "description": "A short description shown on the portfolio page.",
  "imageUrl": "[https://raw.githubusercontent.com/your-username/your-repo/main/assets/screenshot.png](https://raw.githubusercontent.com/your-username/your-repo/main/assets/screenshot.png)",
  "websiteUrl": "[https://my-project.example.com](https://my-project.example.com)",
  "technologies": [
    "React",
    "TypeScript",
    "TailwindCSS"
  ]
}

Step 2: Fetch the data in your frontend
Make a single GET request using your API key. The API scans your GitHub, finds all repos with a meta.json, and returns a clean, structured array of your projects.

const fetchProjects = async () => {
  const response = await fetch('[https://api.portfolioapi.wiktormalyska.ovh/projects](https://api.portfolioapi.wiktormalyska.ovh/projects)', {
    headers: {
      'X-API-KEY': 'your_api_key_here'
    }
  });
  const data = await response.json();
  return data; // Boom! Ready to map over in React/Vue/Svelte
};

Why did I build it this way?

Zero Database Needed: Your code lives on GitHub anyway, why not keep its metadata there too?
Always Up to Date: Update the meta.json in your project repo, and your portfolio updates instantly.
Blazing Fast: I implemented server-side caching so the GitHub data is delivered in milliseconds. No unnecessary noise.
Tech Agnostic: It doesn't matter if your portfolio is built in React, Vue, Next.js, or vanilla HTML. It’s just a standard REST API.

What's next?

Right now, the API handles reading GitHub portfolios perfectly. I'm currently working on adding a dedicated Node.js package and an email contact form endpoint to make it an all-in-one backend for developer portfolios.

I’m an indie developer trying to build tools that actually save time. I’d love to hear your feedback. What do you think about managing portfolio content directly from GitHub repos?

Let me know in the comments! 👇

Psst... with code FREETRIAL you can get first month for free! (for first 10 customers)