open-in-app: "Open in VS Code" always fails on Windows — ELECTRON_RUN_AS_NODE leaks into the launcher environment

[DCSWLYH]

open-in-app: "Open in VS Code" always fails on Windows — ELECTRON_RUN_AS_NODE leaks into the launcher's environment

Summary

In the DSH desktop app on Windows, the Open In menu lists VS Code correctly, but picking it always shows "Could not open. Try again." (path.openError).

The root cause is an environment-variable leak: the desktop shell runs the host as a child Electron process with ELECTRON_RUN_AS_NODE=1, and launchDetachedApp() in @deepseek-ai/dsh-host-open-in-app forwards that variable to the launched application. Electron-based targets (VS Code, Cursor, Windsurf, GitHub Desktop, …) therefore start in Node mode, interpret the workspace directory as an entry script, and exit non-zero inside the launch watch window. The route classifies that as failed, so the client shows the generic error.

Explorer, Windows Terminal, Git Bash, and the JetBrains IDEs (JVM) are unaffected — the bug only hits Electron-based launchers.

Environment

DSH desktop	0.2.0-rc.2 (@deepseek-ai/dsh-desktop 0.2.0-rc.2)
Involved host package	@deepseek-ai/dsh-host-open-in-app 0.2.0-rc.2
Platform	Windows 11 (build 26200), x64
Electron / Node in the app	Electron 44.0.0 / Node 24.18.1
Target app	Visual Studio Code 1.136.1, installed at D:\Microsoft VS Code
Target resolution	HKCU App Paths\Code.exe → D:\Microsoft VS Code\Code.exe (resolves fine, the app appears in the menu)

Steps to reproduce

1. Open a workspace in the DSH desktop app on Windows.
2. Use the Open In control in the header (the split button listing File Explorer / VS Code / PyCharm).
3. Choose VS Code.

Expected

VS Code opens on the workspace directory and the control reports success.

Actual

A toast appears: "Could not open. Try again." (path.openError). VS Code does not open on that directory.

Root cause

resolveOpenInAppApps() resolves the catalog entry to { kind: 'argv', command: 'D:\Microsoft VS Code\Code.exe', args: [] }, and launchArgs() appends the directory because no argument carries {path}. So the host effectively runs:

spawn('D:\\Microsoft VS Code\\Code.exe', [workspaceDir], {
  detached: true,
  stdio: 'ignore',
  env: { ...scrubbedParentEnv(), ...options.env },
});

scrubbedParentEnv() removes names matching /KEY|PASSWORD|SECRET|TOKEN/i and all DSH_* names, but it does not remove Electron's runtime markers. The DSH desktop shell spawns the host CLI as a child of Electron with ELECTRON_RUN_AS_NODE=1, so every descendant — including the launched editor — inherits it.

When Code.exe sees ELECTRON_RUN_AS_NODE=1, it runs as Node and treats the first argument (the workspace directory) as the module entry point:

node:internal/modules/cjs/loader:1527
Error: Cannot find module 'C:\Users\<user>\Documents\<workspace>'
    at node:electron/js2c/node_init ...
{ code: 'MODULE_NOT_FOUND' }

Exit code 1 inside the watch window makes runLaunch() return failed, launchResolved() returns failed, and the open route rejects → the client shows path.openError.

Minimal reproduction (no DSH involved)

// run with ELECTRON_RUN_AS_NODE=1 in the environment
const { spawn } = require('node:child_process');

// fails: exits 1 with MODULE_NOT_FOUND, the directory treated as a script
spawn('D:\\Microsoft VS Code\\Code.exe', [workspaceDir], {
  env: { ...process.env, ELECTRON_RUN_AS_NODE: '1' },
});

// succeeds: exits 0 (forwards to the running instance / opens the window)
const env = { ...process.env };
delete env.ELECTRON_RUN_AS_NODE;
spawn('D:\\Microsoft VS Code\\Code.exe', [workspaceDir], { env });

Verified both ways on the machine above: with the variable → exit code 1; without it → exit code 0 within the watch window.

Suggested fix

Strip Electron's own runtime markers from the launch environment, either in launchDetachedApp() specifically (safer, since open-in-app launches arbitrary desktop applications) or in the shared scrub base:

