[bug] 桌面版 ELECTRON_RUN_AS_NODE=1 泄漏到子进程，导致 open-in-app 打开 VS Code 必然失败

[ZhaoRibo]

DSH 桌面版：ELECTRON_RUN_AS_NODE=1 泄漏到子进程，导致"在应用中打开（VS Code）"必然失败

环境

• DSH 桌面版（Electron），版本 0.2.0-rc.2
• 安装路径：C:\Users\zhaoruibo\AppData\Local\Programs\DeepSeek Harness\
• 操作系统：Windows 11（WindowsApps/App Paths 均为 Windows 语义）
• profile：desktop（默认，仅 @deepseek-ai/dsh-base + @deepseek-ai/dsh-web-app，无第三方插件）
• VS Code：1.141.0，用户级安装于 %LOCALAPPDATA%\Programs\Microsoft VS Code\Code.exe，手动打开完全正常

现象

在 Web 界面右上角点击"用 VS Code 打开"（open-in-app），界面提示「打开失败，请重试」。

实测（VS Code 事先完全未运行，观察 60 秒）：

时间	Code 进程数	%APPDATA%\Code\logs 目录数
点击前基线	0	12（最新 20261009T163404，16:34:15）
点击后 60 秒内	0（始终）	12（无新增）

即：VS Code 主进程从未启动，也没有产生任何日志目录——失败发生在 Electron 主进程初始化之前，不是界面误报。

复现

1. 启动 DSH 桌面版，确认 VS Code 未运行
2. Web 界面右上角 → 用 VS Code 打开
3. 提示「打开失败，请重试」；Code.exe 进程未出现，%APPDATA%\Code\logs 无新目录

同一台机器上，直接双击开始菜单里的 VS Code 正常打开工作区。

根因

ELECTRON_RUN_AS_NODE=1 从桌面版宿主进程泄漏到了它启动的所有子进程。

1. 桌面版入口无条件注入该变量

app.asar/lib/main.js（Electron 主入口）中：

/**
 * Select Electron's Node mode and the shell launcher used by package scripts.
 */
function desktopNodeEnvironment(executable, bin, environment) {
  return {
    ...environment,
    ELECTRON_RUN_AS_NODE: "1",      // ← 无条件覆盖调用者环境
    ...bin === void 0 ? {} : {
      DSH_DESKTOP_NODE_EXECUTABLE: executable,
      PATH: `${bin}${delimiter}${environment.PATH ?? ""}`
    }
  };
}

它被用于拉起宿主进程（app.asar/lib/main.js，HostProcess.start()）：

const child = spawn(this.node, [
  "--expose-internals",
  ...this.inspectPort === void 0 ? [] : [`--inspect=127.0.0.1:${String(this.inspectPort)}`],
  entry, this.runtimeDir, this.projectDir,
  this.primaryRuntime ?? join(this.runtimeDir, "..", "runtime", "primary-runtime"),
  ...this.packageManager === void 0 ? [] : [this.packageManager.pnpm, this.packageManager.nodeBin]
], {
  cwd: this.projectDir,
  env: desktopNodeEnvironment(this.node, void 0, this.environment),   // ← 宿主进程自身带上了该变量
  stdio: ["ignore", "pipe", "pipe", "ipc"]
});

因此宿主进程自己的 process.env 里就有 ELECTRON_RUN_AS_NODE=1，并会被其所有子进程继承。

2. 子进程环境清洗不过滤它

@deepseek-ai/dsh-subprocess 的 scrubbedParentEnv()：

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;
  ...
}

ELECTRON_RUN_AS_NODE 既不命中敏感词也不以 DSH_ 开头 → 原样传给外部应用。

3. 于是 Electron 系应用被强制当 Node 跑

@deepseek-ai/dsh-host-open-in-app 用 spawn(command, args, { detached: true, stdio: 'ignore', env: { ...scrubbedParentEnv(), ...options.env } }) 启动 Code.exe --cd=<workspace>。子进程继承 ELECTRON_RUN_AS_NODE=1 后，Electron 进入 Node 模式，不会创建窗口，并在极早期退出。

同一台机器上实测：

启动方式	结果
双击开始菜单 / 手动打开	正常打开窗口
Code.exe --cd=<dir>，环境含 ELECTRON_RUN_AS_NODE=1	立即退出，退出码 9，无进程、无日志
Code.exe --cd=<dir>，环境不含该变量	不再出现退出码 9

dsh-host-open-in-app 的启动器有 1 秒观察窗，规则是"spawn 失败或在窗口内非 0 退出即判失败"：

child.on('exit', (code, signalName) => {
  if (code === 0) settle(resolve);
  else settle(() => { reject(new Error(`launcher exited with code ${String(code)}, signal ${String(signalName)}`)); });
});

退出码 9 → reject → 界面显示「打开失败，请重试」。

4. 不是本机环境配置造成的

为避免误判，已确认该变量只存在于运行时，注册表与环境变量持久层都没有：

