Windows] workspace-write 沙箱下所有受限子进程以 0xC0000142 退出（打包版把 Electron 二进制当作 ACL runner）

[3water06]

[Windows] workspace-write 沙箱下所有受限子进程以 0xC0000142 退出（打包版把 Electron 二进制当作 ACL runner）

可直接粘贴到上游 issue。所有结论都是本机实测，不是推测。

环境

• DSH Desktop 0.2.0-rc.2，安装于 C:\Users\Administrator\AppData\Local\Programs\DeepSeek Harness\
• Windows 11 25H2，build 26200.9550
• 后端以 Electron 二进制运行：ELECTRON_RUN_AS_NODE=1，process.execPath = DeepSeek Harness.exe（244 MB）
• PowerShell 7.6.6（C:\Program Files\PowerShell\7\pwsh.exe），系统 node v24.21.0

现象

文件策略	结果
read-only	正常
workspace-write	每条命令都是 (no output) + [exit code: 3221225794]
danger-full-access	正常（不经过沙箱）

3221225794 = 0xC0000142 = STATUS_DLL_INIT_FAILED。命令完全没有执行（无输出、无副作用）。

根因

@deepseek-ai/dsh-sandbox-local/lib/index.js 的 windowsAclRunnerInvocation()：

const builtEntry = this.internals.windowsAclRunnerEntry
  ?? fileURLToPath(import.meta.resolve("@deepseek-ai/dsh-sandbox-windows-acl/runner"));
if (existsSync(builtEntry)) return [process.execPath, builtEntry];

打包形态下 process.execPath 是 Electron 主程序，于是 windows-acl runner 自己就是以 Electron 进程镜像运行的。该 runner 铸造 WRITE_RESTRICTED + Low integrity 的受限令牌，再从该令牌 spawn 受限子进程；在 workspace-write 下受限子进程死在 DLL 初始化阶段。

runner 本身没有失败（它自己的失败签名是 exit 127 + stderr windows-acl-run: ），所以宿主把 0xC0000142 当作目标进程的退出码上报，最终表现为「空结果」，掩盖了真正的失败位置。

证据（同一 token recipe / 授权 / stdio / env，只改 runner 的进程镜像）

ACL runner 镜像	模式	结果
Electron（ELECTRON_RUN_AS_NODE=1）	workspace-write	子进程 exit 3221225794
node.exe	workspace-write	exit 0，输出正常
Electron	read-only	exit 0

补充对照（都排除了）：

• 外层 subprocess runner 的镜像无关：Electron 外层 + node ACL runner 成功；node 外层 + Electron ACL runner 失败。
• 继承来的 Electron 令牌无害：父进程是 node 或 Electron，只要 ACL runner 是 node.exe，两者都成功。致命的是「由 Electron 进程铸造令牌」。
• 不是 --write-sid / --temp-write-sid 造成的：workspace-write 不带 SID 参数同样失败。
• 不是目标程序造成的：cmd.exe / node.exe / pwsh.exe 三种目标全部以 0xC0000142 退出。
• 不是 windowsHide / CREATE_NO_WINDOW：runner 侧 true/false 都失败。
• 不是 stdio 布局或 fd 7 控制通道：inherit/pipe、有无控制通道四种组合在 node ACL runner 下全部成功。
• 不是权限/授权缺失：缺授权时 runner 自己是 exit 127 + windows-acl-run: 签名，与用户看到的错误不同。

复现脚本（node，无第三方依赖）：直接以
node <runner.js> --workspace <dir> --temp <dir> --mode workspace-write [--write-sid … --temp-write-sid …] -- <cmd>
运行 runner，把第一段的解释器换成 DeepSeek Harness.exe（ELECTRON_RUN_AS_NODE=1）即复现 0xC0000142，换成 node.exe 即恢复正常。

建议修复

打包形态下不要用 process.execPath 作为 runner 的解释器，改用真实 node 可执行文件。本安装自带：

