[Bug] 桌面版「在编辑器中打开」对 Electron 系编辑器必然失败 —— ELECTRON_RUN_AS_NODE 泄漏到子进程

[control-lab126]

环境

项	值
DSH	桌面版 0.2.0-rc.2（nightly 通道）
Electron	44.0.0
系统	Windows 11 26H2（build 26300.9457）
编辑器	VS Code（用户级安装，装在非系统盘）
相关包	@deepseek-ai/dsh-host-open-in-app@0.2.0-rc.2

现象

会话页右上角的「在 VS Code 中打开」按钮点击后必然失败，界面提示打开失败。

接口层面直接可复现：

POST /open-in-app/open
{"app":"vscode","path":"<工作区绝对路径>"}

→ HTTP 502
{"code":"launch-failed","message":"failed to launch vscode"}

注意：应用探测是正常的 —— GET /open-in-app/apps 正确返回 {"apps":["explorer","vscode"]}，
说明按钮和 VS Code 条目都在，失败只发生在启动这一步。

根因

DSH 桌面版用 ELECTRON_RUN_AS_NODE=1 把宿主当纯 Node 运行
（desktopNodeEnvironment() 显式设置该变量），因此这个变量常驻宿主进程环境。

启动外部应用时，launchDetachedApp 用 scrubbedParentEnv() 构造子进程环境：

const child = spawn(command, [...args], {
    detached: true,
    stdio: "ignore",
    windowsHide: options.windowsHide,
    env: {
        ...scrubbedParentEnv(),
        ...options.env
    }
});

而 scrubbedParentEnv()（@deepseek-ai/dsh-subprocess）只过滤两类：

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

