[Windows] workspace-write 沙箱捕获原生命令输出：子进程 0xc0000142 弹窗 + 输出静默丢失

[renchuangzitianguang]

[Windows] workspace-write 沙箱下捕获原生命令输出：子进程 0xC0000142 弹窗 + 输出静默丢失

English abstract — On Windows under the workspace-write sandbox, any console child process
whose stdio PowerShell captures (pipeline, $x = cmd, 2>&1, >) either fails at creation
(Program 'X' failed to run: Access is denied) or starts and dies during loader initialization
(STATUS_DLL_INIT_FAILED, popup 应用程序无法正常启动(0xc0000142)). Command output is silently
lost — redirections produce 0-byte files with no PowerShell error. Creating an anonymous pipe
inside the sandbox is itself denied. 100% reproducible; both symptoms disappear when the sandbox
is disabled. Suspected cause: the restricted/Low-integrity token plus the default-DACL pipe issue
described in dsh-sandbox-windows-acl (setTokenDefaultDaclGrant) not covering Windows
PowerShell 5.1's native-command redirection.

• Reporter: DSH 用户，匿名用户 id 2de8917c-256b-462f-b3f2-e6bbba668209
• Session: session-d625bfea-e717-4fbc-8dd1-f7d26776cfd1
• Workspace: E:\deepseek-harness\workspace　Harness home: E:\deepseek-harness\.dsh

环境

项	值
OS	Windows 10 Pro，build 15063.1418（1703 / Creators Update），AMD64
Shell	Windows PowerShell 5.1.15063.1387（Desktop）；未安装 pwsh 7，DSH 的 pwsh 工具实际由 C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe 执行
Node	v24.21.0（D:\Program Files\nodejs\node.exe）
DSH	@deepseek-ai/dsh 0.2.0-rc.2（registry latest 同为 0.2.0-rc.2，无更新可升级）
沙箱插件	@deepseek-ai/dsh-sandbox-windows-acl 0.2.0-rc.2
权限预设	workspace-write（sandbox: workspace-write, approval: ask）

摘要

在 workspace-write 沙箱下，只要一个原生命令（.exe）的 stdout/stderr 被 PowerShell 捕获
（管道 |、赋值 $x = cmd、2>&1、重定向 >），就会出现下面两种结果之一：

1. 进程根本没被创建 → PowerShell 报 Program '<exe>' failed to run: Access is denied；
2. 进程被创建但在加载器初始化阶段死亡 → 系统弹出阻塞式对话框
   应用程序无法正常启动(0xc0000142)，且 PowerShell 不报任何错，重定向目标变成 0 字节空文件。

不接管道、输出直通终端时，同一个命令 100% 正常。关闭沙箱后，两种症状都消失。

今天（2026-10-16）系统日志中此类弹窗 52 条：node.exe 34、git.exe 7、cmd.exe 4、
python.exe 3、where.exe 3、pnpm.exe 1。时间分布 11:57–15:22，全部落在 DSH 执行命令的时段。

复现步骤（100% 稳定）

A. 主复现：沙箱内捕获原生命令输出

# 沙箱内（workspace-write）
cmd /c "tasklist /fo csv /nh" > .\_r1.csv
cmd /c "tasklist /fo csv /nh" > .\_r2.csv
cmd /c "tasklist /fo csv /nh" > .\_r3.csv

实际结果：三个文件全部 0 字节；桌面弹出 3 个 cmd.exe - 应用程序错误 / 应用程序无法正常启动(0xc0000142)；PowerShell 标准错误没有任何输出（静默失败）。

B. 对照组：同一条命令，关闭沙箱

对完全相同的三条命令，以 sandbox: danger-full-access 运行一次：

	生成文件	弹窗
沙箱内 workspace-write	_r1/_r2/_r3.csv = 0 / 0 / 0 字节	3 个 cmd.exe … 0xc0000142
沙箱外 danger-full-access	_u1/_u2/_u3.csv = 13662 / 13658 / 13658 字节（完整进程列表）	0 个

C. 最小复现：接管道即失败，直通即正常

node --version                        # OK  -> v24.21.0
node --version | Out-String           # Program 'node.exe' failed to run: Access is denied
$x = node --version                   # 同上
cmd /c "echo hi" | Out-String         # Program 'cmd.exe' failed to run: Access is denied
where.exe node | Out-String           # Program 'where.exe' failed to run: Access is denied
whoami /groups | Select-String x      # Program 'whoami.exe' failed to run: Access is denied

与 node 无关：cmd / where / whoami / git / python / pnpm 表现完全一致。node 最显眼，
是因为 DSH 沙箱 runner 本身就是 node.exe（[node, runner.js, --workspace, …]）且大量命令经 node。

D. 根因最小化：沙箱内建不出匿名管道

[System.IO.Pipes.AnonymousPipeServerStream]::new()     # Access to the path is denied.
[System.IO.Pipes.NamedPipeServerStream]::new('probe')  # OK

