[Desktop] Electron 壳把 ELECTRON_RUN_AS_NODE=1 泄漏给 dsh 宿主：所有 Electron 系应用（VS Code 等）被当 Node 启动、静默失败

[xzgjj]

现象

官方桌面客户端 @deepseek-ai/dsh-desktop@0.1.7-rc.2（bundled runtime @deepseek-ai/dsh-desktop-runtime@0.1.7-rc.2，Windows 11）里，任何"启动 Electron 系外部应用"的入口都静默失效：

• 第三方插件 dsh-better-sidebar v0.21.1 的「在应用中打开 → VS Code」：点击后无窗口、无报错、无系统弹窗；
• 官方自带的 open-in-app（@deepseek-ai/dsh-host-open-in-app + @deepseek-ai/dsh-client-ui-open-in-app）在桌面版里点 VS Code 项同理（launchDetachedApp 用 scrubbedParentEnv()，而它不清这个变量）；
• 受影响的是所有 Electron 系编辑器/应用：VS Code、VS Code Insiders、Cursor、Windsurf、Zed 的 Electron 版等。非 Electron 的打开路径（走 explorer.exe 交系统外壳的"默认应用打开 / 显示文件位置"）不受影响。

根因链

1. 桌面壳的 Electron 主进程在拉起 dsh 宿主时注入模式开关（app.asar/lib/main.js）：

   function desktopNodeEnvironment(executable, bin, environment) {
     return { ...environment, ELECTRON_RUN_AS_NODE: "1", /* DSH_DESKTOP_NODE_EXECUTABLE, PATH */ }
   }

   （@deepseek-ai/dsh-desktop-host 也把同一变量写进它给 packageManager 的 env。）宿主本身确实是"Electron 二进制以 Node 模式"运行，所以这个变量必须在启动时存在 —— 但它随后留在了宿主的 process.env 里。

2. 于是宿主进程 spawn 出去的任何子进程都继承它，例如插件的 spawn(cmd, args, { detached: true, stdio: 'ignore' })（不覆盖 env）→ 传给了 Windows 打开器 rundll32.exe → 再传给 Code.exe。

3. VS Code 自己也是 Electron 应用：它看到 ELECTRON_RUN_AS_NODE=1 就退化为纯 Node，把文件路径/URL 当脚本执行 → SyntaxError → 立即退出。用户侧看到的就是"点了没反应"。

实测证据（同机、同命令，只差父进程是否带该变量）

试验	命令	结果
负对照（继承带该变量的环境）	rundll32.exe url.dll,FileProtocolHandler vscode://file/D:/dsh/AGENTS.md	Code.exe 进程数 0
正对照（spawn 时剔除该变量）	同上	Code.exe 11 个进程，窗口标题 AGENTS.md - Visual Studio Code
直接证据	带该变量执行 Code.exe D:\dsh\AGENTS.md	stderr：D:\dsh\AGENTS.md:1 SyntaxError … at node:electron/js2c/node_init … Node.js v24.20.0

另外，packages/subprocess/subprocess/src/index.ts:44 的 SENSITIVE_ENV_PATTERN = /KEY|PASSWORD|SECRET|TOKEN/i 不会命中 ELECTRON_RUN_AS_NODE → scrubbedParentEnv() 原样保留，所以走该清理的官方 spawn 同样中招。

建议（两处，任一处都能止血，建议都做）

1. 桌面壳：desktopNodeEnvironment 只在"启动宿主这一次"的 spawn 上设置该变量，宿主进程启动后把它从 process.env 中删除（或桌面壳在交给插件的 env 里剔除）。原则：Electron 的进程级模式开关绝不该出现在传递给第三方插件/外部应用的继承环境里。
2. scrubbedParentEnv()：把 ELECTRON_RUN_AS_NODE（以及同类 Electron 模式开关，如 ELECTRON_NO_ATTACH_CONSOLE、ELECTRON_FORCE_WINDOW_MENU_BAR）加入固有丢弃名单 —— 它属于"宿主实现细节"，与 DSH_* 同类，不属于要传给子进程的用户环境。

关联

• 插件侧同一现象：BUG：右键在应用中打开无反应 omdsh-dev/DSH-better-sidebar#412（已在该 issue 补充根因；插件 launchExternal 继承 env 亦应清洗）
• web 版（普通 node 宿主，无此变量）不受影响 → 可作为对照环境复现/验证

[PerryLink]

这条泄漏结构上成立，而且我核到了源头那一行

1. 源头与文档

// apps/desktop-host/src/index.ts:36
ELECTRON_RUN_AS_NODE: '1',

而 apps/desktop/README.md:64 把这件事写成了设计：

dsh runs under Electron with ELECTRON_RUN_AS_NODE=1 and --expose-internals …

⇒ 也就是说：宿主进程自己就带着这个变量（这是它在 Electron 里当纯 Node 跑的必要条件）。于是任何用"继承父进程环境"的方式拉起来的 Electron 应用，都会以 Node 模式启动——表现正是你写的"无窗口、无报错"。你的因果链成立。

我也核到了你点的那个函数确实存在：packages/host/open-in-app/src/resolver.ts:74

export const launchDetachedApp: OpenInAppLauncher = (command, args, options) => …
// 并在 :148 被选用：launch: internals.launch ?? launchDetachedApp

2. 为什么"非 Electron 路径正常"这条对照很有力

你观察到的不对称（explorer.exe 交系统外壳的"默认应用/显示位置"不受影响，只有 Electron 系应用失败）正好排除了"启动逻辑整体坏了"，把范围压到"环境变量被继承"这一条上。建议保留这句。

3. 修法建议（两条，建议都要）

1. 在 detached 启动时剔除该变量（scrubbedParentEnv() 的清洗名单里加上 ELECTRON_RUN_AS_NODE，可能还要一并考虑其它 ELECTRON_* 模式开关）；
2. 更根本的做法：不要把这个变量放进宿主的进程环境，而是只注入到需要它的那个子进程——现在它污染了整个进程树，任何下游创建进程的地方都要各自记得清洗，这是一类会反复出问题的形状。

第 2 条尤其值得写进报告：它解释了为什么这不会只错一次。

4. 一个同族线索（对你有利）

launchDetachedApp 这条路径另有一个独立缺陷正在同一天被报告（#7842：其"打开方式"下拉里的默认应用条目也是静默失败，机理同为"启动载体差一层"）。两条合起来说明：这个函数需要一次整体的策略梳理（环境清洗 + 窗口显示标志），而不是各打一个补丁。建议你在报告里引用它。

5. 版本提醒

你在 0.1.7-rc.2（桌面 @deepseek-ai/dsh-desktop@0.1.7-rc.2）——就是当前最新，无需先升级。⚠️ 只是别把核换成 npm 的 latest（仍停在 0.1.5-rc.3，更旧）。

一条边界

我确认的是变量注入点、文档化的设计意图、以及 launchDetachedApp 的存在；"清洗名单里没有它"这一句以你的实测为准（我没有逐行读 scrubbedParentEnv）。