[Bug] workspace-write 下所有命令 0xC0000142 失败 / Windows ACL 沙箱环境变量泄漏

[fxp39-maker]

BUG-REPORT-workspace-write-0xC0000142.md

缺陷报告：workspace-write 下所有命令以 0xC0000142 失败（Windows 桌面版）

• 报告日期：2026-09-28
• 产品：DeepSeek Harness 桌面版（Windows）
• 安装路径：E:\deepseekharness
• 版本文件：E:\deepseekharness\version = 44.0.0
• 关键包：@deepseek-ai/dsh-subprocess、@deepseek-ai/dsh-subprocess-local、@deepseek-ai/dsh-sandbox-windows-acl
• 严重级别：高（沙箱模式完全不可用，且故障会持续整个会话）

---

1. 摘要

在文件策略为 workspace-write 时，任何命令工具调用（pwsh / bash 类）都会失败，表现为：

(no output)
[exit code: 3221225794]

3221225794 = 0xC0000142 = STATUS_DLL_INIT_FAILED（Windows 进程加载器初始化失败）。

同一会话切到 danger-full-access 后同一命令立即恢复正常。因此故障被限定在沙箱子进程创建链路上，与具体命令无关。

---

2. 复现步骤

1. 以默认/受限文件策略启动桌面版，使会话处于 workspace-write。
2. 执行任意命令，例如 echo hello。
3. 观察结果：(no output) + 退出码 3221225794。

补充观察：

• 同一会话的第一条命令可能成功，随后所有命令开始失败（本机观察到第 1 条 echo hello 成功，之后全部失败）。
• 失败对命令内容不敏感：echo hello、cmd /c "echo hi"、whoami 结果一致。
• 会话级文件工具（读/写/搜索走进程内路径时）仍然可用；只有「创建子进程」这条路全线失败。

---

3. 已确认的根因（因果链）

3.1 DSH 运行时自身带着 ELECTRON_RUN_AS_NODE=1

桌面宿主 dsh-desktop-host 以 Node 模式启动 DSH 运行时，并在其环境中注入该变量。安装包内可见（app.asar 内 dsh/node_modules/@deepseek-ai/dsh-desktop-host/lib/index.js）：

{ command: process.execPath, args: ["--expose-internals", process.argv[5]],
  env: { ELECTRON_RUN_AS_NODE: "1", DSH_DESKTOP_NODE_EXECUTABLE: process.execPath, PATH: ... } }

因此 harness 主进程的 process.env 里始终存在 ELECTRON_RUN_AS_NODE=1。

3.2 子进程环境由 scrubbedParentEnv() 派生，且不过滤该变量

@deepseek-ai/dsh-subprocess/lib/index.js：

const SENSITIVE_ENV_PATTERN = /KEY|PASSWORD|SECRET|TOKEN/i;

function scrubbedParentEnv() {
	const env = {};
	for (const [key, value] of Object.entries(process.env)) if (value !== void 0 && !SENSITIVE_ENV_PATTERN.test(key) && !key.toUpperCase().startsWith("DSH_")) env[key] = value;
	for (const [name, value] of Object.entries(proxyEnvironmentForChild())) if (value === void 0) Reflect.deleteProperty(env, name);
	else env[name] = value;
	return env;
}

ELECTRON_RUN_AS_NODE 既不是凭据型名字（不含 KEY/PASSWORD/SECRET/TOKEN），也不以 DSH_ 开头，因此被原样转发给每个子进程。

3.3 沙箱目标进程因此继承该变量（实测）

用探针（经沙箱运行器启动的目标进程自行打印环境）得到：

{"electron":"1","dshRunner":null,"tmp":"<session private temp>","temp":"<session private temp>","execPath":"E:\\deepseekharness\\DeepSeek Harness.exe"}

即：被沙箱启动的目标进程，其环境里带着 ELECTRON_RUN_AS_NODE=1。

3.4 该组合在受限令牌下必然崩溃（对照实验）

隔离实验（同一脚本、同一命令，唯一差别是运行器环境里是否含该变量）：

运行器环境	结果
不含 ELECTRON_RUN_AS_NODE	退出码 0x0，命令正常执行
含 ELECTRON_RUN_AS_NODE=1（值 0、node 同样触发）	退出码 0xC0000142，零输出

同时确认：

• Electron-as-Node（DeepSeek Harness.exe + ELECTRON_RUN_AS_NODE=1）作为 Electron 子进程启动是可行的（-e、--version、普通脚本均返回 0）——因此问题不在「Electron 能否启动」，而在受限令牌下该变量导致的加载器初始化失败。
• CREATE_NO_WINDOW（Node 的 windowsHide: true）不是原因：开关该选项结果相同（两种都 0xC0000142）。

3.5 与沙箱文档已记录的边界一致

@deepseek-ai/dsh-sandbox-windows-acl 的 README 已明确记录同类失败模式：

控制台隔离不可用。 以 CREATE_NO_WINDOW / CREATE_NEW_CONSOLE 创建的子进程在 DLL 初始化期间以 STATUS_DLL_INIT_FAILED（0xC0000142）死亡。

本报告是同一失败码的另一条触发路径，且触发条件是环境变量而不是创建标志。

---

4. 建议修复（上游）

在源码层修，任选其一：