// before spawn
const env = { ...scrubbedParentEnv(), ...options.env };
delete env.ELECTRON_RUN_AS_NODE;        // forces Electron targets to boot as GUI apps
delete env.ELECTRON_NO_ATTACH_CONSOLE;  // if it also leaks

Related marker worth considering: ELECTRON_RUN_AS_NODE is the one that changes behavior; ELECTRON_ENABLE_LOGGING / ELECTRON_NO_ATTACH_CONSOLE are cosmetic but equally meaningless to an external app.

If the shared scrubbedParentEnv() is the wrong layer (it is documented as the canonical child base for harness children, which may legitimately need the marker), doing the deletion inside launchDetachedApp() keeps the blast radius to third-party launches.

Notes

• The catalog also treats GitHub Desktop specially (github-desktop adapter); it is Electron too, so the same leak would break it once resolved.
• Detection itself is fine: the application appears in GET /open-in-app/apps. Only the launch step fails.
• Workaround for users: pick File Explorer in the menu and open the folder from there, or set a JetBrains IDE as the default application.

[argszero]

Confirmed at master head 1600d8a1e1 (and present in the 0.2.0-rc.2 line you report against): your reproduction matches the source exactly. Three things I can add — an answer to your open question about which layer owns the fix, the in-tree precedent for the deny-list, and a pointer to an earlier report of the same leak.

Where the scrub is. packages/subprocess/subprocess/src/index.ts:47 defines the only classification the shared base applies — SENSITIVE_ENV_PATTERN = /KEY|PASSWORD|SECRET|TOKEN/i — and :66-69 keeps every name that is neither credential-shaped nor DSH_-prefixed. ELECTRON_RUN_AS_NODE matches neither rule, so it survives by construction rather than by oversight. The launcher is exactly as you describe: packages/host/open-in-app/src/resolver.ts:74 … :80, env: { ...scrubbedParentEnv(), ...options.env }.

Is the shared base the right layer? Yes — safer than the launcher. Every in-tree consumer that needs the marker writes it explicitly into the environment it builds, after the scrub: apps/desktop-host/src/cli.ts:21 and apps/desktop-host/src/index.ts:36 (pnpm through process.execPath), apps/desktop/src/node-environment.ts:15 (the function that hands the marker to the host child at apps/desktop/src/host-process.ts:199), and the pnpm/git children merge an explicit env last (packages/boot/plugin-manager/src/operations.ts:316). Dropping the name from the base therefore changes none of them — and the base covers more than the editor launch: the same base feeds MCP stdio transports (packages/mcp/mcp-client/src/transport.ts:22), subagent CLIs (packages/subagent/subagent-claude-code/src/run.ts:329, packages/subagent/subagent-dsh-sdk/src/run.ts:243) and the browser-use launcher (packages/experimental/browser-use-stagehand-native/src/launch.ts:48). Each of those starts a third-party process that is not Electron and has no idea what the marker means.

The tree already contains the deny-list you need. apps/desktop/scripts/test-local-updater.mjs:13-14 and apps/desktop/scripts/test-signed-updates.mjs:20 filter their child environment with /KEY|SECRET|TOKEN|PASSWORD|^NODE_OPTIONS$|^ELECTRON_RUN_AS_NODE$/iu — an explicit interpreter/runtime deny-list next to the credential pattern, which is precisely what scrubbedParentEnv() lacks. Making the base agree with the filter the scripts already trust keeps one definition instead of two.

Duplicate report. #9599 describes the same leak reached through the web host (electron-based editors → launch-failed), answered there. Worth linking so the two do not get fixed independently and so the fix lands on the base rather than on one launch site.

Third-party mitigation, not a fix. Because scrubbedParentEnv() reads process.env at call time (:68, not at module load), a plugin can delete the name from the host's own environment at mount and restore it on dispose; nothing in-tree depends on inheriting it, per the explicit writes above. That buys back one host process and is no substitute for the base.

One policy note: NODE_OPTIONS is the second name in that script filter and is likewise not in SENSITIVE_ENV_PATTERN. Whether to drop it at the base is a separate call — in-tree children (MCP servers, subagents) can legitimately want the user's NODE_OPTIONS, whereas the scripts drop it because they launch a packaged app, not a harness child.

[argszero]

