DEV Community: Wiktor Małyska

Running VS Code end-to-end tests on a Windows desktop nobody can see

Wiktor Małyska — Wed, 11 Nov 2026 09:00:00 +0000

My end-to-end tests press Ctrl+S in real VS Code windows. That can't happen on the screen I'm working on.

The extension under test is Virga, which runs Apex and SOQL scratches against an org with Ctrl+S and lets you close them without a "save changes?" dialog. Most of what can go wrong in it lives in VS Code itself: auto save, the dirty state of a tab, native dialogs, keymaps that also want Ctrl+S, tabs that come back after a restart. A fake of the VS Code API can imitate those, and Virga's unit tests do. At some point, though, you have to check the real thing, and that means real VS Code windows.

This post is about how Virga's end-to-end suite runs 221 checks in six VS Code sessions on a Windows desktop that is never shown.

Why not the official test runner

The usual way to test an extension is to start VS Code with --extensionTestsPath. Virga's suite deliberately doesn't. In extension test mode, VS Code answers its own "save changes?" dialog with "Don't Save" without ever showing it. For most extensions that's convenient. For Virga that dialog is the bug the tests exist to catch, so the suite starts VS Code as a normal application and drives it from outside.

A desktop nobody looks at

Windows has supported several desktops per window station for a long time. The one you see is called Default. CreateDesktop makes another, and a process started with that desktop's name in STARTUPINFO.lpDesktop puts its windows there. Child processes inherit it. Nothing on that desktop is ever displayed, so nothing there can take the focus.

The launcher, e2e/hidden-desktop.ps1, compiles a few lines of C# with Add-Type. Condensed, with the error handling left out:

IntPtr desktop = CreateDesktopW(desktopName, IntPtr.Zero, IntPtr.Zero, 0, GENERIC_ALL, IntPtr.Zero);
var si = new STARTUPINFO();
si.cb = Marshal.SizeOf(typeof(STARTUPINFO));
si.lpDesktop = desktopName;
PROCESS_INFORMATION pi;
CreateProcessW(null, new StringBuilder(commandLine), IntPtr.Zero, IntPtr.Zero, false,
    CREATE_NO_WINDOW, IntPtr.Zero, cwd, ref si, out pi);
WaitForSingleObject(pi.hProcess, (uint)timeoutMs);

On a timeout it kills the whole process tree with taskkill /T /F, so no VS Code is left running on a desktop I can't see.

Before anything else starts, the launcher runs a self-test. It starts a small PowerShell child on the hidden desktop that asks Windows which desktop its own thread is on (GetThreadDesktop plus GetUserObjectInformation) and writes the name to a file. If that name isn't the hidden desktop's, the run stops there and no VS Code is started. I wanted that guarantee checked every run instead of assumed.

The whole suite is started through it:

& $launcher -WorkingDirectory $root -CommandLine $cmd

where $cmd runs node e2e\run-e2e.mjs with its output going to a log file. npm run e2e does all of this.

An isolated VS Code

run-e2e.mjs starts VS Code with its own --user-data-dir and --extensions-dir under e2e/, so my own profile and extensions are never touched. Virga is loaded from the source folder, or installed from the packaged .vsix for npm run e2e:vsix. Helper extensions come along: one that registers the apex, apex-anon and soql language ids without language servers, a driver that runs the suite inside the window and quits, and in some passes stand-ins for other extensions.

The suite can use a copy of VS Code in e2e/vsc/, so a pending update of the installed one is never in the way. A copy has a few traps:

Every VS Code start registers its urlProtocol as the Windows handler for vscode:// links. A copy has to get its own in product.json, or a sign-in callback could open the test copy with your real profile.
It also needs its own win32MutexName, or a pending update of the installed VS Code keeps it from starting.
A copy in a path longer than 260 characters can't load the tokenizer worker, so the test profile sets editor.experimental.asyncTokenization to false.

The base profile also sets window.dialogStyle to native and files.hotExit to off, so closing a window with a dirty file really asks, and only Virga's auto save can keep it from asking.

Keys through the DevTools protocol

VS Code is an Electron app, so with --remote-debugging-port it speaks the Chrome DevTools protocol. The suite connects to the workbench page and sends input the way a keyboard would (condensed):

const base = { modifiers: k.modifiers, key: k.key, code: k.code,
               windowsVirtualKeyCode: k.vk, nativeVirtualKeyCode: k.vk };
await s.send('Input.dispatchKeyEvent', { type: 'rawKeyDown', ...base });
await s.send('Input.dispatchKeyEvent', { type: 'keyUp', ...base });
// typed text
await s.send('Input.insertText', { text: step.text });

It also turns on Emulation.setFocusEmulationEnabled, so the page behaves as focused even though nobody is looking at it.

Going through the real input path matters. A command called directly from a test would skip the keymap. With key events, VS Code's own keybinding resolution decides what Ctrl+S does, which is exactly what I needed for the IntelliJ IDEA keymap, where Ctrl+S is Save All.

Catching dialogs instead of hanging on them

