[Bug] Windows: pwsh 工具在 workspace-write 沙箱下 100% 失败（0xC0000142），同参数 runner 直调正常

[JiangyeMx]

摘要

Windows 上，只要会话文件策略是默认的 workspace-write，pwsh 工具每一次调用都失败：

(no output)
[exit code: 3221225794]          # 0xC0000142 = STATUS_DLL_INIT_FAILED

失败是静默的：无 stdout、无 stderr、无 [sandbox: file access denied ...] 策略拒绝提示、也没有 ACL runner 的失败方言（windows-acl-run: ...）。
但同一台机器、同一个 pwsh、完全相同的 runner 参数，直接调用 DSH 自带的沙箱 runner（@deepseek-ai/dsh-sandbox-windows-acl/lib/runner.js --mode workspace-write）却能正常启动并执行（且受限确实生效——受限子进程内写工作区外被拒绝）。
因此问题不在 PowerShell 版本、不在 MSIX 打包、不在 ACL runner 本身，而在 dsh-pwsh-sandbox / dsh-tool-pwsh 与 runner 之间的接线；并且工具层吞掉了可用于定位的失败信息。

环境

项	值
OS	Windows 10.0.26200
DSH	桌面版（dsh-desktop），<DSH_INSTALL>\DeepSeek Harness.exe
会话文件策略	workspace-write（复现时）
PowerShell	C:\Program Files\PowerShell\7\pwsh.exe = 7.6.6（MSI 安装）
对照	C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe（5.1）
工作区	<WORKSPACE>

复现过程中曾把 Store(MSIX) 版 PowerShell 7.6.6 卸载、改装 MSI 版；问题在两种安装形态下同样存在。

复现步骤

前置：从 app.asar 抽出 DSH 自带的 ACL runner 与依赖（脚本随附，见文末）：

node 00-build-runner.js      # 默认读 <DSH_INSTALL>\resources\app.asar，可用 --app 指定

A. 工具侧（失败）

1. 把会话文件策略设为 workspace-write
2. 发一条新消息（策略切换只在回合边界生效，见下"附带问题"），在新回合里让 DSH 执行任意 pwsh 命令
   预期：命令执行并返回输出。
   实际：(no output) + [exit code: 3221225794]。
   B. runner 直调侧（成功）

pwsh -File ./repro.ps1 -Markdown result.md -Redact   # -Redact 自动抹掉用户名/主机名/工作区路径

--- 用例（runner 直调，--mode workspace-write）---
[pwsh-version   ] exit=0    PASS    stdout: 7.6.6
[pwsh-echo      ] exit=0    PASS    stdout: SANDBOX_PWSH_OK
[cmd            ] exit=0    PASS    stdout: SANDBOX_CMD_OK
[ps51           ] exit=0    PASS    stdout: SANDBOX_PS51_OK
[pwsh-writeprobe] exit=0    PASS    stdout: OUTSIDE-WRITE-DENIED     ← 受限确实生效

pwsh-writeprobe 在受限子进程内尝试写 C:\ 被拒绝，证明沙箱在强制、且 pwsh 在受限令牌下能正常启动并执行命令。
C. 对照（成功）：同一会话切到 danger-full-access 后，pwsh 工具完全正常：

PSVersion=7.6.6
Process=C:\Program Files\PowerShell\7\pwsh.exe

判定矩阵

组合	结果
DSH 工具 pwsh + workspace-write	❌ 0xC0000142（多轮稳定复现）
DSH 工具 pwsh + danger-full-access	✅ 正常
直调 runner + workspace-write + pwsh 7.6.6	✅ SANDBOX_PWSH_OK
直调 runner + workspace-write + cmd.exe	✅ SANDBOX_CMD_OK
直调 runner + workspace-write + PS 5.1	✅ SANDBOX_PS51_OK
直调 runner + 受限内写工作区外	✅ 被拒绝（沙箱生效）
runner 参数错误（temp 在工作区内 / temp 不存在）	exit 127 + windows-acl-run: ... 明确 stderr

工具侧实际进程命令行

工具调用期间抓到的进程树：

"<DSH_INSTALL>\DeepSeek Harness.exe"
  <DSH_INSTALL>\resources\app.asar\dsh\node_modules\@deepseek-ai\dsh-subprocess-local\lib\runner.js
  -- "C:\Program Files\PowerShell\7\pwsh.exe" -NoLogo -NoProfile -NonInteractive -Command
     "[Console]::OutputEncoding = [System.Text.UTF8Encoding]::new($false); ...; <用户命令>"

