[Bug][Windows] Confined grandchildren with piped stdio fail with EACCES and raise a desktop 0xC0000142 hard-error dialog

[yzyyohh]

Summary

Under workspace-write, a confined powershell.exe cannot launch a native child when that
child's stdout/stderr are piped. The spawn fails with Access is denied (Win32
ERROR_ACCESS_DENIED / EPERM), and Windows additionally raises a hard-error dialog on
the user's desktop: python.exe - Application Error : 应用程序无法正常启动(0xc0000142).

This is a user-visible symptom, not just a tool-level error: the dialog is a loader hard
error, so it cannot be suppressed by the harness, by WER settings, or by error mode.

Environment

Item	Value
OS	Windows 11 25H2, build 26200.9445, system locale ACP 936
dsh	@deepseek-ai/dsh 0.1.5-rc.2
sandbox backend	@deepseek-ai/dsh-sandbox-windows-acl 0.1.5-rc.2
process primitives	@deepseek-ai/dsh-win32-process 0.1.5-rc.2
Node	v24.15.0
resolved shell	C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe (Windows PowerShell 5.1)
session sandbox mode	workspace-write

Also reproduced against @deepseek-ai/dsh-win32-process@0.1.6-alpha.1 and against the
current master source line — neither contains a change for this path
(STARTF_USESTDHANDLES is still the only dwFlags bit set).

Reproduction A — through the harness

With a session in workspace-write, using the pwsh tool:

# FAILS: no output, "Program 'python.exe' failed to run: Access is denied"
& "C:\Users\Lalawu\anaconda3\python.exe" -V | Out-String

# WORKS: output redirected to a file instead of a pipe
& "C:\Users\Lalawu\anaconda3\python.exe" -V > out.txt

The failing form also writes System event log Application Popup id 26:

Application popup: python.exe - Application Error :
应用程序无法正常启动(0xc0000142)。请单击"确定"关闭应用程序。

Switching the same session to danger-full-access and re-running the identical captured
command succeeds 3/3 with zero popups. The only variable is the confined shell.

Over a 30-day window this host produced 141 such popups, across nine different
executables — node.exe (47), python.exe (34), git.exe (11), cmd.exe (11),
where.exe (11), curl.exe (3), dotnet.exe (1), pdftoppm.exe (1), HOSTNAME.EXE (1).
None of the affected programs is broken; each runs correctly outside the sandbox.

Reproduction B — direct AclSandbox API (no harness in the loop)

AclSandbox (workspace-write) is used to spawn a confined powershell.exe, and the
case only varies what that confined shell does with a native child. This isolates the
failure from any harness/tool-layer behaviour.

#	Command executed inside the confined shell	Exit	Result
1	Write-Output CMDLET_OK	0x00000000	✅ CMDLET_OK
2	& python.exe -V | Out-String	0x00000001	❌ Access is denied + desktop popup 0xC0000142
3	& python.exe -V > py_out.txt; Get-Content py_out.txt	0x00000000	✅ works
4	cmd.exe /c "echo FROM_CMD" | Out-String	0x00000001	❌ Access is denied

The matrix is deterministic — repeated runs give the same result. The discriminator is
piped stdio vs. file-redirected stdio, not the executable, not the console, and not the
host's console state:

• The confined shell itself always starts fine (case 1), so this is not the
  console-less-host boundary described in [Bug] Windows: sandboxed pwsh always dies with 0xC0000142 under console-less host (desktop launch path) #810.
• Case 3 proves the confined shell can create a native process when the handle is a file.
• Cases 2 and 4 fail identically for two different executables.

Probe harness (two files, ~110 lines) is available on request; it calls the shipped
AclSandbox exactly as the executor does:

const sandbox = new AclSandbox({
  writableDirs: [ws], tempDir: temp,
  writeSid: workspaceWriteSid(ws), tempWriteSid: tempWriteSid(temp),
  mode: 'workspace-write',
})
await sandbox.init()
const child = sandbox.spawn({ command: PS51, args: [...], cwd: ws })
const { stdout, stderr, exitCode } = await child.wait()

