[Bug] open-in-app: VS Code (and every Electron app) cannot be launched on Windows — ELECTRON_RUN_AS_NODE leaks into the child environment

[JSNGCC]

Where to post: deepseek-ai/deepseek-harness has Issues disabled; bug reports go to Discussions → General, titled with a [Bug] prefix. Paste this file as the body. If maintainers prefer support threads, the same body fits Q&A unchanged.

Environment
DSH desktop 0.2.0-rc.2, Windows 11 (10.0.26200), x64
VS Code 1.142.0, installed at D:\Microsoft VS Code (non-default path; resolved correctly through HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\Code.exe)
Profile: desktop (bundles: @deepseek-ai/dsh-base, @deepseek-ai/dsh-web-app, dsh-ops, dshmarket)
Summary
The Session-header "Open In…" menu lists VS Code, but choosing it never takes effect: the split button keeps showing File Explorer (default) and no choice is persisted. The same failure applies to the document-preview "Open" action. Launching the identical executable from a terminal works.

Cause: the desktop app runs its backend through the Electron binary acting as Node (process.execPath + ELECTRON_RUN_AS_NODE=1), so the backend's process.env carries that variable. open-in-app launches applications detached with scrubbedParentEnv(), which strips only /KEY|PASSWORD|SECRET|TOKEN/ names and DSH_* — the Electron selector survives, and any launched Electron application (VS Code, Cursor, Windsurf, …) then starts as plain Node, receives the workspace directory as if it were a script argument, and exits non-zero immediately.

Because launchWatchMs (default 1000 ms) classifies a non-zero exit inside the window as a failed launch, the route reports failure and the client never stores the choice, so the UI looks like the entry "cannot be selected".

Steps to reproduce
Install VS Code (anywhere; App Paths or the file locators resolve it).
Open a Session, click the chevron of the header "Open In…" split button.
Choose VS Code. Nothing opens; the default stays File Explorer.
Compare with the terminal, which succeeds:
代码块

"D:\Microsoft VS Code\bin\code.cmd" .

VS Code opens the directory normally.

Evidence
The host process and everything it spawns see the selector:

代码块

echo %ELECTRON_RUN_AS_NODE%
1
Launching the resolved catalog launcher exactly as launchDetachedApp does — spawn(command, [dir]), no shell, inherited environment — ends in failure within ~55 ms:

代码块

node -e "const{spawn}=require('node:child_process');const p=spawn('D:\Microsoft VS Code\Code.exe',['C:\Users\hjc\Documents\deepseek-harness\default-workspace']);p.on('exit',(c,s)=>{console.log('exit',c,s);process.exit(0)})"

exit 1 null (after 55 ms)

The executable itself is fine — it is signed Microsoft VS Code 1.142.0 (FileDescription: Visual Studio Code, FileVersion: 1.142.0, valid Authenticode signature). Under the inherited environment it answers as Node:

代码块

"D:\Microsoft VS Code\Code.exe" --version
v24.21.0 # Node, not VS Code
With the selector removed it boots the application (main-process logs appear and it keeps running):

代码块

cmd /c set ELECTRON_RUN_AS_NODE= && "D:\Microsoft VS Code\Code.exe"
[main ...] [node-compile-cache] main: packaged cache enabled
[main ...] StorageMainService: creating application shared storage
Note that bin\code.cmd works because it sets ELECTRON_RUN_AS_NODE=1 and passes resources\app\out\cli.js explicitly — the supported CLI path — rather than relying on inheritance.

Root cause
@deepseek-ai/dsh-subprocess — the scrubbed child environment:

js

const SENSITIVE_ENV_PATTERN = /KEY|PASSWORD|SECRET|TOKEN/i;

function scrubbedParentEnv() {
const env = {};
for (const [key, value] of Object.entries(process.env)) {
if (value !== void 0 && !SENSITIVE_ENV_PATTERN.test(key) && !key.toUpperCase().startsWith("DSH_")) env[key] = value;
}
for (const [name, value] of Object.entries(proxyEnvironmentForChild())) { /* … */ }
return env;
}
@deepseek-ai/dsh-host-open-in-app — the launcher:

js

const child = spawn(command, [...args], {
detached: true,
stdio: "ignore",
windowsHide: options.windowsHide,
env: { ...scrubbedParentEnv(), ...options.env },
});
ELECTRON_RUN_AS_NODE matches neither exclusion, so it reaches every spawned application.

The desktop build is what puts it in the backend's environment (support launcher):

js