A native dialog on a hidden desktop would block the run forever. e2e/dialog-watch.ps1 polls EnumWindows every 50 ms for windows of class #32770, the native message box, that belong to the VS Code under test: a process started from the test executable whose parent is the test runner. A VS Code you have open yourself is never touched. Each dialog is logged as one JSON line with its title and buttons, then dismissed ("Don't Save", else Cancel, else its first button).

EnumWindows only sees the desktop the watcher itself runs on. That works out, because the watcher is started by the runner and inherits the hidden desktop.

The passes check that the dialog log stayed empty, so a "save changes?" anywhere fails the run.

Six runs, 221 checks

The suite starts VS Code six times:

Default keymap: the whole suite.
IntelliJ IDEA keymap: the key checks again, with Ctrl+S as Save All.
Restart, run A: three scratches open in two editor groups, one in a background tab, one as a preview tab, then VS Code quits. The runner then deletes the file of the scratch that was in front.
Restart, run B: VS Code starts again and restores those tabs.
Two windows, run A: the same project in two windows, with a Reload Window in one while the other closes a scratch.
Two windows, run B: the folder again, then a .code-workspace with it.

The last full run took 212 seconds from source and 317 seconds against the .vsix. The log reads like a list of claims. An excerpt:

ok   (4) that run had the text shown at Ctrl+S and nothing typed after it
ok   (4) every key typed after Ctrl+S is still in the editor, the 14 spaces too (no save participant trimmed them)
ok   [IntelliJ keymap] (f) Ctrl+S in a plain file saved every dirty file (Save All: the keymap is active)
ok   no VS Code dialog appeared during the whole run, closing the window included

221 passed, 0 failed; 6 VS Code run(s); 212 s

Two bugs worth the setup

The first Ctrl+S of a window. The first time VS Code dispatches a contributed command, it resolves the command's activation event with a round trip to the extension host. Keys typed meanwhile reach the document before the command does, so the first Ctrl+S could run a script that already included a key typed right after it. Virga now runs the command once at activation, as a no-op, so the event is resolved up front. The (4) checks above press Ctrl+S and keep typing, then compare what ran with what was on screen.

Restored tabs with missing files. After a restart, VS Code restored scratch tabs whose files were already gone, and other tools working on open files reported a file that "does not exist". Virga now closes restored scratch tabs at startup. Runs 3 and 4 reproduce exactly that situation, including a stand-in extension that reads files late, the way a code analyzer reading on open does.

Where the unit tests fit

Most of Virga's logic lives in two lib.js files that don't import vscode. They're tested in plain Node, together with a fake of the VS Code API (test/fake-vscode.js) that copies the behavior the extension depends on: auto save as a debounce, a short auto save counting as "being saved", failed saves, the "save changes?" prompt, restored tabs before activation, several windows on one project. CI on Ubuntu runs those tests and packages the extension on every push. The end-to-end suite is Windows only, and it's on the release checklist, against the source and against the packaged .vsix.

If you want to borrow it

Everything is in the Virga repository under MIT: e2e/hidden-desktop.ps1, e2e/dialog-watch.ps1 and e2e/run-e2e.mjs. The hidden desktop part is Windows-specific. On Linux, a virtual X server does a similar job.

Repository: github.com/wiktormalyska/virga
Extension: VS Code Marketplace and Open VSX

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

How a raw List in an @InvocableMethod breaks Apex completion, measured on 274 signatures

Wiktor Małyska — Fri, 30 Oct 2026 09:00:00 +0000

I was writing an @InvocableMethod, hadn't typed the parameter's element type yet, and member completion stopped working in the whole class. Typing r. on a variable gave me nothing, in every method. The Problems panel showed a syntax error and nothing else.

The cause is a crash inside the Apex language server, and the server never tells you about it. This post explains what happens, how I measured which signatures trigger it, and what my VS Code extension Virga now does about it.

Reproducing it

Put this in a class in a project with the Salesforce Extension Pack installed:

public with sharing class OrderIntake {
    @InvocableMethod(label='Take orders' description='Accepts or rejects each order.')
    public static List<Result> take(List requests) {
        List<Result> results = new List<Result>();
        return results;
    }

    public static void probe() {
        Request r = new Request();
        r.
    }

    public class Request {
        @InvocableVariable(required=true) public String orderNumber;
    }

    public class Result {
        @InvocableVariable public Boolean accepted;
    }
}

Ask for completion after r. in probe(). With the raw List in take, the language server returns no members. With List<Request> requests they come back. Completion after r. on a local variable whose type is an inner class is also the test I used for every measured shape below. Note that the broken signature and the method where completion fails don't have to be the same method.

What happens inside the language server

The Apex language server in the Extension Pack is called jorje. It runs extra semantic checks on methods marked @InvocableMethod, static @AuraEnabled, @HttpGet / @HttpPost and the other @Http* annotations, webservice and global. Those checks unwrap the element types of collection parameters, and which collections they unwrap depends on the method: List (two levels deep) in an @InvocableMethod, List in a webservice method, List and Map in static @AuraEnabled and @Http* methods, and List, Set and Map in global methods.

