桌面端「用其他应用打开工作区」对 VS Code/Cursor 等 Electron 应用必然失败（打开失败，请重试）

[KianaMirayi]

桌面端「用其他应用打开工作区」对 VS Code/Cursor 等 Electron 应用必然失败（打开失败，请重试）

摘要

Windows 桌面端里，对工作区目录选择「VS Code」打开时 100% 报 打开失败，请重试。我初步定位到原因可能不在 VS Code：桌面端宿主进程自身带着 ELECTRON_RUN_AS_NODE=1（这是 Electron 桌面壳以 Node 模式运行 dsh 运行时所必需的），而这个开关似乎会随子进程环境一路传下去，导致被启动的 Electron 应用（VS Code / Insiders / Cursor / Windsurf / Zed）以 Node 模式运行、把工作区路径当成 JS 入口文件，报 Cannot find module '<路径>' 并以退出码 1 结束，于是 host 把这次启动判定为失败。

资源管理器、Git Bash、GitHub Desktop 不受影响（前两者走 shell-open，后者自带显式启动环境）。

想请你们确认一下这个定位是否成立。

环境

• DeepSeek Harness 桌面端 0.2.0-rc.2（Windows x64，nightly 通道），签名主体 CN="Hangzhou DeepSeek Artificial Intelligence Co., Ltd."
• @deepseek-ai/dsh-subprocess-local@0.2.0-rc.2、@deepseek-ai/dsh-subprocess@0.2.0-rc.2、@deepseek-ai/dsh-host-open-in-app@0.2.0-rc.2（npm next 标签最新版）
• VS Code 1.139.1，安装在 %LOCALAPPDATA%\Programs\Microsoft VS Code
• 该环境未在用户级/机器级设置 ELECTRON_RUN_AS_NODE，看起来是桌面端在启动 host 子进程时显式注入的

复现步骤

1. 打开桌面端任一工作区（例如 E:\PoliticsLearning）
2. 点会话头部的「用其他应用打开工作区」，选 VS Code
3. UI 提示 打开失败，请重试

实际行为

Code.exe 被以 Node 模式启动：

Code.exe : node:internal/modules/cjs/loader:1575
Error: Cannot find module 'E:\PoliticsLearning'
    code: 'MODULE_NOT_FOUND'

退出码 1。而 host 的启动逻辑是「看护窗口内子进程非 0 退出 ⇒ 启动失败」，所以 UI 显示 打开失败，请重试。

我做了隔离验证（同一台机器、同一个可执行文件，只切换这一个环境变量）：

启动环境	结果
含 ELECTRON_RUN_AS_NODE=1	退出码 1，Cannot find module '<工作区>'
剥除该变量	退出码 0，VS Code 正常打开该目录（对 4 个不同工作区路径逐一确认）

期望行为

选中 Electron 系编辑器时能正常打开对应目录。

我的推测与依据

packages/subprocess/subprocess-local/src/spawn.ts 里构造子进程环境的位置：

export function childEnv(extra?: Readonly<NodeJS.ProcessEnv>): NodeJS.ProcessEnv {
  const env = scrubbedParentEnv()
  if (process.platform !== 'win32') return { ...env, ...extra }
  let entries: [string, string | undefined][] = Object.entries(env)
  ...
}

scrubbedParentEnv() 按我的理解只剔除「凭据形状的名字」（/KEY|PASSWORD|SECRET|TOKEN/i）与 DSH_* 名字，没有剔除 Electron 的 Node 选择器，所以宿主进程的 ELECTRON_RUN_AS_NODE=1 会进入每个被派生的子进程环境，再由 dsh-host-open-in-app 的 launchDetachedApp 原样交给被启动的应用。

另外我注意到同一份代码在另一条路径上已经处理过这个开关（PTC runtime 会显式过滤 ELECTRON_RUN_AS_NODE），只是那处处理似乎没有覆盖到 childEnv() 这条公共路径——这是否属于有意为之，想请你们判断。