packageManager: {
command: process.execPath,
args: ["--expose-internals", /* … /],
env: {
ELECTRON_RUN_AS_NODE: "1", // backend runs the Electron binary as Node
DSH_DESKTOP_NODE_EXECUTABLE: process.execPath,
PATH: / … */,
},
},
Suggested fix
Exclude runtime selector variables from the inherited environment in scrubbedParentEnv() (@deepseek-ai/dsh-subprocess), keeping the explicit adapter entries authoritative:

js

// Names that only make sense for this host's own Electron-as-Node runtime. A launched
// application must never inherit them: VS Code and other Electron apps would start as Node
// and exit immediately, which open-in-app reports as a failed launch.
const HOST_RUNTIME_ENV = new Set(["ELECTRON_RUN_AS_NODE", "ELECTRON_NO_ATTACH_CONSOLE"]);

function scrubbedParentEnv() {
const env = {};
for (const [key, value] of Object.entries(process.env)) {
if (value === void 0) continue;
if (SENSITIVE_ENV_PATTERN.test(key)) continue;
if (key.toUpperCase().startsWith("DSH_")) continue;
if (HOST_RUNTIME_ENV.has(key.toUpperCase())) continue;
env[key] = value;
}
/* … */
}
This keeps the GitHub Desktop entry working: that catalog entry deliberately sets env: { ELECTRON_RUN_AS_NODE: "1" } to run its packaged cli.js, and the spread order in launchDetachedApp (...scrubbedParentEnv(), ...options.env) still lets the explicit entry win.

A narrower alternative is to delete the name inside launchDetachedApp before spreading options.env; filtering the inherited environment is preferable because the same leak affects any detached child that happens to be an Electron binary.

Impact
All Electron-based catalog entries (VS Code, VS Code Insiders, Cursor, Windsurf, Zed, and any other application honoring the selector) cannot be launched from the header or the document preview.
File-manager entries are unaffected because they use shell-open, which explains why File Explorer works and the same action on VS Code does not.
Symptom is silent: the failed launch shows at most a transient toast, and the remembered choice is not updated, so it reads as "this menu item cannot be selected".
中文摘要
Windows 上「Open In…」里选 VS Code 不生效：桌面端用「Electron 二进制 + ELECTRON_RUN_AS_NODE=1」 拉起后端，后端 process.env 因此带上这个变量；open-in-app 启动外部应用时用的 scrubbedParentEnv() 只剔除 KEY/PASSWORD/SECRET/TOKEN 与 DSH_*，变量被继承，VS Code 于是以 Node 模式启动、约 55 ms 后退出码 1。launchWatchMs（默认 1000 ms）把它判为启动失败，选择因此不会 被记住，界面看起来就是「无法选中」。建议在 scrubbedParentEnv() 里排除该运行时选择变量，显式 adapter 条目（如 GitHub Desktop 的 ELECTRON_RUN_AS_NODE: "1"）仍应生效。

[PerryLink]

Confirmed at the source of the scrubber, and the specific reason your variable survives is worth quoting because it is not an oversight — it is the scrubber's stated scope.

packages/subprocess/subprocess/src/index.ts:

export const SENSITIVE_ENV_PATTERN = /KEY|PASSWORD|SECRET|TOKEN/i          // :47

export function scrubbedParentEnv(): Record<string, string> {              // :66
  const env = {}
  for (const [key, value] of Object.entries(process.env)) {
    if (value !== undefined && !SENSITIVE_ENV_PATTERN.test(key) && !key.toUpperCase().startsWith(DSH_ENV_PREFIX)) env[key] = value
  }
  ...
}

ELECTRON_RUN_AS_NODE contains no KEY/PASSWORD/SECRET/TOKEN and does not start with DSH_, so it passes both filters unchanged. And packages/host/open-in-app/src/resolver.ts is one of the consumers of this function, so the leaked variable reaches the detached launch exactly as you describe.

The doc comment at :51-58 also makes the intent explicit: the base is "the canonical base every harness child starts from", and anything credential-shaped or DSH_* has to be passed explicitly. ELECTRON_RUN_AS_NODE is neither, which is precisely why it falls through. So the bug is not that the pattern is too narrow in general — it is that one runtime-selection variable is a harness-identity variable rather than a credential variable, and the scrubber currently only knows how to think about credentials.

Two fix shapes, and they are not equivalent:

