[BUG]DSH Desktop 把 ELECTRON_RUN_AS_NODE=1 导出到整个进程树，导致从 DSH 启动的任何 Electron 应用（VS Code / Cursor / Zed）静默启动失败

[liye0005]

Summary

DSH Desktop 在自己进程的环境里设置了 ELECTRON_RUN_AS_NODE=1，该变量被所有子进程继承（工具子进程、以及「打开方式」的启动器链路）。任何 Electron 应用在这种环境下启动时都会退化成纯 Node.js、随即退出，GUI 永远不会出现。

而 Windows 自带的启动器（cmd /c start、rundll32 url.dll,FileProtocolHandler）仍然返回退出码 0，所以整个失败是静默的——用户只看到一句通用文案 "打开失败，请重试"（path.openError）。

受影响场景：所有从 DSH 内启动的 Electron 系编辑器/IDE，例如 VS Code / VS Code Insiders / VSCodium、Cursor、Windsurf、Zed。

Reproduction

环境：DSH Desktop 0.2.0-rc.2，Windows 10.0.26200，VS Code 1.141.0。任选一个 Electron 应用，下面用 VS Code。

1. 启动 DSH Desktop，从它派生出的任意 shell 里确认变量已泄漏：

   $env:ELECTRON_RUN_AS_NODE      # -> 1

   它没有被持久化到任何地方，仅存在于 DSH 进程内：

   [Environment]::GetEnvironmentVariable('ELECTRON_RUN_AS_NODE','User')     # -> 空
   [Environment]::GetEnvironmentVariable('ELECTRON_RUN_AS_NODE','Machine')  # -> 空
   [Environment]::GetEnvironmentVariable('ELECTRON_RUN_AS_NODE','Process')  # -> 1

2. 用与 DSH 启动器相同的方式启动目标程序（这条命令也等价于点击「打开方式 → VS Code」）：

   & 'C:\Users\<user>\AppData\Local\Programs\Microsoft VS Code\Code.exe' --open-url -- 'vscode://file/D:/some/folder'

3. 对照实验——只从子进程环境中移除这一个变量，其余完全不变：

   $psi = New-Object System.Diagnostics.ProcessStartInfo
   $psi.FileName  = 'C:\...\Microsoft VS Code\Code.exe'
   $psi.Arguments = '"D:\some\folder"'
   $psi.UseShellExecute = $false
   [void]$psi.EnvironmentVariables.Remove('ELECTRON_RUN_AS_NODE')   # ← 唯一改动
   [System.Diagnostics.Process]::Start($psi)

Current behavior

第 2 步（变量存在）拿到 bad option：

C:\...\Microsoft VS Code\Code.exe: bad option: --open-url

改用普通路径参数时，栈信息直接暴露它跑的是 Node.js，而不是 VS Code：

Error: Cannot find module 'D:\some\folder'
    at Module._resolveFilename (node:internal/modules/cjs/loader:1571:15)
    at Module.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:169:5)
    at node:electron/js2c/node_init
Node.js v24.21.0

事后 Get-Process -Name Code 为 0 —— 进程从未存活。

第 3 步（仅移除该变量）则完全正常，VS Code 启动并打开了目标文件夹：

[main] StorageMainService: creating application shared storage
[main] update#setState idle
[main] AgentHostProcessManager: agent host started

Get-Process -Name Code → 9 个进程。

单变量对照即恢复正常，把原因锁定在这个变量上。

补充：同一个「打开方式」菜单里的 「文件资源管理器」是可以正常工作的，因为它复用已在运行的 Explorer 实例（/select 通过 COM 转发），不需要新建 Electron 进程——这与上述结论一致。

Expected behavior

1. ELECTRON_RUN_AS_NODE 不应被进程级导出；它只应对真正需要 Node 语义的那一次 spawn 生效。
2. 从 DSH 启动 Electron 应用应当成功，或至少给出可诊断的失败信息。

Environment

项目	值
DSH Desktop	0.2.0-rc.2（安装器版本；内置 CLI dsh --version → 0.2.0-rc.2）
操作系统	Windows 10.0.26200
DSH 运行时 Node	24.18.1
目标应用	Visual Studio Code 1.141.0（2a59476c9bfcb90b3ddc372c36762471b7dfad1c，x64）
触发入口	「打开方式」菜单 → VS Code

---

[argszero]

One coupling is worth having in hand before this gets fixed, because the obvious fix is a one-liner that breaks something else on Windows.

ELECTRON_RUN_AS_NODE is not only ambient noise for DSH: the Windows ACL sandbox runner is the Electron binary. The invocation is built as [process.execPath, runner.js] (packages/sandbox/sandbox-local/src/index.ts), and the packaged desktop is the one build where process.execPath is an Electron executable rather than a Node binary — so that child needs the variable to behave as node at all. A blanket tombstone of ELECTRON_RUN_AS_NODE in the shared child environment (the undefined tombstone buildChildEnvironment supports) therefore takes runner.js down with it, and measured, the failure is not subtle: the packaged host with ELECTRON_RUN_AS_NODE=1 dies with 3221225794, while a real node.exe running the same runner with the same arguments exits 0.