匿名管道创建被拒，而具名管道正常——这正是 Windows PowerShell 5.1 为原生命令准备 stdio 时
（.NET ProcessStartInfo.RedirectStandardOutput）使用的对象。

系统日志证据

Channel System、Provider Application Popup、Event ID 26（内核硬错误对话框记录）：

<EventData>
  <Data Name='Caption'>node.exe - 应用程序错误</Data>
  <Data Name='Message'>应用程序无法正常启动(0xc0000142)。请单击“确定”关闭应用程序。 </Data>
</EventData>

采集命令：

Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Application Popup'} |
  Select-Object TimeCreated,
                @{n='Caption';e={$_.Properties[0].Value}},
                @{n='Message';e={$_.Properties[1].Value}}

0xc0000142 = STATUS_DLL_INIT_FAILED：进程对象已创建，加载器初始化失败，因此由 CSRSS 代弹对话框。

影响

1. 阻塞式弹窗：每次失败都要求用户手动点“确定”，今天已累积 52 次；用户最初的反馈就是
   “执行命令时总有 node 弹出错误”。
2. 静默数据丢失（最严重）：重定向产物是 0 字节空文件，且没有非零退出码、没有 stderr。
   构建 / 导出 / 抓取类命令可能“看起来成功、实际什么都没做”。
3. 常用命令不可用：npm（npm.ps1 内部有 $NPM_PREFIX=(& $NODE_EXE …) 捕获）、
   git … 2>&1、任何 … | Out-String 都会触发。
4. 误导性诊断：框架把这类进程创建失败渲染成 [sandbox: file access denied under workspace-write mode] 并提示“可升级权限”，因为 windows-acl 的拒绝特征串里包含
   access is denied（dsh-sandbox-local/lib/index.js 的 DENIAL_SIGNATURES）。排查方向被带偏。

机制分析（推测，附代码位置）

dsh-sandbox-windows-acl 用 CreateRestrictedToken + Low 完整性运行命令
（lib/types-Cl_DXjhk.js 的 AclSandbox.init()）。源码注释已经点名了这类故障：

"The restricted token inherits the user's default DACL verbatim, which names no restricting SID:
a new anonymous pipe (child stdio) therefore fails the write pass-2 check at creation
(ERROR_ACCESS_DENIED; Node surfaces it as spawn EPERM), breaking every piped-stdio grandchild spawn."
— types-Cl_DXjhk.js:785-796

为此实现了 setTokenDefaultDaclGrant(...)（[types-Cl_DXjhk.js:1293]），把 write SID 的
full-access ACE 合入受限令牌的 default DACL。

在本环境中该缓解未覆盖 Windows PowerShell 5.1 的原生命令重定向路径，实测表现为上面 A/B/C/D。
可能的原因（供维护者判断）：

• .NET / PS 5.1 走的是 ProcessStartInfo + CreatePipe，其管道安全描述符与实现里假设的
  “拿 token default DACL” 的路径不同；
• 管道创建失败后 PS 5.1 仍会尝试 CreateProcess，于是分别落到 ERROR_ACCESS_DENIED
  （CreateProcess 失败）与 STATUS_DLL_INIT_FAILED（子进程起来但初始化失败）两种表象；
• 而 dsh-tool-pwsh 的说明写着 “PowerShell's own pipelines are unaffected”，与实测不符。

建议

1. 修复管道创建：让受限令牌下 .NET/PS 5.1 产生的匿名管道可被持有者访问（例如为管道显式提供
   命名 restricting SID 的安全描述符，或让持有管道的 shell 侧不被限制），使
   setTokenDefaultDaclGrant 的意图真正覆盖该路径。
2. 修正误分类：CreateProcess / 管道创建失败应作为 runner 级错误上报，不要渲染成
   “file access denied under … mode”，也不要给出升级权限的提示。
3. 修正文档：dsh-tool-pwsh 中 “PowerShell's own pipelines are unaffected” 需要修正或加限定条件。
4. 可观测性：检测到子进程以 0xC0000142 退出时给出明确诊断，而不是让操作系统弹对话框、
   让重定向静默产出空文件。
5. 兜底：workspace-write 下若无法支持管道，至少应让重定向失败报错并返回非零退出码，
   避免静默空输出。

附：报告人侧的临时探测均已清理

调查期间在 workspace 创建的 _r*.csv、_u*.csv、_tl.csv 等文件已全部删除，工作区为空。

---

本报告由 DSH 会话中的 AI 助手依据可复现证据整理，经用户确认后提交到 Discussions（本仓库 Issues 已关闭）。原始会话：session-d625bfea-e717-4fbc-8dd1-f7d26776cfd1。

[argszero]

Confirmed at source — and the code's own comment names the boundary your case falls outside

This is a careful report and the mechanism holds up. I read the package at the current head (86a40220), so my line numbers are src/, not the bundle's lib/:

1. Your point 4 (misclassification) is real, and the source says why