1. Deny-list the selector. Add ELECTRON_RUN_AS_NODE (and its relatives — ELECTRON_NO_ATTACH_CONSOLE, ELECTRON_FORCE_IS_PACKAGED, NODE_OPTIONS deserves a look too) to an explicit "harness-identity" strip list. Small, targeted, and it makes the intent auditable: "we are running as Electron-as-Node; children are not."
2. Allow-list the environment for launched applications. Launching a GUI application is not the same contract as spawning a harness child: the former wants the user's desktop environment, the latter wants a controlled base. scrubbedParentEnv() is the right base for the second and arguably the wrong base for the first.

I would argue for (2) as the direction and (1) as the immediate patch, because (2) is the only one that keeps working when the next Electron variable appears — and it also stops you from having to re-audit this every time someone adds a knob.

One thing worth adding to the report: the same leak plausibly affects any other detached-launch path that reuses scrubbedParentEnv() while the host is Electron-as-Node. If you have the appetite, grepping the consumers listed in that package's README (open-in-app, browser launchers, subagent providers) for "launch a third-party GUI binary" would tell you whether this is one bug or a class. browser-use-stagehand-native and subagent-claude-code both consume the same function, and both can start external binaries.

[JSNGCC]

Thanks — the "harness-identity variable, not a credential variable" framing matches what I see, and splitting the immediate patch from the contract is exactly the distinction I was missing.

One more data point: the selector is load-bearing for the harness's own spawns

Before reporting, I tried the cheap local workaround: a host plugin that deletes process.env.ELECTRON_RUN_AS_NODE at mount, no code changes. It made the symptom go away, but every subsequent pwsh and ops_bash call failed:

subprocess-local: Windows Job runner exited with exit code 0 before proving its managed range empty

So the Windows job runner is launched through scrubbedParentEnv() too, and it relies on inheriting the selector to start as Node — the same way the desktop launcher starts this backend. With the variable gone, it starts as Electron, finds no script, exits 0, and never gets to prove its managed range empty.

Two consequences for the fix:

.A deny-list inside scrubbedParentEnv() breaks every shell tool, so shape (1) cannot live there. It has to sit at the GUI-launch site (launchDetachedApp).
.The better long-term shape is (2) plus an explicit opt-in: the runner is an Electron-as-Node child, so it should pass the selector itself rather than rely on the base, and the base should stop forwarding it at all. A scrubber cannot tell "this child wants the harness identity" from "this child is a user's editor" — that knowledge exists only at the call site.

Consumer audit of scrubbedParentEnv() (the list you asked for — five importers in 0.2.1-rc.2)

Consumer	What it spawns	Verdict
dsh-host-open-in-app — launchDetachedApp	GUI editors / IDEs / terminals	Affected, reproduced
dsh-mcp-client — buildChildEnv for StdioClientTransport	arbitrary stdio MCP servers	Latent — an Electron-packaged MCP server fails identically; NODE_OPTIONS-class names reach it too, which is a separate concern
dsh-plugin-manager — GitHub preflight, pnpm installs	git, pnpm	Leak present, benign today (neither honors it); same hole for NODE_OPTIONS
dsh-subprocess-local — the service's own spawn	every ctx.subprocess child, including the Windows job runner	Load-bearing — must keep inheriting (see above)
dsh-web-app — default-browser handoff via open	the user's default browser	Leak present, benign today; conceptually the same "user application" contract as open-in-app

So the answer to "one bug or a class": one bug today, one latent class, and one consumer that constrains the fix. The class is "detached launch of a user-facing application" — open-in-app now; the browser handoff and any future launcher or third-party GUI provider next. The constraint is the harness's own Electron-as-Node children, which need the selector and currently get it only by inheritance.

On the two shapes

(2) is the direction I would ship: a launched application wants the user's environment, not the harness base, and only the adapter's declared entries should be added on top. As the interim patch, (1) works if it is scoped to launchDetachedApp and covers ELECTRON_NO_ATTACH_CONSOLE, ELECTRON_FORCE_IS_PACKAGED and NODE_OPTIONS there.

One detail worth keeping in either shape: the deletion has to happen before the adapter entries are spread. The GitHub Desktop entry deliberately passes env: { ELECTRON_RUN_AS_NODE: '1' } to run its packaged cli.js, and that explicit override must survive.

[Yang-SVVG]

Implemented shape (1) from your comment above, but scoped to the launch path rather than to the scrubber, so harness children keep the switch:

