[Bug][Windows][桌面端] 「更多打开方式」启动 VS Code 等 Electron 应用失败：ELECTRON_RUN_AS_NODE 泄漏使目标以 Node 模式启动并立即退出

[YOUKNOWWHOOO]

摘要

官方桌面端（@deepseek-ai/dsh 0.2.0-rc.2）会话头部的「更多打开方式」菜单中，选择 VS Code 会立即弹出「打开失败，请重试」，且系统中不会出现任何 VS Code 进程；同一菜单里的「文件资源管理器（默认）」在同一时刻、对同一目录工作正常。

定位结论：桌面端 Host 为把 dsh 服务以 Node.js 模式运行而设置的环境变量 ELECTRON_RUN_AS_NODE=1，被原样传给了它启动的外部应用。VS Code 是 Electron 应用，检测到该变量后以 Node.js 模式启动而非 GUI 模式，随即退出（本机实测退出码 1）。Host 把「子进程在看护窗口内以非零退出码结束」判为启动失败，返回 502，前端显示该提示。

复现步骤

1. 启动官方桌面端，打开任一已有工作区的会话。
2. 点击会话头部右上角「更多打开方式」的下箭头，菜单出现三项：文件资源管理器（默认）、VS Code、Git Bash。
3. 选择「VS Code」。
4. 预期：VS Code 打开该会话的工作区目录。实际：界面出现「打开失败，请重试」，且系统中不产生 VS Code 进程。

对照：在同一菜单里选择「文件资源管理器（默认）」，该目录可正常打开。

环境

• 操作系统：Windows 11 家庭版 中文版，25H2，版本 10.0.26200，内部版本 26200.8246，64 位，AMD64。
• 官方桌面端：DeepSeek Harness 0.2.0-rc.2，per-user 安装于 %LOCALAPPDATA%\Programs\DeepSeek Harness。
• 桌面端运行时：Electron 44.0.0，内置 Node.js 24.18.1，Chromium 152.0.7977.54。
• 桌面端 Host：以 Electron utility process 为父进程、以 ELECTRON_RUN_AS_NODE=1 拉起的 Node.js 服务，监听 127.0.0.1:19387。
• 桌面端 profile：desktop。
• 被启动的应用：Visual Studio Code 1.139.1，per-user 安装于 %LOCALAPPDATA%\Programs\Microsoft VS Code；其 App Paths\Code.exe 注册项与卸载记录均指向实际存在的可执行文件（该可执行文件可被独立启动并正常打开目录）。
• 观测时间：2026-09-30（UTC+8）。

位置

• 前端触发点：dsh-client-ui-open-in-app，目录场景的 launch() 向 POST /open-in-app/open 发送 { app, path }，非 2xx 即显示 path.openError（「打开失败，请重试」）。

• 后端路由：dsh-host-open-in-app 在 ctx.webServer 上注册的 POST /open-in-app/open，命中即调用 launchResolved(resolved, path, config.launchWatchMs, …)。

• 启动实现：同包内的 launchDetachedApp，其子进程环境为 { ...scrubbedParentEnv(), ...options.env }。

• 环境清洗规则：dsh-subprocess 的 scrubbedParentEnv() 只剔除两类名字——匹配 /KEY|PASSWORD|SECRET|TOKEN/i 的，以及全部 DSH_* 前缀的。ELECTRON_RUN_AS_NODE 不在剔除范围内；VS Code 的启动器也未在 options.env 里覆盖它。

• 变量来源：dsh-desktop-host/lib/index.js 在为 dsh 服务构造启动环境时显式写入：

  env: {
    ELECTRON_RUN_AS_NODE: "1",
    DSH_DESKTOP_NODE_EXECUTABLE: process.execPath,
    PATH: `${process.argv[6] ?? ""}${delimiter}${process.env.PATH ?? ""}`
  }

  该变量对 dsh 服务本身是必需的（让它以 Node.js 而非 Electron 模式运行），但它随后的每个子进程都会继承，其中就包括「用某应用打开目录」这条路径启动的外部程序。

观测证据

以下四项在同一台机器上取得。为区分「点击未送达」与「后端失败」，页面上的一切交互均通过 DevTools 协议派发真实鼠标事件（Input.dispatchMouseEvent），并直接读取页面内 fetch 的返回。

一、后端返回 502，且失败发生在毫秒级

在桌面端页面上下文内直接请求同一端点：