A raw List has no type argument, so the unwrap gets an empty list where it expects exactly one element. In the server's log it looks like this:

java.lang.IllegalArgumentException: Expected list of size 1 but was: []
    at apex.common.collect.MoreIterables.getOnlyElement(MoreIterables.java:186)
    at apex.jorje.semantic.symbol.type.common.CollectionTypeInfoUtil.getElementType(CollectionTypeInfoUtil.java:44)
    at apex.jorje.semantic.ast.modifier.rule.InvocableContextRule.isAtMostTwoNestedLists(InvocableContextRule.java:134)

The server logs the exception and goes on. The file, though, is left without resolved types, and completion after . returns nothing anywhere in it until the signature is fixed. The same happens with List<>, with an unfinished List<Req directly followed by ), and with the wrong number of type arguments, such as List<String, String>.

There is a second, separate mechanism in the parser. A raw collection as a return type (List check(...), List<>, List<List>) makes the parser drop the whole method. So does a parameter cut off right after < or a comma, like List<). That one is local: only completion inside that method is gone.

Measuring instead of guessing

The obvious rule would be to flag every raw collection in a signature. That rule would be wrong in a lot of places. A raw List in a plain public static method is just a syntax error: the server reports it and completion keeps working. A check that fires on harmless code teaches people to ignore it.

So before writing any rule, I measured. I took the language server jar from the extension (salesforcedx-vscode-apex 67.26), started it headless with the same flags VS Code uses, and talked to it over the language server protocol. For each signature I sent the class with that signature as a change to the document, then asked for completion after r. on a local variable whose type is an inner class. Two things were recorded per shape: whether the server logged an exception, and whether that completion came back empty.

That ran over 274 signatures. Some results surprised me:

Signature shape	Where	Result
`List requests`	`@InvocableMethod`	crash, whole file
`List<List> requests`	`@InvocableMethod`	crash, whole file
`List<List<List>> requests`	`@InvocableMethod`	clean
`Set requests`, `Map requests`	`@InvocableMethod`	clean
`List<Request requests` (no `>`)	`@InvocableMethod`	clean, the parser inserts the `>`
`List<Request) {`	`@InvocableMethod`	crash, whole file
`Map requests`, `Map<String> requests`	static `@AuraEnabled`	crash, whole file
`Set requests`	`global` method	crash, whole file
`List< > requests` (with a space)	any method	crash, whole file
`List requests`	plain method	clean, only a syntax error
`List check(...)` as return type	any method	method dropped

The List<List<List>> row fits the stack trace: the rule is called isAtMostTwoNestedLists, and in the measurement it unwrapped two levels and no more. And List< > with a space is different from List<> written together, because jorje reads <> as a single token, while < > leaves an empty argument slot, which breaks type resolution in any method at all.

What Virga does with it

Virga flags exactly the shapes that broke in the measurement and stays quiet about the ones that measured clean, even when they are syntax errors. The diagnostic has source virga and one of two codes: jorje-crash when completion is gone in the whole file, jorje-parse when only that method is affected. The message names the cause:

Raw List in an @InvocableMethod parameter. The Apex language server crashes on it
and stops suggesting members after '.' in this file. Use List<Type>.

Diagnostics appear 400 ms after you stop typing, cover .cls files only, and skip anonymous Apex and the generated copies under .sfdx/.

The quick fix (Ctrl+.) inserts the type and picks it from the file:

in an @InvocableMethod parameter, an inner class with @InvocableVariable fields, Request- or Input-style names first;
in an @AuraEnabled parameter, a class with @AuraEnabled fields;
in a return type, the output class (Response, Result or Output), even an empty one;
otherwise List<String> or Map<String, Object>, and the title says why.

It completes an unfinished List<Req, names a parameter that has no name, and adds a missing ):

// before
@InvocableMethod
public static void check(List) {
// after the quick fix
@InvocableMethod
public static void check(List<Request> requests) {

Only the type is replaced, so comments and line breaks inside the signature stay where they are. A fix is marked preferred only when the choice is unambiguous. When more than one class fits, you get more than one fix:

requests" and "Change to List requests"" width="800" height="468">

Virga's checks agree with the measurement in all 274 signatures. Then I applied the quick fixes and ran the breaking cases again: the server threw in none of the 184, and completion after . came back in 180 of the 181 where it had been empty. The one left over is @InvocableMethod on an interface method, which the parser rejects anyway.

What I took from it

When a language server goes silent, its log usually knows why. The syntax error in Problems was true but beside the point. The stack trace named the exact rule.

The other lesson was to measure before writing a lint rule. A rule that looked reasonable on paper would have flagged Set and Map in invocable methods, which are fine, and missed List< > in ordinary methods, which isn't.

Virga is free and MIT licensed: VS Code Marketplace, Open VSX, source on GitHub. The measured shapes are listed in the README, and the unit tests in test/local-types.test.js pin both the breaking and the clean ones.

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

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)