• HKCU:\Environment → 无该值
• HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Environment → 无该值
• [Environment]::GetEnvironmentVariable('ELECTRON_RUN_AS_NODE','User'/'Machine') → 均为空
• 但在 DSH 进程树内 process.env.ELECTRON_RUN_AS_NODE === "1"

因此这不是用户配置问题，而是桌面版自身的注入 + 未清理。

影响面

• 桌面版下，所有 Electron 系外部应用经 open-in-app 启动都会失败：VS Code、VS Code Insiders、Cursor、Windsurf 等（它们都用 Electron，都以 ELECTRON_RUN_AS_NODE 作为 Node 模式选择开关）。
• 非 Electron 应用（JetBrains 系列、终端、文件管理器等）不受影响——这也解释了为什么只有编辑器类会失败。
• 同一 profile 通过 CLI 启动（dsh --profile desktop，用户自己的干净终端）时不会出现，因为该变量不在环境里。

建议修复

1. 宿主子进程：@deepseek-ai/dsh-desktop-host 在接收启动环境后，从自身 process.env 中删除 ELECTRON_RUN_AS_NODE（Electron 的 Node 模式选择只在启动那一刻生效，删除后不影响该进程自身运行）。这样宿主进程的一切子进程都干净。
2. 统一兜底：把 ELECTRON_RUN_AS_NODE（以及 ELECTRON_NO_ATTACH_CONSOLE、ELECTRON_FORCE_IS_PACKAGED 等 Electron 选择变量）加入 scrubbedParentEnv() 的过滤名单——这是所有"启动外部程序"路径共用的清洗函数。
3. 只在前者不便时：在 dsh-host-open-in-app 的 launchDetachedApp 里，对 options.env 显式清除该变量（env: { ...scrubbedParentEnv(), ...options.env, ELECTRON_RUN_AS_NODE: undefined }）。注意这一处只管 open-in-app，其他 spawner（终端、skill 调用等）仍会中招，故建议优先做 1 或 2。

补充：仓库里已有正确处理该变量的先例可参照——dsh-ptc-runtime-node 的说明为"Host 仅在子进程启动时保留 ELECTRON_RUN_AS_NODE…bootstrap 在求值模型代码前删除该选择变量"，其实现里也有 key.toUpperCase() !== "ELECTRON_RUN_AS_NODE" 的过滤。open-in-app 这条路径只是漏了同样的清理。

可选的加固建议

dsh-host-open-in-app 目前把"启动器 1 秒内非 0 退出"直接当作启动失败。对 Electron 类应用，"主进程立刻退出但已把请求交给既有实例"是正常行为（例如 --reuse-window 场景），纯退出码判定容易误报。可考虑：对声明的 GUI 适配器放宽为"进程表/窗口出现"判定，或在错误信息中带上子进程的实际退出码与 stderr 尾部，便于定位（当前只显示笼统的「请重试」）。

临时规避（用户侧）

• 需要"在编辑器中打开"时，手动从开始菜单打开 VS Code，或
• 改用 CLI 启动 profile（dsh --profile desktop），在自己的干净终端里启动，该变量不存在，open-in-app 正常。

[PerryLink]

你的诊断基本全对，我把泄漏链四段都在最新代码上钉了行号；但你援引的先例语义是反的，这条要改，否则维护者会顺着错方向看。

1. 泄漏链：四段可逐段复核

段	位置	发生了什么
注入	apps/desktop/src/node-environment.ts:12-18	return { ...environment, ELECTRON_RUN_AS_NODE: '1', … } —— :14 展开 caller 环境，:15 无条件覆盖
交给宿主	apps/desktop/src/host-process.ts:199	env: desktopNodeEnvironment(this.node, undefined, this.environment)；同文件 :174 private readonly environment: NodeJS.ProcessEnv = process.env ⇒ 宿主进程自己的 env 里就有它
未被拦	packages/subprocess/subprocess/src/index.ts:47, 66-70	SENSITIVE_ENV_PATTERN = /KEY|PASSWORD|SECRET|TOKEN/i；scrubbedParentEnv() 只挡这个正则与 DSH_ 前缀
交给外部应用	packages/host/open-in-app/src/resolver.ts:76-81	env: { ...scrubbedParentEnv(), ...options.env }（:80）

你的 HostProcess.start() 复述正确。

2. 一个很能说明问题的细节

桌面端在同一批里还注入了 DSH_DESKTOP_NODE_EXECUTABLE 等 DSH_DESKTOP_*，而 scrubbedParentEnv() 的 DSH_ 前缀规则恰好把它们挡掉了 —— 唯独 ELECTRON_RUN_AS_NODE 既不匹配敏感词、也没有 DSH_ 前缀，于是漏网。这正好解释"为什么只有 Electron 系应用失败"：它不是随机漏，是被清洗规则的形状漏掉的。