{
  "at": "2026-09-30T14:11:28.781Z",
  "status": 502,
  "body": "{\"code\":\"launch-failed\",\"message\":\"failed to launch vscode\"}",
  "elapsedMs": 89
}

三次重复的耗时分别为 94 ms、119 ms、89 ms。桌面端 composition 中 launchWatchMs 取值为 1000（毫秒），因此这不可能是「看护窗口超时」，只能是子进程在看护窗口内提前失败。

二、目标进程确实被创建，并在约 86 ms 后退出

在触发请求的同时以 40 ms 间隔轮询系统进程表：

发现的新 Code 进程: 1
PID=10160 启动=22:11:28.786 已退出=True 退出码=(空) 存活约86ms

即 Code.exe 被成功 spawn（不是 ENOENT 类的启动失败），但在极短时间内就结束了。请求在 22:11:28.781 发出、进程于 28.786 创建，两者相差 5 ms。

三、对照实验：ELECTRON_RUN_AS_NODE 是唯一分界

在同一台机器上以两种环境分别启动同一个 Code.exe，参数均为「打开某个目录」：

条件	结果
不设 ELECTRON_RUN_AS_NODE	进程持续存活，系统中出现 VS Code 的进程组（观测到 10 个进程），目录被打开 ✅
设 ELECTRON_RUN_AS_NODE=1	进程立即退出，退出码 1，未出现任何 VS Code 进程 ❌

第二种情形与故障现场观测到的「约 86 ms 后退出」一致。

四、变量确实存在于 Host 的子进程环境中

桌面端主进程自身的环境里没有该变量（mainProcessHasVar: false），说明它不是从用户会话或启动器继承来的；它由 dsh-desktop-host 在拉取 dsh 服务时写入（见上文「位置」一节的源码片段），而 dsh 服务正是那个承担「打开目录」职责的进程。

为什么其它入口不受影响

同一菜单里的三项走的是不同代码路径，这解释了「只有 VS Code 失败」这一现象：

菜单项	启动方式	是否受影响
文件资源管理器（默认）	shell-open：交给操作系统 shell 的「打开」动词，不直接 spawn 目标程序	不受影响（该路径在实现上也不会判失败）
VS Code	argv：spawn(Code.exe, [目录])，继承清洗后的父环境	受影响
Git Bash	同为 argv：spawn	非 Electron 程序，ELECTRON_RUN_AS_NODE 对其无效果，预期不受影响

影响面

• 凡是通过该路径启动、且自身是 Electron 应用的目标都会失败。判断依据是框架层行为而非各应用自己的实现：Electron 在启动时检测到 ELECTRON_RUN_AS_NODE 就会进入 Node.js 模式，因而所有以 Electron 构建的程序都落在这个范围内。按应用目录登记，VS Code、VS Code Insiders、Cursor、Windsurf 属此类；而 Zed、Sublime Text、JetBrains 系 IDE 不是 Electron 程序，不在其列。用户看到的一律是「打开失败，请重试」，且没有指向真实原因的诊断信息。
• 非 Electron 的启动器（终端、Git GUI、文件管理器）不受影响，因此症状看起来像「只有某个应用坏了」，容易误导排查方向。
• 同一环境下 web 端不受影响：web 端的 dsh 由普通 Node.js 进程启动，其环境中不存在该变量，因而同样的操作正常。这也是本问题只在官方桌面端出现的原因。

建议

问题出在「dsh 自身需要的 Node 模式标志」与「它启动外部 GUI 应用所需的环境」之间没有隔离。两个可选修复方向：

1. 在启动外部应用时剔除该变量（推荐，改动局部）：dsh-host-open-in-app 的 launchDetachedApp 在构造子进程环境时，从 scrubbedParentEnv() 的结果中删除 ELECTRON_RUN_AS_NODE。理由是该变量只对「把 dsh 自身跑成 Node 进程」有意义，而对外部 GUI 应用是有害的；把它一并交给被启动程序，在任何场景下都不是期望行为。
2. 在 Host 侧不以环境变量传递该模式：dsh-desktop-host 改以其它机制让 dsh 服务以 Node 模式运行（例如沿用已经传入的 --expose-internals 等命令行参数，而不设置 ELECTRON_RUN_AS_NODE），从源头避免它对整棵子进程树可见。

若短期内不便改动，可考虑在启动失败时把子进程的退出码与信号写入返回体或日志（当前 502 只给出 failed to launch <id>），使同类问题能被直接定位，而不必依赖外部工具观测。