[Bug] Desktop 派生的 explorer.exe 被 ELECTRON_RUN_AS_NODE 长期污染，导致此后双击 .md 等 Electron 关联静默失效

[Mr54233]

现象

在 DSH 里点过一次「在资源管理器中打开」之后，在那个资源管理器窗口里双击任何 Electron 应用的文件关联都会静默失效：

• 双击 .md → Typora 不启动，无报错、无弹窗、任务管理器里无残留
• VS Code / Cursor / Obsidian 同理
• 记事本、图片查看器正常

重启资源管理器或重启机器后恢复；再从 DSH 点一次「在资源管理器中打开」，立刻复发。DSH 关闭几小时后仍然发作。

根因：explorer.exe 被 ELECTRON_RUN_AS_NODE=1 长期污染

派生 explorer.exe 的调用链是 path-opener.ts → runNativeCommand() → execFile()，而 packages/util/native-command/src/runner.ts 不传 env，于是 explorer.exe 原样继承宿主进程环境，其中包含桌面端启动 Node 宿主时注入的 ELECTRON_RUN_AS_NODE=1（apps/desktop/src/node-environment.ts 的 desktopNodeEnvironment()）。

explorer.exe 是常驻进程。它一旦带着这个变量启动，就会永久保留，并传给此后用户从它窗口里双击启动的每一个进程。Typora 拿到 ELECTRON_RUN_AS_NODE=1 后不再启动 GUI，而是变成 node 去把 .md 当 JavaScript 编译：

repro_md_test.md:1
# hello
^
SyntaxError: Invalid or unexpected token
    at wrapSafe (node:internal/modules/cjs/loader:1185:20)
    ... Node.js v18.16.1

失败发生在创建窗口之前；Typora 是 GUI 子系统程序（/SUBSYSTEM:WINDOWS）没有控制台，stderr 无人接收 → 用户看到的就是「双击，什么都没发生」。

另外 runExplorer() 还会主动吞掉 explorer 的 exit 1（因为「委派给已有 shell 后退出 1」是正常行为），所以 DSH 日志里也没有任何痕迹。

实测证据

同一时刻两个 explorer 实例，一个干净一个带毒（环境块是直接读 PEB 拿的，不是看 $env:）：

explorer	启动时间	环境变量数	ELECTRON_RUN_AS_NODE
pid 12972（开机 shell）	08:29:18	54	无
pid 40456（由 DSH 派生）	15:41:30	65	=1

HKCU\Environment 与 HKLM\...\Session Manager\Environment 均不含该键 —— 不是系统环境变量，也不是任何配置文件；它只存在于 DSH 的进程子树里。

最小复现

在 DSH 的 shell 里（此时 $env:ELECTRON_RUN_AS_NODE 天然为 1）：

Start-Process explorer.exe '"C:\Users\54\Desktop"'
Start-Sleep 3
Get-CimInstance Win32_Process -Filter "Name='explorer.exe'" | Select ProcessId,CreationDate

新出现的那个 explorer.exe 实例就带着 ELECTRON_RUN_AS_NODE=1，此后它的全部子进程都带毒。

与 #8174 等 28 条同根因报告的区别

#8174 定位的是 packages/subprocess/subprocess/src/index.ts 的 scrubbedParentEnv() 不清洗该键。但本条指向的是另一条泄漏路径：

// packages/util/native-command/src/runner.ts —— 当前 master，完全没有 env 隔离
export const runNativeCommand: NativeCommandRunner = (command, args, signal, window) =>
  new Promise((resolve, reject) => {
    execFile(
      command,
      [...args],
      { encoding: 'utf8', signal, windowsHide: window === 'hidden' },  // ← 没有 env
      (error, stdout, stderr) => { /* ... */ },
    )
  })

runNativeCommand 从不调用 scrubbedParentEnv()。所以即使 #8174 提议的 tombstone 在 subprocess seam 落地，explorer.exe 这条路径依然会泄漏。

而已有的 28 条报告，症状都是一次性的、限于 DSH 内部的、用户可归因的（Open In → VS Code 失败、返回 502、静默无窗口）。本条则是：

• 长期存活 —— explorer.exe 常驻，带毒状态会持续到它退出或被杀
• 跨应用 —— 此后在该窗口里双击任何 Electron 应用都失效
• 跨时间 —— DSH 关掉几小时后仍然发作
• 完全不可归因 —— 用户看到的是「双击 .md 打不开 Typora」，与 DSH 毫无表面关联，正常排查路径（检查文件关联、重装 Typora、检查系统环境变量）全部无效

建议修改

A. 直接修本条（可独立合入）

packages/util/native-command/src/runner.ts：给 execFile 传一个过滤掉 ELECTRON_RUN_AS_NODE 的 env。

安全依据：runNativeCommand 的全部调用点是 explorer.exe / reg.exe / wslpath / defaults / open / xdg-open / xcode-select，没有任何一个需要以 Node 模式运行；而 #8174 评论里担心的 runner 耦合走的是 subprocess-local / sandbox-local 自己的 spawn 路径，不经过这里，所以在这里 tombstone 不会破坏它。

回归测试：仿照 packages/ptc-runtime/ptc-runtime-node/tests/host-failures.spec.ts 的既有先例（那里已经断言过子进程环境里没有该变量），在 packages/util/native-command/tests/ 里注入 process.env.ELECTRON_RUN_AS_NODE = '1'，断言 execFile 收到的 env 不含该键、且 PATH 等变量仍在。

B. 根因修复（配合 #8174）

scrubbedParentEnv() 加 tombstone，并必须同时在两个显式层补回 ELECTRON_RUN_AS_NODE: '1'：

1. packages/subprocess/subprocess-local/src/spawn-runner.ts 的 runnerEnvironment()
2. packages/sandbox/sandbox-windows-acl/src/runner.ts（或其调用方的 env 构造处）

因为这两处的 runner 都是以 [process.execPath, runner.js] 启动、依赖继承才拿到 Node 模式；只加 tombstone 而不补显式层，会让它们静默失去 Node 模式而坏掉 —— 这正是 #8174 评论里 argszero 指出的耦合。

NODE_OPTIONS 属同一类进程级选择器，可一并考虑（目前 RUNNER_CONTROL_ENV_PREFIXES = ['NODE_', 'TSX_'] 只对 runner 生效，普通子进程仍会继承）。

C. 用户侧临时自救

Stop-Process -Name explorer -Force   # 杀掉带毒的常驻实例，桌面闪一下即恢复

注意：在 DSH 的 shell 里 $env:ELECTRON_RUN_AS_NODE = '' 或 = 0 无效 —— Electron 判断的是这个变量的存在性，必须删除（Remove-Item Env:ELECTRON_RUN_AS_NODE）。

环境

Windows 11 专业版 build 26200 · DSH 0.2.1-rc.3（Electron 44.7.0）· Typora 1.8.10（内置 Node v18.16.1）

[Mr54233]

rc5依旧能复现