[Bug][Windows] 桌面版受限模式下沙箱 runner 起不来：argv[0] 是 Electron 的 exe，却没人给它 ELECTRON_RUN_AS_NODE

[fangwen9527]

环境

• DSH Desktop 官方封装版（D:\deepseekharness\DeepSeek Harness.exe）：@deepseek-ai/dsh-desktop / dsh-desktop-runtime = 0.1.7-rc.2（app.asar 打包时间 2026-09-24 22:10）
• Windows 11（build 26200）
• 会话文件策略：workspace-write / read-only 可复现；danger-full-access 一切正常
• 未打包的 node 宿主（node apps\cli\lib\bin.js web）不受影响

现象

打包版（桌面端）在受限文件策略下，任何经沙箱 spawn 的命令都可能零输出 + 退出码 0xC0000142（STATUS_DLL_INIT_FAILED）。

根因

@deepseek-ai/dsh-sandbox-local（rc.2 打包代码）在 Windows 上把 runner 的 argv[0] 写成 process.execPath：

// lib/index.js:535-539
windowsAclRunnerInvocation() {
  const override = this.internals.windowsAclRunnerArgs;
  if (override !== void 0) return override;
  const builtEntry = this.internals.windowsAclRunnerEntry ?? fileURLToPath(import.meta.resolve("@deepseek-ai/dsh-sandbox-windows-acl/runner"));
  if (existsSync(builtEntry)) return [process.execPath, builtEntry];   // ← argv[0] = process.execPath
  ...
}

打包版里 process.execPath 是 DeepSeek Harness.exe（Electron）；用 Electron 跑 JS 脚本必须带 ELECTRON_RUN_AS_NODE=1，
否则它按 App 形态启动、原生初始化失败。

全 asar 里设置该变量的只有这几处：dsh-desktop-host、dsh-ptc-runtime-node、dsh-host-open-in-app、
dsh-experimental-speech-to-text-sensevoice。dsh-sandbox-local 与 dsh-subprocess-local 都没有，
宿主进程自身也没有导出它（实测 [Environment]::GetEnvironmentVariable('ELECTRON_RUN_AS_NODE') 为空）。
而 ConfinedArgv 只携带 argv（不带 env），于是「补这个变量」的责任落在 spawn 方 —— 但 spawn 方无从知道 runner 是 Electron 二进制。

复现（同一条命令，只差一个环境变量）

$exe    = 'D:\deepseekharness\DeepSeek Harness.exe'
$runner = 'D:\deepseekharness\resources\app.asar\dsh\node_modules\@deepseek-ai\dsh-sandbox-windows-acl\lib\runner.js'

# A) 带 ELECTRON_RUN_AS_NODE：runner 真的作为 node 跑起来了（打印它自己的用法错误）
$env:ELECTRON_RUN_AS_NODE = '1'
& $exe $runner
# 实测: windows-acl-run: missing --workspace      exit=127

# B) 去掉该变量：什么都没有
Remove-Item Env:ELECTRON_RUN_AS_NODE
& $exe $runner
# 实测: (空输出)

在受限模式下由工具经 subprocess spawn 时，表现为零输出 + 0xC0000142（本机一个第三方插件的「接管前自检」
就是这样拿到该退出码的）。

建议

1. 让 sandbox-local 的 ConfinedArgv 携带 spawn 所需的 env（例如 ELECTRON_RUN_AS_NODE: '1'）；或
2. 由 subprocess-local / desktop-host 在 argv[0] === process.execPath && process.versions.electron 时补齐
   （同仓 dsh-ptc-runtime-node / dsh-host-open-in-app 有现成写法可参考）；或
3. 至少在文档里写明这个前提，好让下游插件能自行兜底。

与沙箱强度无关：这是纯粹的启动方式问题，修它不会放宽任何限制。

[argszero]

A third-party plugin now recognizes this exact exit code at the tool layer and names which of the two measured producers it is: @argszero/cordis-plugin-sandbox-grant-advisor@0.6.0 (source).

Usage — mount it in the profile with the shipped patch:

- insert:
    - id: sandbox-grant-advisor
      name: '@argszero/cordis-plugin-sandbox-grant-advisor'

Relation to this report. Your suggestion 3 — at least document the prerequisite so that downstream plugins can fall back on their own — is the gap this closes, and you were the downstream plugin that hit it: the "pre-takeover self-check" that came back with 0xC0000142 and no output at all is the reading this family was built on. The plugin watches tools/post-execute and reads ToolExecutionSuccess.value, the shell tools' own canonical foreground projection, so the code arrives as the 32-bit integer (-1073741502, or 0xC0000142 in the unsigned spelling your report uses) rather than as text — a command that merely prints the marker cannot be mistaken for it.

That read is necessary here because the pipeline never calls this an error: RUNNER_FAILURE_RULES['windows-acl'] admits exactly one code (allowedExitCodes: [127] with the windows-acl-run: signature), so classifyRunnerFailure skips 0xC0000142, and tool-pwsh reports a nonzero exit as [exit code: N] rather than as an isError result. A diagnosis that only reads failures is structurally blind to this one.

The advisory is delivered once per agent, only under a confining mode (under danger-full-access, or when no sandboxPolicy can be resolved, it stays silent and says so once in the host log instead of guessing). It states the class — the loader terminated the process before its entry point, so there is no output because the program never ran — and then enumerates both producers with the check that separates them. For this one the discriminator is measured, not assumed: the plugin reports whether this process is an Electron binary (process.versions.electron), because that is precisely the fact your root-cause section turns on, and a reader on the unpacked node host must not be told the packaged-desktop story.

Two things it deliberately does not do. It does not set ELECTRON_RUN_AS_NODE for the runner — nothing is spawned on your behalf and no environment is altered, so your fix 1 or 2 upstream remains the real fix; this only names the situation to the session that is stuck. And it never offers danger-full-access as a way out, since that would trade a diagnosis for a silently weaker sandbox.

It repairs nothing. Your report is the authoritative one.

[argszero]

A correction to the plugin note above, from a later report of the same class. @argszero/cordis-plugin-sandbox-grant-advisor@0.7.0 supersedes 0.6.0 here: 0.6.0 described the packaged-desktop producer with a single shape — the runner never runs, because process.execPath is the Electron executable and it launches as an application unless the child carries ELECTRON_RUN_AS_NODE=1 — and then told an Electron reader that a real-node host working out means the runner never ran. #8193 measures the other shape: the desktop launcher does set that variable, the runner runs, and the child still dies, because the restricted token is derived from the Electron process image (packages/sandbox/sandbox-windows-acl/src/token.ts). Both shapes are now named in the advisory, the single-cause sentence is gone, and the check that separates them outside a session (is ELECTRON_RUN_AS_NODE set, and does the ACL runner appear in the host's process tree while the command runs?) is stated rather than implied. This does not change the mechanism in this report — it stops the plugin from claiming that this report's measurement is the only one.