[Bug][Windows][桌面版] 在 VS Code / Cursor 中打开必现失败：宿主运行模式变量泄漏给子进程

[HAHAide]

平台：Windows 10 x64 (19045) ｜ DSH 桌面版 44.0.0（未做任何修改的原始安装），profile desktop 实测：VS Code 1.139.1、Cursor

症状
桌面版 Web GUI 右上角「在应用中打开」→ 选 VS Code / Cursor，必现红色「打开失败，请重试」。同菜单的文件资源管理器正常。

根因
桌面外壳为了让 Electron 以「纯 Node 模式」运行 dsh 宿主进程，会在启动它时设置 ELECTRON_RUN_AS_NODE=1。该变量留在了宿主进程的环境里，而 open-in-app 在启动编辑器时会把父进程环境透传给子进程——它只做凭据清洗（KEY / SECRET 一类），不区分运行模式变量，因此这个标志也一并传了下去。

VS Code、Cursor 等都是 Electron 应用：它们在启动时读取该变量来决定「当 GUI 运行还是当 Node 运行」。读到 1 就进入 Node 模式——不创建窗口、把命令行参数当作脚本路径去找、找不到便直接退出，退出码非零。

而 open-in-app 的判定逻辑是「子进程在观察窗口内以非零码退出 = 启动失败」，于是返回 502 launch-failed，前端显示为「打开失败，请重试」。

关键点：应用发现与路径解析本身是成功的（VS Code 能被正确找到并解析出可执行文件路径），失败发生在子进程启动之后。因此错误信息与实际原因方向相反：它提示 failed to launch vscode，容易把人引向「VS Code 没装好或路径不对」，而真正的原因是环境变量继承。

最小复现
在持有该变量的环境中，按同样方式启动 VS Code：

确认当前进程环境里存在 ELECTRON_RUN_AS_NODE=1（桌面版宿主即如此）；
以 detached、无 stdio 的方式启动 VS Code 可执行文件，并把一个目录作为参数传入；
观察结果：子进程立即以退出码 1 结束，且没有窗口出现；
从环境中删除该变量后重复第 2 步：窗口正常打开。
为排除干扰，实验前应先彻底终止所有 VS Code 进程——它是单实例应用，已有实例在运行时新进程会把请求转交并以 0 退出，会掩盖真实行为。

验证情况
现象实测（两个独立应用）：在原始安装的桌面版 44.0.0 上，VS Code 与 Cursor 均必现失败。

两个不同的编辑器出现完全相同的行为，可以排除「某个编辑器自身安装有问题」这一类解释——它们唯一的共同点就是都会继承同一个父进程环境。

已成功消除该症状的方法：在宿主进程内删除该运行模式变量。

具体做法是以一个本地插件挂载到用户的 profile 配置上；该插件加载进宿主进程后，只从本进程的环境中移除 ELECTRON_RUN_AS_NODE。此后 open-in-app 启动编辑器时读到的父环境已不含它，子进程不再继承，VS Code 与 Cursor 均恢复正常。

之所以安全：Electron 只在启动那一刻读取该变量来决定运行模式，而插件加载时该决定早已完成——删除它不会改变当前进程自身的运行方式，只影响之后被启动的子进程。真正依赖该变量的适配器是自行显式声明的（例如目录中 GitHub Desktop 的条目），不依赖继承，因此不受影响。改动范围仅限本进程环境，不涉及系统设置、注册表或安装文件，并随进程重启失效。

备注
已排除：文件权限、沙箱隔离、VS Code 安装损坏、未安装系统 Node、VS Code 安装路径。

本文档由 AI 分析生成：DeepSeek v4.1F。

[PerryLink]

你的根因分析完全正确，我把两处确切位置给你

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

packages/host/open-in-app/src/resolver.ts
:9   * adapters spawn detached with a credential-scrubbed environment and their …
:22  import { scrubbedParentEnv } from '@deepseek-ai/dsh-subprocess'
:60  * credential-scrubbed environment (never the harness's `*KEY*`/`*SECRET*` …
:80    env: { ...scrubbedParentEnv(), ...options.env },

⇒ :80 把父进程环境整体铺开，而"清洗"只针对凭据（*KEY* / *SECRET*，:60 逐字写着）⇒ 运行模式变量不在清洗范围内 ⇒ ELECTRON_RUN_AS_NODE 原样传给编辑器必然发生。

另有一处更直接：:584 在某个分支里显式设了 env: { ELECTRON_RUN_AS_NODE: '1' } ⇒ 所以这条链上有两处要处理（一处置"泄漏"，一处置"主动设置"）。

2. 你写的"只做凭据清洗"是关键——建议作为诉求的着力点

你把清洗范围的语义点出来了：凭据清洗 ≠ 环境隔离。⇒ 建议诉求写成：

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

"黑白名单之争"这一句很值钱：只要仍是"凭据黑名单"，下一个宿主变量还会以同样方式泄漏。

3. 与同族报告互引（建议）

同在 Q&A 区、同期另有 #8668（标题即"宿主注入的 ELECTRON_RUN_AS_NODE=1 使 VS Code 等 Electron 应用启动即失败"）与 #8304（"对 VS Code/Cursor 等 Electron 应用必然失败"）。⇒ 三条说的是同一件事，你这条的根因分析最完整（点明了清洗范围）。建议你这条作为主贴，另两条引用过来。

4. 可复现性与版本

你的复现是确定性的（未改动的原始安装、必现、同菜单的文件资源管理器正常 ⇒ 天然对照）。⇒ 建议补一句对照：同一个菜单里非 Electron 应用正常这一点，直接指向"Electron + 该变量"这一组合。

我核到的 :80/:584 在当前最新版仍在 ⇒ 无需在新版重测即可确认存活。