Windows 桌面版：受限模式（workspace-write）下 pwsh 工具必然失败 0xC0000142；同一版本经 npx 启动的 Web UI 正常

[sailoumili]

环境

• DSH 桌面版 0.2.0-rc.2（Electron），Windows 10 22H2（10.0.19045，x64）
• 对照组：同一台机器、同一 dsh 版本，用 npx 启动的 Web UI

现象

• 桌面版：会话文件策略为受限模式时，pwsh 工具的任何调用都返回 exit code 3221225794（0xC0000142，STATUS_DLL_INIT_FAILED），连最简单的 echo 也一样。切到 danger-full-access 后，同一条命令立刻正常。
• Web UI：同样是受限模式，pwsh 完全正常（可用子进程的 TEMP 被改写为 <temp>\dsh-<hash> 私有目录，确认沙盒确实在生效）。

两种启动方式的差异（定位到的关键）

	宿主可执行文件	process.execPath
Web UI（npx 启动）	真正的 node.exe	指向 node
桌面版	应用自带的 DeepSeek Harness.exe，以 ELECTRON_RUN_AS_NODE=1 运行（宿主环境变量里可直接看到）	Electron 二进制本身

问题出在哪

@deepseek-ai/dsh-sandbox-local 构造 runner 前缀时用的是：

[process.execPath, <@deepseek-ai/dsh-sandbox-windows-acl 的 runner 入口>]

于是：

• Web UI 下 runner 宿主 = node → 受限执行链正常；
• 桌面版下 runner 宿主 = Electron 二进制（等于再套一层 Electron-as-node）→ 这一层起不来，整条受限执行链失效，工具层把 runner 的启动失败报成了上面的 0xC0000142。

旁证：桌面版进程列表里能看到活的 dsh-subprocess-local/lib/runner.js 子进程（说明「Electron 二进制当 Node 子进程」本身并非一律不可行），但看不到 dsh-sandbox-windows-acl/lib/runner.js 进程。

最小复现

1. Electron 二进制当 Node 用时的子进程行为

在 ELECTRON_RUN_AS_NODE=1 下用 Electron 二进制跑一个脚本：

• spawnSync('cmd.exe', ['/c', 'echo hi']) → status=0，正常返回；
• 紧接着 spawnSync('<PowerShell 7 安装目录>\\pwsh.exe', ['-NoProfile', '-c', 'Write-Output ok']) → 整个进程静默消失（无输出、无退出码）。同步 spawnSync 与异步 spawn 表现一致。

2. 完全照生产写法启动沙盒 runner

<process.execPath> <...>/dsh-sandbox-windows-acl/lib/runner.js \
  --workspace <tmp> --temp <tmp> --mode read-only -- cmd /c exit 0

• 宿主 = node.exe：受限 cmd、受限 pwsh（7.6.6）、受限 powershell.exe（5.1）全部 status=0；
• 宿主 = Electron 二进制（ELECTRON_RUN_AS_NODE=1）：第一步进程就消失，日志断在第一个受限子进程之前。

已排除

pwsh 的来源与版本（商店 MSIX 与官方 MSI 都试过，且在真 node 宿主下受限运行正常）、ACL 与文件权限、受限令牌与 SID、低完整性标签、SystemRoot 缺失、宿主提权（UAC 已关闭）、工作区路径、cmd.exe 与 Windows PowerShell 5.1。

建议

沙盒 runner 不要以 process.execPath 作为宿主：桌面版应改用真正的 Node 解释器（随包内置，或按需解析一个可用的 node），或者在 process.execPath 指向 Electron 二进制时另行选择 node 来启动 runner。

[argszero]

This is the same host variable the 0xC0000142 family is about, seen from the working side: the same version and the same confining mode, failing when the runner is hosted by the packaged desktop binary and working when process.execPath is a real node.exe (the Web UI started from a terminal). @argszero/cordis-plugin-sandbox-grant-advisor@0.10.0 now names this report as the fifth thread of that family in the advisory it attaches to the exit-code case, and the Web UI host is one of the remedies it hands the user — alongside the note that danger-full-access confirms the diagnosis rather than fixing it.