dsh-subprocess-local/lib/runner.js 通过 spawnCurrentTokenJobProcess（普通令牌）启动目标进程，自身不施加隔离；隔离由 dsh-pwsh-sandbox 经 ctx.sandbox.confine() 挂在外层（沙箱生效时应出现 @deepseek-ai/dsh-sandbox-windows-acl/lib/runner.js --workspace <ws> --temp <t> --mode workspace-write -- ... 这一层包装）。

为什么"静默"本身是个问题

@deepseek-ai/dsh-sandbox-windows-acl 的设计约定是：runner 侧失败一律向 stderr 打印 windows-acl-run: <detail> 并以 127 退出（seam 通过该签名分类为"沙箱损坏"）。而本故障的观测是 纯 0xC0000142 + 零 stderr，说明：

• 失败不是 runner 参数校验/启动阶段（那些会给出 127 + 明确文本）
• 失败发生在受限子进程内部（进程已创建，早期 DLL 初始化被拒），或包装层向子进程传递参数/环境/stdio 的过程中
• 而该错误没有任何文本透传到模型侧，用户与模型都只能看到裸退出码

已排除 / 待验证

已排除：

假设	依据
PowerShell 版本或安装损坏	MSI 7.6.6 独立运行正常；runner 直调同一文件成功
Store/MSIX 打包问题	卸载 Store 版改装 MSI 版后问题依旧
ACL 沙箱机制整体失效	runner 直调 + cmd/PS5.1/pwsh 全部成功，且受限内写工作区外被正确拒绝
runner 参数校验失败	参数错误有明确 windows-acl-run: + exit 127；本故障静默
dsh-subprocess-local 的 Job/stdio 机制	它用普通令牌启动子进程，且在 danger-full-access 下工作正常
策略未切换	已确认 runtime 快照中 workspace-write 生效，且该回合内持续失败
待验证（按可能性排序）：

1. dsh-pwsh-sandbox 传给 ACL runner 的 --workspace / --temp / 环境参数与 runner 直调形态不一致，导致受限子进程所需对象的权限不足 → 早期 DLL 初始化被拒；
2. 私有 temp 授权未正确物化或已被撤销（runner 会为每个"会话×工作区"对创建私有 temp 并挂能力 SID；若复用为失效/未打标状态，症状正是早期 DLL 初始化死亡）；
3. 受限令牌保留 SID 集合与 pwsh 的实际 DLL 依赖路径不匹配（ACL 包 README 已记录：缺 keep-alive 组会导致 0xC0000142）。
   需要在工具层调用形态下转储受限令牌与 DACL 才能定论。

附带问题：策略切换只在回合边界生效

会话文件策略的切换只在「回合边界」生效，同一回合内的后续工具调用仍走旧策略。这会让诊断得出互相矛盾的结论：

1. 切到 workspace-write 后，同回合内的工具调用仍失败（实为旧策略的调用）
2. 切到 danger-full-access 后，同回合内的探针显示"工作区外写入被允许"（新策略），但随后的工具调用仍按旧的无沙箱路径执行（进程树里没有任何沙箱包装层）
3. 只有发出一条新消息后，工具调用才真正按新策略执行
   建议：在工具结果里标注"本次调用实际生效的策略 / 是否被隔离"，避免此类误判。

建议的改进

1. 透传 runner 的 stderr / 失败分类（现在 0xC0000142 无任何文本，定位成本极高）
2. runner 失败时给出结构化错误（seam 已有 denialSignatures / fatalSignatures 机制，本案例未被触发）
3. 工具结果标注本次调用实际生效的策略

复现包

文件	用途
00-build-runner.js	从 app.asar 抽取 ACL runner 及依赖（迭代解析，自愈）
repro.ps1	用例 B：runner 直调（含受限内写工作区外探针）
01-tool-side.ps1	用例 A：由 DSH 工具在 workspace-write 生效的回合里运行；第一步先自检沙箱是否真在强制
result-runner-direct.md	本机 repro.ps1 实测输出留档
需要的话我可以把复现包打包成 zip 附到 Discussion 里。
dsh-pwsh-sandbox-repro.zip