<install>\resources\runtime\primary-runtime\dependencies\node\bin\node.exe   (v24.21.0)

例如在 windowsAclRunnerInvocation() 中：当 process.versions.electron !== undefined 时优先使用该内置 node（注意普通 node.exe 读不了 app.asar 内的文件，runner 需要以可读路径提供，或把 runner 及依赖解包到 app.asar.unpacked）。

临时规避（用户侧）

1. 文件策略改为 read-only（有隔离、可执行，但不可写，且 PowerShell 处于 ConstrainedLanguage、非 ASCII 输出可能乱码）；
2. 或用一个宿主插件在启动时覆写 provider 的测试钩子：
   ctx.sandbox.internals.windowsAclRunnerArgs = [<real node.exe>, <runner.js 的 asar 外可读副本>]
   （internals 是 dsh-sandbox-local 自带的 test hook，位置见 lib/index.js:259，windowsAclRunnerInvocation() 每次执行都会读取它，因此运行期覆写立即生效；不需要改 app.asar。）

相关背景

• app.asar 的 Electron fuse 中 EnableEmbeddedAsarIntegrityValidation 为 enabled，所以「直接改 app.asar 里的这一行」不是安全的用户侧方案；EnableNodeOptionsEnvironmentVariable 为 disabled，因此也不能靠 NODE_OPTIONS 注入。
• 该缺陷与「空结果但 exit 0」的另一种表现（ELECTRON_RUN_AS_NODE 未注入时 runner 退化为启动第二个 GUI 实例、静默自杀）是同一处设计问题的不同分支，但退出码不同：本 issue 是 3221225794，那一种是 exit 0 + 零输出。

[argszero]

Your isolation is the cleanest I have seen for this cause, and the invariant it falsifies is stated in the code itself.

packages/sandbox/sandbox-local/src/index.ts:565-583:

/**
 * ... The prefix stays `[node, runner, ...]` — a future native-exe runner keeps
 * the same argv contract and only swaps these entries.
 */
private windowsAclRunnerInvocation(): string[] {
  const override = this.internals.windowsAclRunnerArgs
  if (override !== undefined) 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]
  ...

and a test that states the same belief as a comment — packages/sandbox/sandbox-local/tests/local.spec.ts:470-473: "windowsAclRunnerInvocation always yields [node, ...] in product". In the packaged desktop process.execPath is the Electron binary, so the node in that prefix is not node: the runner itself is the Electron image, and the restricted token is cast from it. Your arm that changes only the runner image (node.exe ⇒ exit 0, Electron ⇒ 3221225794, with the same token recipe, grants, stdio and environment) is what turns that from a hypothesis into the mechanism.

Two notes that may help the fix land:

• The repository already ships the executable the invariant assumes. The desktop carries a standalone Node at resources/runtime/primary-runtime/dependencies/node/bin/ (apps/desktop/README.md:279), and the desktop README documents that distribution as the one package operations must execute. The runner prefix is the only place I can see that still assumes process.execPath is node.
• The published analyzer for this family, @argszero/cordis-plugin-sandbox-grant-advisor@0.22.0 (npm), already records "the restricted token is derived from the Electron process image" as a native-init producer, and its diagnostic separates it from the second producer (a restricting list containing a non-token SID). Your report is the sharper isolation of the first, and the analyzer's remedy text points at that same standalone Node. To be clear about its limits: it is a diagnostic, not a fix — the change belongs in windowsAclRunnerInvocation.

[zlystyle369-cpu]

Adding an independent environment sample. Symptoms and conclusions match the OP's, but the shell, install path and Windows build are all different, so those variables can be ruled out.

Environment

• DSH Desktop 0.2.0-rc.2 (FileVersion = 0.2.0-rc.2), installed at E:\软件\deepseek harness\ (non-default path, not under AppData)
• Windows 11 24H2, build 26100.2454, 64-bit
• Commands are actually executed by Windows PowerShell 5.1 ($PSVersionTable = 5.1.26100.2161) — pwsh is not on PATH on this machine, so the host falls back to 5.1
• Update channel: resources/app-update.yml reports channel: nightly
• Bundled Node is present: E:\软件\deepseek harness\resources\runtime\primary-runtime\dependencies\node\bin\node.exe