即「凭据类变量（*KEY*/*SECRET*/*TOKEN*/*PASSWORD*）」和「DSH_ 前缀」。

ELECTRON_RUN_AS_NODE 两条都不匹配，因此被原样传给被启动的程序。

VS Code 的 Code.exe 本身也是 Electron，看到该变量就不启动 GUI，改以 Node 模式运行，
把工作区路径当作 JS 入口脚本去 require：

Error: Cannot find module '<工作区绝对路径>'
    at node:internal/modules/cjs/loader...
Node.js v24.21.0

进程随即以退出码 1 结束。而 launchDetachedApp 的监视逻辑规定：

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

→ 在监视窗口内非 0 退出即判为失败 → 路由返回 502 → 前端报错。

复现 / 对照实验

同一个可执行文件、同样参数，只差一个环境变量：

条件	退出码	结果
带 ELECTRON_RUN_AS_NODE=1（DSH 的实际行为）	1	Error: Cannot find module '<工作区>'，VS Code 不出现
不带该变量	0	VS Code 正常打开并定位到工作区

# 复现（模拟 DSH 的调用）
$exe = '<编辑器安装目录>\Code.exe'
$ws  = '<工作区绝对路径>'
$psi = [System.Diagnostics.ProcessStartInfo]::new()
$psi.FileName  = $exe
$psi.Arguments = '"' + $ws + '"'
$psi.UseShellExecute = $false
# $psi.EnvironmentVariables.Remove('ELECTRON_RUN_AS_NODE')   # 去掉这一行注释 → 退出码变 0
$p = [System.Diagnostics.Process]::Start($psi)
$p.WaitForExit(15000) | Out-Null
$p.ExitCode

影响面

会失败 ❌	正常 ✅
VS Code、VS Code Insiders、Cursor、Windsurf、VSCodium 等所有 Electron 系编辑器	Sublime Text、JetBrains 全家桶、explorer（文件管理器）等非 Electron 应用

因此菜单里的「在文件管理器中显示」是好的，只有 Electron 系编辑器打不开。

在 Windows 桌面上该问题 100% 复现；非桌面入口（如从普通终端启动）也可能受影响，因为
dsh 的命令包装脚本本身也会设置该变量。

建议修复

最小改动 —— 在合并适配器显式 options.env 之前剔除继承来的该变量：

  const child = spawn(command, [...args], {
      detached: true,
      stdio: "ignore",
      windowsHide: options.windowsHide,
-     env: {
-         ...scrubbedParentEnv(),
-         ...options.env
-     }
+     env: ((inherited) => {
+         delete inherited.ELECTRON_RUN_AS_NODE;
+         return { ...inherited, ...options.env };
+     })(scrubbedParentEnv())
  });

顺序很关键：必须在合并 options.env 之前清除。因为 catalog 里已有条目
（如 GitHub Desktop）故意声明 env: { ELECTRON_RUN_AS_NODE: "1" } 来运行它自己的
cli.js；若在合并之后删除，会破坏那类条目。

另一种等效做法是给 catalog 中 vscode / cursor / windsurf 等 GUI Electron 条目加
env: { ELECTRON_RUN_AS_NODE: undefined }，利用已有的 options.env 覆盖机制。

顺带一提：@deepseek-ai/dsh-host-open-in-app 里 launchDetachedApp 在
lib/index.js 与 lib/types/resolver.js 各有一份同样写法，两处都需要改。

临时绕过（用户侧）

无需改代码即可先用起来：

• 在 VS Code 里手动「打开文件夹」，或从资源管理器右键打开工作区；
• 菜单里的「在文件管理器中显示」可正常使用。

附：诊断用到的可观测点

• GET /open-in-app/apps → 应用探测结果（本例为正常）
• POST /open-in-app/open → 启动结果与失败码（本例 502 launch-failed）
• 对照实验的退出码差异，可精确定位到环境变量泄漏而非探测失败

[argszero]

Mechanism confirmed in the tree — and the two-arm experiment you ran (same binary, same argv, one variable different) is what makes this immediately actionable.

• packages/subprocess/subprocess/src/index.ts:47 — export const SENSITIVE_ENV_PATTERN = /KEY|PASSWORD|SECRET|TOKEN/i; the scrub at :69 keeps every name that is neither credential-shaped nor DSH_-prefixed. ELECTRON_RUN_AS_NODE matches neither, so it survives.
• The launch site is packages/host/open-in-app/src/resolver.ts:74-80 (env: { ...scrubbedParentEnv(), ...options.env }), so the launcher's child inherits the same base every other harness child does — the leak is not specific to the editor path.

Three things worth adding:

1. The pattern is "allow everything that is not credential-shaped", and that cannot express "do not forward host-runtime control variables". So each such variable is a separate bug, and this one is worse than a leak: the forwarded name is not a credential but a process-mode switch, which is why the outcome is a hard 502 on a healthy-looking install rather than a suspected-secret. The general shape that stops the class is an explicit deny list of interpreter/electron runtime switches (ELECTRON_RUN_AS_NODE, NODE_OPTIONS, and their kin) next to the credential pattern, rather than relying on the credential regex to catch non-credentials.

2. This one is not plugin-reachable, so it needs an in-tree change. The scrub is core (@deepseek-ai/dsh-subprocess), and the launch happens inside @deepseek-ai/dsh-host-open-in-app's own launchDetachedApp; internals.launch is a module-internal test seam (packages/host/open-in-app/src/internals.ts), not a configuration a separate plugin can supply. There is no supported seam for a third-party package to replace a host launcher's environment.

3. The failure is arguably worse than "the button does not work". Because launchDetachedApp treats a non-zero exit inside its watch window as launch failure, every Electron-based target fails identically, while a non-Electron editor opens normally — so the symptom reads as "VS Code is unsupported" rather than "one variable leaked". Worth stating in the report title/body if you edit it, since the fix is one allow/deny decision away from working.

Your diagnosis of the exit path (Code.exe re-entering Node mode and require-ing the workspace path) is exactly consistent with what we see: exit code 1 with Cannot find module '<workspace>', not a spawn error.