[open-in-app] Windows: Desktop 宿主注入的 ELECTRON_RUN_AS_NODE=1 使 VS Code 等 Electron 应用启动即失败（「打开失败，请重试」）

[mythphi423]

DSH-issue-open-in-app-vscode.md

[PerryLink]

我拿到了确切的注入点——而且这解释了整族"VS Code/Cursor 打不开"的报告

1. 代码

packages/host/open-in-app/src/resolver.ts:584
  env: { ELECTRON_RUN_AS_NODE: '1' },

另外宿主自身也用同一变量（apps/desktop/src/node-environment.ts:15：ELECTRON_RUN_AS_NODE: '1'）。

⇒ open-in-app 在启动外部应用时把 ELECTRON_RUN_AS_NODE=1 传给了子进程。对 DSH 自己的 Node 子进程这是正确且必要的；但对 VS Code / Cursor 这类 Electron 应用，它会让 Electron 以"纯 Node 模式"启动——不创建窗口、直接去找脚本 ⇒ 用户看到的就是"打开失败，请重试"。

这与你观察到的选择性完全吻合：非 Electron 应用正常，Electron 应用必失败。

2. ⇒ 修法（一句可判定的话）

启动外部应用时，子进程环境应当剥掉宿主专有的 ELECTRON_RUN_AS_NODE（以及其它宿主注入变量），而不是整体继承。

建议把诉求写成"应当剥掉哪些变量"（而不是只点名一个），因为 apps/desktop/src/node-environment.ts 里注入的是一组环境变量——凡为"让 DSH 自己的 Node 子进程正常工作"而设的变量，都不该泄漏给第三方 GUI 应用。

3. 这条能一次覆盖多份报告（建议引用）

同在 Q&A 区、同期还有：

• #8304「桌面端『用其他应用打开工作区』对 VS Code/Cursor 等 Electron 应用必然失败」；
• #8428「在 VS Code / Cursor 中打开必现失败：宿主运行模式变量泄漏给子进程」——那条的标题已经点出了同一个机制。

⇒ 「宿主运行模式变量泄漏」这个措辞很准确。请把这三条互引，并把它写成同一个根因：不是"某个应用不支持"，而是"我们注入了不该注入的变量"。三条各修一半是最可能的浪费。

4. 请补两样

1. 一次对照：同一个工作区，用 VS Code（失败）与一个非 Electron 应用（成功）各试一次 ⇒ 这一步就能把"Electron 相关"钉死；
2. 版本：你未写版本（当前最新 0.2.1-alpha.1）。我核到的最新 HEAD 上 resolver.ts:584 仍是如此 ⇒ 这条是当前存活项，无需重测。

一条边界

我确认的是该注入点存在（resolver.ts:584）与宿主注入变量的位置（node-environment.ts:15），足以支撑"变量泄漏导致 Electron 应用以 Node 模式启动"这一解释。VS Code 侧的实际报错/进程行为以你的实测为准——我没有在该环境复现。

[namingsohard]

我也遇到的同样的情况，具体来说现象是这样的：
在选定工作区后，如果尝试使用右上角的【用 VSCODE 打开】（默认是用 文件资源管理器 打开 Ctrl+Alt+O）时，会显示 打开失败，请重试。
原因和上述说明一致，总结原因：

DSH 桌面端自己就是 Electron 程序，它用自带的 Electron 二进制去跑内置的 dsh 运行时，所以它的进程环境里带着 ELECTRON_RUN_AS_NODE=1。启动外部应用的这段代码（@deepseek-ai/dsh-host-open-in-app 里的 launchDetachedApp）在构造子进程环境时只擦掉了 KEY / SECRET 这类凭据变量，没有擦掉 ELECTRON_RUN_AS_NODE。

VS Code 的 Code.exe 也是 Electron 程序。它一继承这个变量就不启动图形界面了，而是把自己当成 Node 解释器，把你传的目录当成 JS 脚本去 require，于是当场报错退出
<<<

*反馈一下，希望能早日修复

[PerryLink]

你的机制描述我核到了确切符号——并给你一个今天就能用的规避办法

1. 你点名的 launchDetachedApp 是对的

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' },               ← 另一分支里显式设置

⇒ 你说的"只擦掉 *KEY* / *SECRET* 这类凭据变量"与 :80 + scrubbedParentEnv 的语义一致（:60 的注释原文即 "credential-scrubbed environment (never the harness's *KEY*/*SECRET*…)"）。⇒ 而且还有第二处：:584 在某个分支里直接把 ELECTRON_RUN_AS_NODE 设成 1 ⇒ 也就是说这条链上有两处要处理。

2. 你补的那半句是很好的诊断

你写：Code.exe 继承该变量后不启动图形界面，而是把自己当 Node 解释器、把传入的目录当 JS 脚本去 require，当场报错退出。

⇒ 这解释了为什么现象是"打开失败，请重试"而看不到任何窗口——失败发生在进程启动那一刻。⇒ 建议把这句放进报告：它让"必然是 Electron 应用失败、资源管理器正常"这一选择性有了机理解释，而不只是统计事实。

3. ⭐ 今天就能用的规避（这条对其他人最有用）

既然问题出在宿主进程的环境变量被透传，那么凡是不经过这个宿主环境的打开方式都不受影响：

1. 先用「文件资源管理器」打开工作区目录（你已确认它是正常的：Explorer 不是 Electron 程序），再从资源管理器里用 VS Code 打开——这样启动 VS Code 的是系统 shell，环境里没有那个变量；
2. 或直接在终端里 code <目录>（同样绕开了宿主的透传路径）。

⇒ 这类"绕开宿主环境"的做法值得写进帖子（哪怕只是临时措施）——因为修复要等上游，而报告里有一个可用规避会让其他遇到的人立刻能用。

4. 修法方向（供你转述）

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

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