Documentation conflict

@deepseek-ai/dsh-sandbox-windows-acl/README.md → Known Limitations currently states:

Piped stdio capture is impossible for confined grandchildren — libuv's pipe stdio uses
named pipes, whose client-end open requests write access no restricting SID is granted …
so spawn(..., { stdio: 'pipe' }) inside a confined process fails with EPERM; inherited
and ignored stdio spawns work, and anonymous pipes (PowerShell pipelines) work because
the restricted token's default DACL carries a full-access restricting-SID ACE.

The last clause does not hold here: a PowerShell pipeline is precisely what fails in cases 2
and 4. Either the default-DACL assumption is OS/build-dependent, or the guarantee is narrower
than documented. The entry also omits that the failure escalates to a desktop hard-error
dialog, which is the part users actually report.

Things I tested that do not fix it

Mitigation	Result
STARTF_USESHOWWINDOW | SW_HIDE on the sandbox STARTUPINFO (the fix proposed in #1344, dwFlags: 256 → 257)	no change — still Access is denied, still the popup
SetErrorMode(SEM_FAILCRITICALERRORS | SEM_NOOPENFILEERRORBOX) set before the spawn (inherited by the confined subtree)	no change — the loader dialog still appears
HKCU\...\Windows Error Reporting\DontShowUI=1 (reported in #1847)	no change — the dialog is a loader hard error, not a WER path
Restarting dsh web	no change
danger-full-access	works, but removes the boundary entirely

What I am asking for

1. Confirmation of the intended behaviour for the pipe path, and a correction (or
   clarification) of the "anonymous pipes work" statement in the backend README.
2. Guidance on whether the pipe DACL can be made usable by the restricting SIDs — e.g. by
   setting an explicit default DACL on the duplicated WRITE_RESTRICTED token — or whether
   this is accepted as a hard boundary.
3. Independent of the fix: the failure currently surfaces as a desktop dialog rather than
   a tool-level error. Even when the spawn cannot succeed, an agent host should not be able
   to put a modal loader error box on the user's screen; a way to force the diagnostic-only
   path would be worth having on its own.

Related existing reports

• [Bug] Windows: sandboxed pwsh always dies with 0xC0000142 under console-less host (desktop launch path) #810 — sandboxed pwsh always dies with 0xC0000142 under console-less host
• [Bug][Windows] Sandboxed subprocess spawn flashes a visible console window from GUI hosts; STARTF_USESHOWWINDOW + SW_HIDE fixes it without the 0xC0000142 crash #1344 — Sandboxed subprocess spawn flashes a visible console window from GUI hosts; STARTF_USESHOWWINDOW + SW_HIDE fixes it without the 0xC0000142 crash
• Workspace-write sandbox: external processes fail with 0xC0000142 on Windows 10 (build 19041) #1847 — Workspace-write sandbox: external processes fail with 0xC0000142 on Windows 10 (build 19041) — closest match: same dialog text, same executable set, plus the "works early in the session, then fails persistently" timing
• [Bug] Windows PTC/Code Mode (run_code) cannot spawn any subprocess — bash/glob/grep fail with 0xC0000142 #3867 — Windows PTC/Code Mode (run_code) cannot spawn any subprocess — bash/glob/grep fail with 0xC0000142

This report adds what those threads lack: a controlled matrix that isolates piped stdio as
the discriminator, on a host where the confined shell itself starts normally.

---

Appendix — the ~110-line probe harness used for Reproduction B

// Sandboxed-spawn probe with optional loader-error-mode suppression.
// node child.mjs <ws> <temp> <resultJson>
import fs from 'node:fs'
import { createRequire } from 'node:module'

const DSH_NM = 'file:///C:/Users/Lalawu/AppData/Roaming/npm/node_modules/@deepseek-ai/dsh/node_modules/'
const PKG = DSH_NM + '@deepseek-ai/dsh-sandbox-windows-acl/lib/index.js'

const results = { mode: process.env.PROBE_MODE ?? 'unknown', errorMode: null, cases: [] }

// ---- optional: SetErrorMode(SEM_FAILCRITICALERRORS | SEM_NOOPENFILEERRORBOX) ----
// Inherited by every descendant, so a loader failure degrades to a silent error
// instead of a desktop hard-error dialog.
if (process.env.PROBE_ERRORMODE === '1') {
  try {
    const require = createRequire(DSH_NM)
    const koffi = require('koffi')
    const kernel32 = koffi.load('kernel32.dll')
    const SetErrorMode = kernel32.func('unsigned int __stdcall SetErrorMode(unsigned int uMode)')
    const previous = SetErrorMode(0x0001 | 0x8000) // SEM_FAILCRITICALERRORS | SEM_NOOPENFILEERRORBOX
    results.errorMode = { requested: '0x8001', previous: '0x' + (previous >>> 0).toString(16) }
  } catch (e) {
    results.errorMode = 'FAILED: ' + (e?.message ?? String(e))
  }
}

const { AclSandbox, workspaceWriteSid, tempWriteSid } = await import(PKG)

const [, , ws, temp, outFile] = process.argv

const sandbox = new AclSandbox({
  writableDirs: [ws],
  tempDir: temp,
  writeSid: workspaceWriteSid(ws),
  tempWriteSid: tempWriteSid(temp),
  mode: 'workspace-write',
})

try {
  await sandbox.init()
  results.init = 'ok'
} catch (e) {
  results.init = 'FAILED: ' + (e?.message ?? String(e))
}

const hex = (n) => '0x' + (n >>> 0).toString(16).toUpperCase().padStart(8, '0')
const PS51 = 'C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe'

const CASES = [
  { name: '1-cmdlet-only', command: PS51, args: ['-NoLogo', '-NoProfile', '-NonInteractive', '-Command', 'Write-Output CMDLET_OK'] },
  { name: '2-native-captured-pipe', command: PS51, args: ['-NoLogo', '-NoProfile', '-NonInteractive', '-Command', '& "C:\\Users\\Lalawu\\anaconda3\\python.exe" -V | Out-String'] },
  { name: '3-native-redirect-file', command: PS51, args: ['-NoLogo', '-NoProfile', '-NonInteractive', '-Command', `& "C:\\Users\\Lalawu\\anaconda3\\python.exe" -V > "${ws}\\py_out.txt"; Get-Content "${ws}\\py_out.txt"`] },
  { name: '4-native-captured-pipe-cmd', command: PS51, args: ['-NoLogo', '-NoProfile', '-NonInteractive', '-Command', 'cmd.exe /c "echo FROM_CMD" | Out-String'] },
]

for (const c of CASES) {
  const rec = { name: c.name }
  try {
    const child = sandbox.spawn({ command: c.command, args: c.args, cwd: ws })
    rec.pid = child.pid
    const r = await child.wait()
    rec.exitCode = r.exitCode
    rec.exitHex = hex(r.exitCode)
    rec.stdout = (r.stdout ?? Buffer.alloc(0)).toString('utf8').trim().slice(0, 200)
    rec.stderr = (r.stderr ?? Buffer.alloc(0)).toString('utf8').trim().slice(0, 200)
  } catch (e) {
    rec.threw = e?.message ?? String(e)
  }
  results.cases.push(rec)
}

try { sandbox.dispose() } catch (e) { results.disposeError = e?.message ?? String(e) }
fs.writeFileSync(outFile, JSON.stringify(results, null, 2), 'utf8')

[yzyyohh]

The reproduction harness is now published as a runnable repo, so the matrix above can be re-run on any Windows host:

https://github.com/yzyyohh/dsh-windows-sandbox-0xc0000142

It drives @deepseek-ai/dsh-sandbox-windows-acl directly (no harness in the loop), so the four cases in the matrix reproduce without any session state. It also ships the raw data for the two mitigations I measured and falsified, and the probe supports a noconsole host mode for the #810 comparison.

Note for anyone running it: AclSandbox.init() leaves a standing ACE on the workspace directory you pass — point it at a scratch directory, not a real project tree.