Reproduction

File policy	Result
workspace-write	Every command returns (no output) + [exit code: 3221225794], including side-effect-free commands like echo
danger-full-access	The identical command succeeds

Consistent with the OP. Three additions:

Same DSH build, different Windows build. This machine is on 0.2.0-rc.2 — identical to the OP's — while running Windows 11 24H2 (26100.2454) against the OP's 25H2 (26200.9550). The defect therefore reproduces on the shipped build across Windows build revisions, not on a local configuration.

Shell independence is confirmed further. The OP runs PowerShell 7.6.6; this machine runs PowerShell 5.1. Both fail. That rules out "a specific PowerShell version / .NET Framework failing to initialize under a restricted token."

No WER record, consistent with dying inside DLL initialization. Across the four hours surrounding the failures, the Windows Application log contains zero Application Error, .NET Runtime, and SideBySide events. Two further items are also excluded:

• HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows has AppInit_DLLs empty and LoadAppInit_DLLs = 0 — there is no global DLL injection.
• The install directory contains no standalone executable whose name matches sandbox / restrict / appcontainer. This install therefore matches the general release: the sandbox is implemented entirely in JS inside app.asar, with no native runner as a fallback. (This check is limited by packaging — filenames inside app.asar are not visible.)

One addition

The bundled Node path suggested in the proposed fix exists in this install as well, with the same layout the OP describes. On a more structural fix: a comparable desktop AI product (WorkBuddy) ships its Windows sandbox as a compiled standalone executable (vendor/sandbox/<ver>/sandbox-cli.exe plus tsbx.dll and a rules file), launched by its own path — there is no "which interpreter am I" inference step at all. As long as the runner's interpreter is still resolved through process.execPath, that invariant will keep failing in packaged form. Switching to the bundled Node is a precise fix; compiling the runner into a standalone executable would remove this class of problem structurally.

[Pretty-Na2CO3]

独立复现：同一份 runner，只换解释器即可切换这个缺陷的成败

环境（与 OP 及楼下样本都不同，用于排除环境变量）

项	值
DSH Desktop	0.2.0-rc.2，安装于 非默认路径 E:\dsh\
OS	Windows 11 家庭中文版 24H2，build 26100.4946，x64
命令实际由	Windows PowerShell 5.1 执行（本机未安装 pwsh 7，主机回落到 5.1）
杀软	Windows Defender + 火绒安全软件
会话文件策略	workspace-write 全挂，read-only 正常，danger-full-access 正常

方法：让两臂执行逐字节相同的 runner

app.asar 里的 runner 用普通 node.exe 跑不了（Error: Cannot find module），所以先把它的完整模块图解包到 asar 外：以 runner.js 为起点递归解析裸导入（得到 14 个包，含 dsh-subprocess / dsh-win32-process / dsh-lazy-require / dsh-skill / yaml / cordis / schemastery …），koffi 从 asar 取结构 + 从 app.asar.unpacked 覆盖 .node。

然后只改解释器这一个变量：

$runner = '<解包目录>\node_modules\@deepseek-ai\dsh-sandbox-windows-acl\lib\runner.js'

# 臂 A：真实 node（<install>\resources\runtime\primary-runtime\dependencies\node\bin\node.exe, v24.21.0）
& node.exe $runner --workspace <ws> --temp <tmp> --mode workspace-write -- powershell.exe -NoProfile -Command 'exit 7'

# 臂 B：Electron 二进制（ELECTRON_RUN_AS_NODE=1）
& '<install>\DeepSeek Harness.exe' $runner --workspace <ws> --temp <tmp> --mode workspace-write -- powershell.exe -NoProfile -Command 'exit 7'