// packages/host/open-in-app/src/resolver.ts
const guiLaunchEnvironment = (
  overrides?: Readonly<Record<string, string>> | undefined,
): NodeJS.ProcessEnv => {
  const env: NodeJS.ProcessEnv = { ...scrubbedParentEnv() }
  delete env.ELECTRON_RUN_AS_NODE
  delete env.ELECTRON_NO_ATTACH_CONSOLE
  return { ...env, ...overrides }
}
// …
env: guiLaunchEnvironment(options.env),

Two details that cost time while writing it, worth recording before someone re-implements this:

• The deletion has to run before the merge. catalog.ts declares GitHub Desktop with env: { ELECTRON_RUN_AS_NODE: '1' } on purpose — its launcher is a cli.js shim — so a helper that strips after merging silently breaks that adapter while fixing the others.
• scrubbedParentEnv() itself should stay as it is. The dsh CLI shim, the GitHub Desktop adapter and the pnpm worker all legitimately rely on inheriting the selector. The defect is narrower than "the scrubber is wrong": it is that a launched GUI application is not a harness child, which is the same boundary your option (2) draws — just enforced where the launch happens.

Branch with the change, one commit, two files, ready to cherry-pick:

master...Yang-SVVG:fix/open-in-app-electron-run-as-node

• packages/host/open-in-app/src/resolver.ts — the helper and the one call site.
• packages/host/open-in-app/tests/launch-detached.spec.ts — the child environment drops the inherited switch; an adapter that declares ELECTRON_RUN_AS_NODE: '1' in its own env still gets it.

Verified on a real install (DSH desktop 0.2.1-rc.2, Windows 11, VS Code 1.141.0 at a non-default path G:\Microsoft VS Code): with the equivalent one-line edit applied to the shipped lib/resolver.js, Open in app → VS Code opens the session workspace, and the File Explorer / Git Bash adapters are unaffected.

Same root cause as #10294, #9920, #9689, #9254 and #8970 — eight threads for one defect, which is itself a signal about discoverability. Two follow-ups I deliberately left out of this patch: NODE_OPTIONS (a --require hook or --inspect port aimed at the harness follows the GUI child too) and ELECTRON_FORCE_IS_PACKAGED — both want their own decision instead of riding along.

[PerryLink]

Your ordering point is the part that would have bitten anyone re-implementing this. launchDetachedApp merges as env: { ...scrubbedParentEnv(), ...options.env } (resolver.ts:80), so an adapter's explicit entry wins — and the GitHub Desktop adapter depends on exactly that (:584, ELECTRON_RUN_AS_NODE: '1' for its cli.js shim). Strip after the merge and you turn one broken launcher into a silently different one.

Where the variable comes from, for the record: it is not only a user shell setting. The desktop shell spawns the host with env: desktopNodeEnvironment(this.node, undefined, this.environment) (apps/desktop/src/host-process.ts:189-199), and that helper returns ELECTRON_RUN_AS_NODE: '1' (apps/desktop/src/node-environment.ts:10-19, the flag at :15). The host process itself runs Electron-as-node, so every desktop build carries the variable in process.env and every argv adapter inherits it. That is why it reproduces for everyone and not just for people who exported it by hand.

One change I would make to the patch: put the deletion inside launchDetachedApp at :80, not in a helper the caller has to remember.

• It is the single choke point: :148 defaults launch to it and :721 is the only call for every argv adapter, so a future adapter cannot opt out by forgetting the helper.
• scrubbedParentEnv() already returns a fresh mutable Record<string, string> (packages/subprocess/subprocess/src/index.ts:66-79), so delete base.ELECTRON_RUN_AS_NODE needs no defensive copy.
• Keeping the base environment out of runLaunch preserves the contract there today — launch.env carries adapter overrides only (:723).
• It is testable where the harness already is: tests/launch-detached.spec.ts mocks spawn, so vi.mocked(spawn).mock.calls[0][2].env is the assertion.

shell-open needs nothing: :717-718 hands the path to explorer.exe / xdg-open, which spawn the target application themselves, so our environment never reaches it. Worth saying so in the comment, otherwise somebody adds the strip there later "for symmetry" and it does nothing.

Two tests I would want in the diff, because they pin the ordering trap you hit: a parent with ELECTRON_RUN_AS_NODE=1 produces a child without it, and an adapter passing env: { ELECTRON_RUN_AS_NODE: '1' } still produces a child with it.

ELECTRON_NO_ATTACH_CONSOLE is not referenced anywhere in the repository, so it can only arrive from the user's environment. Stripping it is defensible as the same family, but if the commit does not say why it is there, someone will remove it as unexplained. Either give it a line or leave it to a follow-up.