1. 在 scrubbedParentEnv() 中显式排除（最直接、语义最清晰）：

   const CHILD_ENV_DENYLIST = new Set(["ELECTRON_RUN_AS_NODE"]);
   ...
   if (value !== void 0 && !SENSITIVE_ENV_PATTERN.test(key)
       && !key.toUpperCase().startsWith("DSH_")
       && !CHILD_ENV_DENYLIST.has(key.toUpperCase())) env[key] = value;

2. 或把它并入敏感名模式（注意不要削弱现有 KEY| 这一项，否则 DEEPSEEK_API_KEY 之类会泄漏给子进程）：

   const SENSITIVE_ENV_PATTERN = /KEY|PASSWORD|SECRET|TOKEN|ELECTRON_RUN_AS_NODE/i;

3. 或在沙箱运行器启动目标前，从目标环境块中删除该变量（在 targetEnvironment() 内，语义上最贴近沙箱边界）。

附带建议：桌面宿主注入 ELECTRON_RUN_AS_NODE 时应视为内部机制变量，与 DSH_* 同级处理，避免其进入任何子进程环境。

---

5. 为什么报告者没有就地修补安装包

安装包内的代码位于 resources/app.asar。任何文件内容的长度变化都会移动其后的所有偏移，必须重建整个归档并更新头部；而 Electron 会校验 asar 头部的完整性哈希。实测该构建里所有可安全插入的位置都比所需改动更短（例：环境函数出口行 53 字节，而 delete + return 最少需要约 85 字节），因此在安装包层面无法做长度中性的修补。故该修复应由源码层完成。

---

6. 影响面

• 平台：Windows 桌面版（workspace-write / read-only 等受限模式）
• 后果：受限模式下命令工具完全不可用，且会话内不会自愈；用户只能切到 danger-full-access 才能继续工作，实质上绕过了文件沙箱——安全影响不可忽视。
• 触发条件普遍：只要桌面版以 Node 模式启动运行时（即默认形态），该变量就存在。

---

7. 附：报告者的环境

• Windows（工作区位于 E:\HuaweiMoveData\...，与驱动器无关，C: 盘同样复现）
• DSH 宿主以**管理员（High 完整性）**运行；沙箱令牌为 WRITE_RESTRICTED 受限令牌
• 安装包 version = 44.0.0；npx 缓存中的 CLI 为 @deepseek-ai/dsh@0.1.5-rc.3

[BIBIMOYU]

Root cause for the workspace-write 0xC0000142 here is the default-DACL trustee, not ELECTRON_RUN_AS_NODE (0.2.0-rc.2, Windows desktop)

Same symptom: every command under workspace-write returns no output and exit code 3221225794 (0xC0000142), while read-only and danger-full-access keep working in the same session. I bisected the runner by loading the asar modules through an ESM load hook and changing exactly one thing per run (Electron-as-node, argv built the same way as windowsAclRunnerArgv: --workspace <ws> --temp %TEMP% --mode workspace-write -- cmd /c echo A):

variant (workspace-write)	result
unpatched	no output, exit -1073741502
ELECTRON_RUN_AS_NODE deleted from the runner's env	still -1073741502
runner.js TMP/TEMP rewrite to the private temp dir disabled	still -1073741502
capability SIDs removed from the restricting list	still -1073741502
default-DACL trustee forced to worldSid	works, prints A, exit 0

read-only survives because AclSandbox.init() falls through to worldSid there; workspace-write is the only mode that names this.tempWriteSidPtr ?? this.writeSidPtr in setTokenDefaultDaclGrant() (the call right after restrictTokenIntegrity()).

Subsystem matters: a probe compiled with -OutputType WindowsApplication runs fine under workspace-write, while a console-subsystem probe (-OutputType ConsoleApplication) dies with 0xC0000142; both work under read-only. So the failing path is console-specific — consistent with the "console isolation is unavailable" limitation (and with S-1-2-1 being absent from the restricting list): something on the console/DLL-init path cannot use an object whose default DACL names a capability SID that no other process holds, while naming Everyone works.

Suggested one-line fix (keeping confinement intact):

setTokenDefaultDaclGrant(api, restrictedToken, worldSid);

Verified in memory: cmd and powershell work under workspace-write again, while the workspace/temp grants, the Low integrity label, the TMP/TEMP rewrite and the capability SIDs in the restricting list are all untouched — a write outside the workspace is still denied (Access is denied), and whoami /all still reports Mandatory Label\Low Mandatory Level S-1-16-4096. Only the default DACL of objects created by the confined child changes, which is what read-only has always done.

FWIW the env var does leak into the confined child here too, and both the CLI (dsh.cmd) and the desktop app run on the Electron binary, which makes ELECTRON_RUN_AS_NODE look causal — but removing it does not change the outcome, and read-only works with the same leak in place.

Second, possibly separate observation from the same machine: inside a confined workspace-write shell, schannel/.NET HTTPS clients cannot complete a TLS handshake at all — curl https://example.com fails with curl: (35) schannel: AcquireCredentialsHandle failed: SEC_E_NO_CREDENTIALS (0x8009030e) and Invoke-WebRequest https://api.github.com/ fails with "the connection was closed while receiving". Both work in an unconfined shell on the same host (same local proxy). This one is not fixed by the default-DACL change, so it is probably a separate consequence of the restricted token; happy to bisect it the same way if it is useful.

Happy to run any probe you want on this machine (Windows 11 build 26100, Electron desktop app, non-admin user, High IL host). Locally I currently work around the first issue with a length-neutral 52-byte in-place patch of app.asar that I re-apply after every update.