探针用 exit 7，子进程不需要碰文件系统，退出码本身就能区分"跑到了用户态"与"死在加载器初始化"。

结果（各重复 2 次，确定性）

ACL runner 解释器	模式	退出码	判定
真实 node.exe v24.21.0	workspace-write	7	✅ 子进程正常启动
Electron 二进制	workspace-write	-1073741502	❌ 0xC0000142
真实 node.exe	read-only	0 / 正常	✅
Electron 二进制	read-only	0 / 正常	✅

在同一个 A/B 里，DSH 版本、runner 字节、沙箱源码、工作区、临时目录、探针命令、令牌配方全部相同，唯一的变量是解释器。 因此本机数据支持本线程提出的机制：打包形态下 windowsAclRunnerInvocation() 返回 process.execPath，受限令牌由 Electron 进程镜像铸造，于是 workspace-write 的受限子进程死在 DLL 初始化。

两点补充

1. read-only 在两种解释器下都正常，所以差异只落在 workspace-write 的令牌铸造路径上——与"Electron 镜像铸造令牌"这一解释一致，也与 Desktop (Windows): every shell command dies at startup with 0xC0000142 under workspace-write #9621 里"read-only 全部正常"的观察一致。
2. "连 runner 的失败报告都没有"是设计使然，不是独立故障。 组装模块图的过程中我确实触发过 runner 自身的失败路径，它的表现与文档一致：stderr: windows-acl-run: Cannot find module … + exit 127。而用户看到的 0xC0000142 是子进程的退出码，runner 只是如实镜像它，所以不会带那条签名。

与另一条候选假设的关系

#9621 的评论里提出 subprocess-local 的 useConptyDll（console host 差异）作为候选。本复现不否定那个方向，但它不是解释本缺陷所必需的：在解释器成为唯一变量时，缺陷已经完整复现。

站内可用的临时规避（对本机同样有效）

把 runner 的解包副本 + 真实 node 作为解释器交给沙箱，即

ctx.sandbox.internals.windowsAclRunnerArgs = [<bundled node.exe>, <asar 外的 runner.js 副本>]

（internals 是 dsh-sandbox-local 自带的测试钩子，windowsAclRunnerInvocation() 每次调用都会读取它。）注意：普通 node.exe 读不了 app.asar 内的文件，所以 runner 及其依赖必须放在 asar 外（本例解包了 14 个包 + koffi 原生模块）。

[argszero]

It shipped. @argszero/cordis-plugin-sandbox-grant-advisor@0.23.0 is published, and your report is what the release carries into the analyzer's native-init advisory.

What changed because of your isolation:

• Producer 2's console-less shape (a) now carries your arm in its sharpest form — same token recipe, same grants, same stdio shapes, same workspace, same command, and only the process image HOSTING the runner varied — so what the text says now decides is the image that MINTS the token, not how the runner was launched. Your controls ride with it, because they are what closes the neighbouring readings: the OUTER subprocess runner's image does not matter, a token INHERITED from an Electron parent is harmless, and cmd.exe / node.exe / pwsh.exe all die as targets.
• The invariant you falsified is named where a reader can act on it: the runner invocation is built as [process.execPath, runner.js], whose docstring promises "the prefix stays [node, runner, …]" and whose own suite asserts it holds in product — which the packaged build is the one form to falsify.
• Your runtime unblock is carried as yours rather than as the fix, and with the reason: the provider does re-read its windowsAclRunnerArgs hook on every call, so a host-side plugin can point the invocation at the packaged node.exe plus a copy of runner.js living outside app.asar — but that is a test hook rather than an interface, which is why hosting the runner on a real node stays the line.

npm: https://www.npmjs.com/package/@argszero/cordis-plugin-sandbox-grant-advisor/v/0.23.0 — it mounts as a bundle patch and the advisory attaches to the 0xC0000142 result itself, on the successful result the pipeline reports. It remains a diagnostic: the change belongs in windowsAclRunnerInvocation.