packages/sandbox/sandbox-local/src/index.ts:207-214:

const DENIAL_SIGNATURES = {
  bwrap: ['read-only file system'],
  landlock: ['permission denied'],
  seatbelt: ['operation not permitted'],
  // pwsh/.NET: "Access to the path '...' is denied."; cmd: "Access is denied.";
  // Node EACCES: "permission denied"; EPERM: "operation not permitted".
  'windows-acl': ['access is denied', 'access to the path', 'permission denied', 'operation not permitted'],

The comment above the entry shows the list was assembled from in-sandbox file errors — the Access is denied. string it names is cmd.exe's file denial text. A CreateProcessAsUserW failure surfaces the same OS message, so a process-creation failure is matched by the same substring set, rendered as [sandbox: file access denied under workspace-write mode], and answered with "escalate". Nothing distinguishes the two, so your point 4 is exactly right: the denial is a runner-level failure wearing a file-denial costume.

2. The mitigation's stated scope is the place to look

packages/sandbox/sandbox-windows-acl/src/token.ts:97-105 — the doc comment on setTokenDefaultDaclGrant:

Merge one full-access allow ACE for sidPtr into the token's DEFAULT DACL — the DACL every NEW object the token holder creates (without an explicit security descriptor) takes. The restricted token inherits the user's default DACL verbatim, which names no restricting SID: a new anonymous pipe (child stdio) therefore fails the write pass-2 check at creation (ERROR_ACCESS_DENIED; Node surfaces it as spawn EPERM), breaking every piped-stdio grandchild spawn.

The parenthetical is the whole scope of the fix, and it is a scope rather than a caveat: the merged ACE reaches an object only because the object asked the token for its default DACL. A caller that supplies its own security descriptor — or whose object's DACL comes from another path entirely — is outside it by construction. Your "可能的原因 1" (the pipe's security descriptor differs from the assumed path) is therefore not a guess about a bug; it is the one assumption in the code that could be false while everything else still behaves as documented. The call site also shows what the merged SID is (sandbox-windows-acl/src/index.ts:306): this.tempWriteSidPtr ?? this.writeSidPtr ?? worldSid — so under workspace-write with a private temp root, the ACE names the private temp SID, not the workspace one. Your suggestion 1 (give the pipe an explicit SD naming the restricting SID) is the same idea expressed where the failing creation happens, which is a better place than widening the default.

3. Your probe D refutes a claim the shipped tool documentation makes

packages/shell/tool-pwsh/src/index.ts:145-150 is delivered to the model as tool guidance:

In both confined modes, programs cannot open named pipes, so a command that captures another program's output through piped stdio (Node.js child_process.spawn/exec with the default stdio: 'pipe') fails with EPERM, while stdio: 'inherit' and stdio: 'ignore' spawns work and PowerShell's own pipelines are unaffected.

Two halves of that sentence are contradicted by your measurements, and they are separate defects:

• programs cannot open named pipes — your D probe created a named pipe successfully and was denied only on the anonymous one. So the object class named in the doc is not the one that fails.
• PowerShell's own pipelines are unaffected — that is precisely the path your §C shows failing ($x = node --version, … | Out-String, where.exe node | Out-String).

The second one is the one that costs something, because the sentence does not merely describe — it instructs: "That EPERM is the documented boundary: do not retry the command another way — escalate the exact command once or restructure it to avoid capturing output." An agent that follows it will escalate a platform defect as if it were a policy boundary, and a host that reads the console will be told the sandbox worked as designed. Whatever is done about the pipes, that paragraph should stop asserting a behaviour on the strength of a host the reports contradict.

4. One correction to your suggestion 5

The 0-byte file is not something the harness can make nonzero. PowerShell opens the redirection target itself, before the child is created, and the child then dies during loader initialization — so the empty file and the absent error are both produced on the PowerShell side of the boundary, as your §B control (13662 bytes vs 0) shows cleanly. What the harness can do is your suggestion 4: recognise the child's STATUS_DLL_INIT_FAILED (and spawn EPERM at creation) as a runner condition and report it as one, rather than letting the OS own the only visible signal. That is the achievable half, and it is also the half that would have saved you the first round of diagnosis.

5. This and a same-day report are one story

There is a second report filed the same day from a different host — the pwsh one, where a .NET executable dies with 0xC0000142 on any invocation, piped or not — and reading the two together is what pins the shape of the problem: the error code is not a discriminator (your cmd.exe redirection produces it too, and cmd is not .NET), the condition is. In your report the condition is "stdio is captured"; in that one it is "the executable is .NET". Both point at the restricted token, and neither points at PowerShell. Your附 already suspects this — the note belongs there rather than as a separate guess, because your own control group is the evidence for it.

I have not run this on Windows, so every measurement above is yours; what I verified in the tree is the denial-signature list and the comment explaining where it came from, the default-DACL grant's documented scope and the SID it actually names, and the tool-documentation sentence asserting that PowerShell's own pipelines are unaffected.