So the two changes have to land together, and the shape that does both is per-child rather than per-process-tree: do not hand the variable to ordinary children, and set it explicitly on the sandbox-runner invocation when (and only when) argv[0] is an Electron binary. That is the same interaction recorded as [#8174] against [#8193], and it is carried as prose in @argszero/cordis-plugin-sandbox-grant-advisor@0.23.0 — the advisor cannot fix it (the environment scrub is core-side), so it states the constraint for whoever does.

Two smaller readings from the same source that your report implies but does not need to restate: the outer subprocess runner's image is irrelevant to this (Electron outside + node ACL runner succeeds; node outside + Electron ACL runner fails — the image that mints the restricted token is what decides), and a token inherited from an Electron parent is harmless on its own. Both are measured, so if a candidate fix is tested by swapping one of those instead, the test is measuring something else.

[explorerxx]

补充独立复现、一处必须同时改的耦合，以及对两条修法建议的两点校正。

1) 独立复现（不同系统版本、不同机器）

楼主是 Windows 10 22H2 (19045)，我这里是 Windows 11 26H2 (26300.9711) —— 跨版本一致；
另一台 Windows 机器同样复现。定量对照（在桌面端 Host 进程内部取证，加载的是 app.asar 内的真实代码，
已用 SHA256 逐字节校验与 asar 一致）：

模式	「打开方式」显式选 VS Code 打开 .md
保留继承（现状）	调用返回成功 461 ms，2.5 s 后 Code.exe 存活 0
打开前删除该变量	调用返回成功，2.5 s 后 Code.exe 存活 10

一行复现：$env:ELECTRON_RUN_AS_NODE=1; & "$env:LOCALAPPDATA\Programs\Microsoft VS Code\Code.exe" <目录>
→ 41–69 ms 退出，stderr Error: Cannot find module '<目录>'。

补一条楼主没覆盖的路径：「显式选应用」走的是 IHandler::Invoke，同样在 Host 进程内执行 ——
Invoke 返回成功、应用却秒退 → 宿主回报成功 → 界面没有任何提示。
只在 launchDetachedApp() 里净化救不了这条"静默失败"。

2) 与沙箱的耦合（同意 argzero）：修法必须是 per-child，且两处一起改

dsh-sandbox-local 的 Windows ACL runner 启动参数就是 [process.execPath, runner.js]
（lib/index.js:539-553，注释原文 "The prefix stays [node, runner, ...]"）。
打包后 process.execPath 是 Electron 二进制，它需要这个变量才具备 Node 语义 ——
所以在 scrubbedParentEnv() 里一刀切会连带打死沙箱 runner。

把树里所有相关点列出来，形状就清楚了：

位置	现状	净化后
dsh-sandbox-local:539-553 → ACL runner [process.execPath, runner.js]	依赖继承	需 per-child 显式补回 ELECTRON_RUN_AS_NODE:'1'
dsh-host-directory-picker-native:74-99 → env = {...process.env, DSH_DIALOG_TITLE} + process.execPath worker.cjs	直传 process.env	接缝净化不影响它；但若改成从 process.env 全局删除就会打破它
dsh-host-open-in-app github-desktop launch spec（resolver.js:495）	已显式设置	否（{...scrubbed, ...options.env} 会补回）
dsh-experimental-speech-to-text-sensevoice:775-784	已显式设置	否
dsh-ptc-runtime-node:956	官方已在自建子环境时过滤掉它	—— 现成先例，建议泛化它而不是新发明规则

3) 两点校正

• "catalog 里 GitHub Desktop 条目显式写了 env"不准确：OPEN_IN_APP_CATALOG 的 github 条目只有
  spec({ kind: 'github-desktop', … })，没有 env；那个 env: { ELECTRON_RUN_AS_NODE: '1' } 在
  定位器产出的 launch spec 里。所以"catalog 显式提供时才保留"会因取错位置而误伤 GitHub Desktop；
  正确判据是看 launch spec 的 env。
• 不建议改写 process.env 来实现净化（会打破上表第二行那种直传 process.env 的 spawn）；
  在接缝处构造子环境时过滤，需要 Node 语义的 spawn 各自显式声明。楼主观察到的
  "VS Code 的 bin\code.cmd 会主动 delete env.ELECTRON_RUN_AS_NODE"正是这个模式。

4) 赞同两点：launch-failed 里带上子进程退出码/错误码；回归夹具再加一条断言 ——
ACL runner 仍能以 Node 语义在受限令牌下启动（否则修好文件关联会换沙箱坏掉）。

English summary: independently reproduced on Windows 11 26H2 (build 26300) and on a second Windows machine;
quantified A/B inside the packaged host (variable inherited → Code.exe exits in 41 ms, 0 processes survive;
variable removed → 10 processes, opens fine). One path is still silent: the "Choose another app" flow runs
IHandler::Invoke in-process, so Invoke succeeds, the app dies, and the UI reports nothing — a fix
confined to launchDetachedApp() misses it. Agreeing with @Argzero's coupling note, the fix has to be
per-child: scrub the selector when building ordinary child environments (generalizing the filter that
dsh-ptc-runtime-node already applies), and set it explicitly where an Electron binary must run as Node —
notably the Windows ACL runner (dsh-sandbox-local returns [process.execPath, runner.js]), which currently
relies on inheritance. Note the explicit override for GitHub Desktop lives in the launch spec produced by the
resolver, not in the catalog table, so a "keep it when the catalog provides it" rule would break GitHub Desktop.