而且契约层面也站不住：packages/host/open-in-app/README.md 只说 spawn 时用 "a credential-scrubbed environment (scrubbedParentEnv) plus explicit adapter entries" —— 只承诺清洗凭据，没承诺清洗 Electron 选择变量。⇒ 这是契约缺口，不是有意设计。这一句比"这是 bug"更有力。

失败文案来自 resolver.ts:90-95：:90 的 setTimeout(…, options.watchMs) 是 1 秒看护窗，:94 是 `launcher exited with code ${…}, signal ${…}`。你"界面只显示笼统的『请重试』、拿不到退出码"的诉求成立。

3. ⚠️ 你援引的 ptc-runtime-node 先例，语义是反的

你写"仓库里已有正确处理该变量的先例…其实现里也有 key.toUpperCase() !== "ELECTRON_RUN_AS_NODE" 的过滤"。

那行确实存在（packages/ptc-runtime/ptc-runtime-node/src/index.ts:233-235），但它做的是保留、不是清除：

Object.fromEntries(Object.keys(process.env)
  .filter(key => !STARTUP_ENVIRONMENT_NAMES.has(key.toUpperCase())
              && key.toUpperCase() !== 'ELECTRON_RUN_AS_NODE')
  .map(key => [key, undefined]))

被置 undefined（= 删除）的是"非启动变量且不是它"⇒ 它恰恰被留下来。紧邻的 :232 注释也写明了：

// Electron needs its Node-mode selector until bootstrap; the child then removes it with other ambient values.

与 .agents/notes/implemented/architecture/2026-09-11-sandboxed-node-ptc-runtime.md:17 一致。

⇒ 所以它不能当作"清除"的先例援引（反过来说，它是"在需要 Electron 语义的地方必须保留它"的证据，而 open-in-app 恰恰是需要清掉它的地方）。真正同向的先例在这两个测试脚本里：

• apps/desktop/scripts/test-local-updater.mjs:13-14 → filter(([name]) => !/KEY|SECRET|TOKEN|PASSWORD|^NODE_OPTIONS$|^ELECTRON_RUN_AS_NODE$/iu.test(name))
• apps/desktop/scripts/test-signed-updates.mjs:20 同款

把这条援引换掉，报告的可信度会明显不同 —— 否则维护者一查就会发现语义相反。

4. 三条修复路线，我建议的顺序与你的不同

首选：宿主自删。 在 apps/desktop-host/src/index.ts:18 的 main() 起点，或 host-process.ts:199 之后，删掉 process.env.ELECTRON_RUN_AS_NODE。理由：Electron 的 Node 模式选择只在启动那一刻生效，删除不影响该进程自身；此后该宿主的一切子进程（open-in-app、终端、skill、MCP…）都干净，改动面最小。

次选：只治 open-in-app。 resolver.ts:80 之后补一次删除。⚠️ 注意它的类型是 Readonly<Record<string, string>>，写 ELECTRON_RUN_AS_NODE: undefined 会 TS 报错 —— 用 const env = { ...scrubbedParentEnv(), ...options.env }; delete env.ELECTRON_RUN_AS_NODE 更稳。

兜底（建议放最后）：改共享的 scrubbedParentEnv。 语义上最正确，但会撞上一条已被记录的先例：.agents/notes/implemented/testing/2026-09-27-plugin-manager-git-child-environment.md:17 明确写着"改共享 scrubbedParentEnv 会改变所有消费者行为，review 指令排除"，所以那个改动被留在 deferred/git-command-line-config-scrub-20260927 分支上。

⇒ 如果你走这条路，报告里要主动论证"为什么这次应该破例"，否则大概率被同样理由挡回。这也是我把"宿主自删"放首选的原因 —— 它不碰共享面。

5. 版本

你写 0.2.0-rc.2。这条链路在 alpha.1 与 origin/master（= dsh-v0.2.1-alpha.2）上完全一致，所以你引的 app.asar/lib/main.js 对应的源码就是上面那两个文件（node-environment.ts / host-process.ts）。没有过期。

6. 一条边界

catalog.ts:216-228 里 vscode 的 win32 侧 locator 只有 appPaths('Code.exe') / installRecord(...) / file([...])，都没有声明 env ⇒ 无从覆盖泄漏值。对照 :579-587 的 github-desktop 显式写了 env: { ELECTRON_RUN_AS_NODE: '1' } —— 说明该字段确实能覆盖，VS Code 这条只是没写。所以你"也可以在 catalog 层给 VS Code 补一条清掉该变量的 env"这个思路是可行的，可以作为第三条路线（比改共享函数更局部，但比宿主自删要逐应用枚举）。你自己选的路线可以保留这个判断。

至于你说的 "Code.exe 在含该变量时退出码 9" —— 那是你本机的 VS Code 侧行为，我这边没有可比环境，无法复核。但这个缺陷独立成立（无条件向外部应用注入 Electron 选择变量），所以结论不依赖那条实测，建议在报告里把它标为"本机观察"。