想请你们确认：这个推测是否正确？如果正确，在 childEnv() 里补一行是否是可接受的修法？

delete env.ELECTRON_RUN_AS_NODE

我担心的点是它会不会影响真正需要 Node 模式的调用方——不过我看到的几处（桌面端语音 worker、PTC runtime bootstrap、桌面端 pnpm 工具）都是显式传入该变量，而显式合并发生在这个删除之后，所以应该不受影响。这点也请你们把关。

如果这个开关不该在 childEnv() 层处理，而是应该修在别处（例如只在启动外部应用时剥离），也请指个方向。

补充证据

• 受影响范围（按白名单推测）：VS Code、VS Code Insiders、Cursor、Windsurf、Zed 等 Electron 应用
• 不受影响：文件资源管理器、Git Bash（shell-open 路径）、GitHub Desktop（自带 env: { ELECTRON_RUN_AS_NODE: "1" } 显式启动其 CLI）
• 似乎必须经由桌面端才会出现：从普通终端启动的 CLI/Web 场景环境里没有这个开关
• 我比对了本机安装包内 dsh-subprocess-local/lib/runner-launch-B2zsQ1Dz.js（57,475 字节）与 npm 上 @deepseek-ai/dsh-subprocess-local@0.2.0-rc.2 的同名产物：逐字节完全相同，因此这应该是发布产物的原始行为，而不是本地改动或环境差异造成的

[PerryLink]

你初步定位的方向是对的——我把确切代码位置与一个今天可用的规避给你

1. 代码（HEAD = dsh-v0.2.1-alpha.1）

packages/host/open-in-app/src/resolver.ts
:74   export const launchDetachedApp: OpenInAppLauncher = (command, args, options) =>
:80     env: { ...scrubbedParentEnv(), ...options.env },     ← 父环境整体铺开
:148      launch: internals.launch ?? launchDetachedApp,    ← 默认启动器
:584      env: { ELECTRON_RUN_AS_NODE: '1' },               ← 另一分支里显式设置

⇒ "这个开关会随子进程环境一路传下去"成立：:80 把父环境铺开，而清洗只针对凭据（同文件 :60 的注释原文："credential-scrubbed environment (never the harness's *KEY*/*SECRET*…)"）⇒ 运行模式变量不在清洗范围内。⇒ 而且还有 :584 那处显式设置，所以这条链上两处要处理。

2. ⭐ 今天就能用的规避（建议写进帖子）

既然问题出在宿主环境被透传，那么绕开宿主环境的方式都不受影响：

1. 先用「文件资源管理器」打开目录（Explorer 不是 Electron，你已确认它正常），再从那里用 VS Code 打开；
2. 或终端里 code <目录>。

⇒ 修复要等上游，而规避今天就能用——报告里带一条可用规避，其他遇到的人能立刻自救。

3. 你列的受影响应用请保留并突出

你列了 VS Code / Insiders / Cursor / Windsurf / Zed ⇒ 这很有价值：它说明不是某个编辑器的问题，而是"凡 Electron 且被该变量影响者"。⇒ 建议把"资源管理器正常"与"上述 Electron 应用全失败"写成对照，这条对照本身就是机制的证据。

4. 诉求措辞

启动外部应用时不应整体继承宿主环境，而应采用允许清单；至少应剥离宿主专有的运行模式变量（ELECTRON_RUN_AS_NODE 等），而不是只按 *KEY*/*SECRET* 做凭据清洗。

**"凭据清洗 ≠ 环境隔离"**是这句的要害：只要仍是凭据黑名单，下一个宿主变量还会同样泄漏。

5. 版本与互引

你写桌面端（未写版本）；请补版本。⇒ 另有两条同题报告（#8668、#8428）——#8428 对根因的分析最完整。建议三条互引（或由一条作主贴），避免各修一半。