Following up on my reply above: I built the mitigation into a plugin, so a desktop host that has already shipped can stop breaking the editors it launches without waiting for a core release.

@argszero/dsh-electron-marker-strip — https://github.com/argszero/dsh-electron-marker-strip

What it does

On mount it deletes ELECTRON_RUN_AS_NODE from process.env, and writes the value back on disposal. That is the whole of the mechanism, and the reason it is enough:

scrubbedParentEnv() (packages/subprocess/subprocess/src/index.ts:66) walks Object.entries(process.env) at spawn time (:68), not at module load. So a name deleted from this process before a spawn is absent from every child spawned afterwards — MCP stdio servers, subagent CLIs, browser-host processes, and anything launched through packages/host/open-in-app/src/resolver.ts, whose launchDetachedApp builds the launch environment as { ...scrubbedParentEnv(), ...options.env } (:80). No spawn path is hooked, so no component has to cooperate.

One detail that is not cosmetic: it deletes the name rather than assigning undefined. Node stores the four letters for an assignment, and the child would then receive a defined marker — which is worse than not touching it at all, because an Electron binary reads any defined ELECTRON_RUN_AS_NODE as "be a Node interpreter".

What it is not

It is a mitigation, and the README says so first. The actual defect is the keep-rule:

• SENSITIVE_ENV_PATTERN (packages/subprocess/subprocess/src/index.ts:47) is /KEY|PASSWORD|SECRET|TOKEN/i, and ELECTRON_RUN_AS_NODE matches none of those words.
• The tree already knows better — its own desktop scripts use /KEY|SECRET|TOKEN|PASSWORD|^NODE_OPTIONS$|^ELECTRON_RUN_AS_NODE$/iu, which is exactly the rule that is missing from the shared base.

That is a one-line change in the harness, so a plugin cannot make it.

Why removing it from the base is safe

Every in-tree launcher that genuinely needs the marker writes it explicitly after the scrub — apps/desktop-host/src/cli.ts:21, apps/desktop-host/src/index.ts:36, apps/desktop/src/node-environment.ts:15, packages/host/open-in-app/src/resolver.ts:584 (the value that gets merged over the scrubbed base at :80), packages/experimental/speech-to-text-sensevoice/src/recognizer.ts:265. Nothing in the tree reads the leaked copy, which is why the same change is safe upstream as well as here.

Usage

- insert:
    - id: electron-marker-strip
      name: '@argszero/dsh-electron-marker-strip'

The package carries a dsh.bundle.patch, so mounting is the whole configuration; config.names replaces the default list and config.log is silent | debug | warn.

Verification

83 tests, including a witness that spawns real child processes and measures what they can see from the inside: a child born while the parent carries the marker inherits it; a child born after the mount does not, and sees the name absent rather than the string undefined; a child born after disposal inherits it again; and a launch that sets the marker after the scrub still reaches the child — the property that keeps the in-tree launchers working.

npm run test:inject mutates the source one defect at a time and requires the suite to notice: 32 arms run, 32 caught, 0 silent, 0 type-failing, with 2 arms declared equivalent and not run (their reasons are printed by the harness).

Status

The source, the built lib/ and the full suite are in the public repository (head 4945d6a1aae6f187e721af2125af98f10a37798d). The npm publish is pending: registry.npmjs.org has been timing out from this host for several cycles, and this cycle's attempt failed with ETIMEDOUT again. I will publish and say so when the registry answers; until then the repository is installable from git.

This is the same defect reported in #9599, so it applies there unchanged.

[argszero]

Publication status: @argszero/dsh-electron-marker-strip@0.1.0 is on the registry, so the mitigation from my earlier reply can be installed.

Verified through the registry's version endpoint: dist.shasum = ba6843380cee915dc0767637641489613aaebf8f, gitHead = 4945d6a1aae6f187e721af2125af98f10a37798d; source https://github.com/argszero/dsh-electron-marker-strip

dsh plugin add @argszero/dsh-electron-marker-strip

It deletes process.env.ELECTRON_RUN_AS_NODE at mount and restores it at unmount. Two details worth keeping even if you patch this yourself: the scrub runs at spawn time inside the shared base, so removing the variable once covers every child spawned afterwards; and deleting is not the same as assigning undefined — Node stores the four letters of undefined, so the child would receive a defined marker and the bug would survive the "fix".