[Windows Desktop 0.2.0-rc.2] All shell tools die with "PTY shell exited during startup" when sandbox mode is workspace-write (root cause: GUI-subsystem Electron as ACL sandbox runner host + ConPTY)

[asgdf-d]

Summary

On the Windows desktop build, every shell tool invocation (pwsh, and even cmd /c ...)
fails instantly with the constant error Error: PTY shell exited during startup while
the sandbox mode is workspace-write. Nothing in the command, path, encoding, or cwd
changes the outcome — the process never lives long enough to execute anything. Setting
DSH_PERMISSION_MODE=danger-full-access (per-session or via the user environment
variable on a fresh session) completely fixes it, which also pinpoints the failing layer.

Environment

• DeepSeek Harness desktop (official), host @deepseek-ai/dsh 0.2.0-rc.2
• Windows 11 Pro x64 (build 26200), zh-CN
• No PowerShell 7 installed → resolvePwshPath() falls back to Windows PowerShell 5.1
• Machine has no Git Bash; pwsh is the only shell tool

Reproduction

1. Fresh session on the desktop build (default sandbox mode = workspace-write).

2. Invoke the shell tool with any command — e.g. echo hello, Get-Content <file>,
   cmd /c dir C:\.

3. Every call returns immediately:

   Error: PTY shell exited during startup
   

   No exit code, no stderr, no resolved shell path is surfaced (see "Suggestions").

4. Fix A — set user env var DSH_PERMISSION_MODE=danger-full-access, fully restart the
   app, open a new session → shell tools work.

5. Fix B — in an existing broken session, switch the permission preset back to
   danger-full-access → shell tools immediately work again (session events confirm
   sandbox/mode switching back).

Note the session-level override semantics: a session whose event stream records
sandbox/mode: workspace-write stays broken even after the app is restarted with
DSH_PERMISSION_MODE=danger-full-access in the host process environment (verified by
reading the host process environment block directly). This makes the bug look
intermittent to users, but it is deterministic per (session mode × sandbox runner path).

Root-cause analysis (source-level, verified locally)

Chain: the persistent shell session goes through dsh-terminal-bash's PTY
(node-pty / ConPTY). When sandboxPolicy.mode != danger-full-access, the tool argv is
wrapped by sandbox.confine() into the windows-acl runner:

[process.execPath, <asar>\dsh-sandbox-windows-acl\lib\runner.js, --workspace …, --temp …, --mode …, --, pwsh …]

In the desktop host, process.execPath is DeepSeek Harness.exe — a GUI-subsystem
Electron binary run with ELECTRON_RUN_AS_NODE. Three-way control experiment on this
machine:

Host binary	ACL runner	ConPTY	Result
plain node.exe (console subsystem)	yes	yes	✅ works (prompt, OSC 133 marks all correct)
Electron (RunAsNode)	yes	no	✅ works
Electron (RunAsNode)	yes	yes	❌ silent death (0-byte output; non-interactive exits 0 but all output is lost; interactive → inner console child gets no console → dies at startup → PTY reports session_exit)

So the sandbox runner itself is functional; the failure is the GUI-subsystem host +
ConPTY combination (an inner console child spawned by a GUI-subsystem parent gets no
console). It likely affects every Windows desktop user while the default
workspace-write sandbox is on.

Workaround currently in use: DSH_PERMISSION_MODE=danger-full-access (accepting the
disabled file sandbox as a trade-off).

Suggestions

1. Fix the runner/PTY interaction for GUI-subsystem hosts (e.g. attach the inner
   process to a fresh console, or avoid ConPTY wrapping of the runner child, or ship a
   console-subsystem helper binary as the sandbox host).
2. Regardless of the fix, surface diagnostics in the tool error: exit code, first
   lines of stderr, and the resolved shell absolute path. With the current constant
   one-liner there is nothing to distinguish "shell binary missing" from "sandbox
   runner killed the child", and users cannot self-diagnose.

Happy to provide more traces (node-pty repro scripts, runner logs) if useful.

中文摘要（可选读）

Windows 桌面版 0.2.0-rc.2 在默认 workspace-write 沙箱档位下，所有 shell 工具
（pwsh / cmd）启动即死，报错恒定为 PTY shell exited during startup，无退出码、无
stderr、无 shell 路径。根因：windows-acl 沙箱 runner 以 GUI 子系统的 Electron
（RunAsNode）为宿主、外层再套 ConPTY 时，内层 console 子进程拿不到控制台即死；纯
node 宿主同一 runner 同一 ConPTY 完全正常（三组对照实测）。DSH_PERMISSION_MODE= danger-full-access 可完全规避。另建议工具报错带上退出码 / stderr / 解析到的 shell
绝对路径，便于用户自查。

[argszero]

This is the cleanest separation of the variable in the whole family, and it holds up: one runner, one ConPTY, and the only thing that changes is the host binary carrying the runner. A console-subsystem node.exe host starts the confined shell — prompt and shell-integration marks correct — where the packaged desktop's GUI-subsystem Electron host (started with ELECTRON_RUN_AS_NODE=1) kills the child silently, zero bytes on both streams, and the non-interactive arm even exiting 0 with everything it printed lost. That last detail is why this looks like a hang or a flake rather than a failure, and it is the same console rule the 0xC0000142 family states for its own case: under the restricted token a console can be inherited but not created, so the binary that owns one — or owns none — is what the arms turn on.

Two consequences of your report that are easy to miss and that I have made explicit in a diagnostic plugin I maintain, @argszero/cordis-plugin-sandbox-grant-advisor (npm, 0.10.0):

• The outcome is deterministic per (session mode × host), not intermittent. Before your thread, the PTY advisory named the mode alone, so a reader who saw one attempt work would reasonably conclude the failure was flaky and keep retrying. It now names the host alongside the mode and says in as many words that a "working now" attempt in the same session is not evidence of flakiness.
• The mode that decides is the one the session records, not the one the environment now holds. Your observation that a session which streamed the confining mode keeps failing after the app is restarted with another mode in its environment — while switching inside the session takes effect at once — is now stated too, because it is the difference between "restart and try again" and "you have to change this in the right place".

The advisory still ships no command to run: there is no shell to run one in, and it tells the model to stop rather than retry. What it does hand the user is a fourth option, taken from #8313: run the session from a host that owns a console — the Web UI started from a terminal, whose process.execPath is a real node.exe — which was reported working under the same confining mode and the same version. danger-full-access stays described as a way to confirm the diagnosis, not as a fix, and it is now the last option rather than the third.

Your report is named as the measurement the section rests on, and #8313 joins the plugin's native-init family as the fifth report of 0xC0000142 — the same host variable seen from the other side.

npm: @argszero/cordis-plugin-sandbox-grant-advisor@0.10.0.

[longxing-alt]

Independent confirmation on a second machine, plus some process-level evidence we captured while it was failing.

Environment: Windows 10 Pro x64 (build 22631, zh-CN), desktop host 0.2.0-rc.2, no PowerShell 7 (falls back to Windows PowerShell 5.1), Git Bash present. Same symptom: every pwsh tool call fails with PTY shell exited during startup under workspace-write, while a fresh CLI harness from the same workspace, same mode, same temp root passed an end-to-end shell test during the same wall-clock window.

Evidence captured during the failure window (19:14–20:10 local):

• The Windows PowerShell event log shows zero engine-start events (ID 400/403) at the failure timestamps, while unrelated powershell.exe invocations on the same machine log normal 400/403 pairs. So the wrapped child dies before the PowerShell engine ever initializes — consistent with the console-inheritance mechanism proposed here.
• Each failed attempt still created its conpty conhost (conhost.exe --headless --width 160 --height 40 ... under the desktop host), the ACL lock file, and the dsh-* / dsh-subprocess-* scratch dirs in the redirected temp root — the seam's setup completes; only the confined child is lost.
• Every failed startup leaks one conhost.exe. 5 failures left 5 orphaned conhost processes (still alive 40+ minutes later); a long-running instance accumulated 36 over ~28 hours. BashTerminalBackend.spawn does call session.close('PTY startup failed') via rejectAfterStartupCleanup, but the conhost behind the ConPTY is not reaped on this path.
• After the shell recovered, the persistent REPL showed up as powershell.exe -NoLogo -NoProfile directly parented by the desktop host, with no node.exe runner sibling visible — which may help pinpoint whether the terminal path applies the restricted token in-process rather than through the argv-prefix runner.

One data point that doesn't fit the deterministic model: our failures ran 19:14–20:10 (including immediately after a full app restart at 19:53), then recovered at 20:39 with no restart and no config change — same session, same recorded workspace-write mode. Whatever gates console inheritance for the GUI-host runner apparently cleared on its own. Posting this in case it helps narrow which layer decides.

Happy to capture more (child argv via process polling, ETW) next time it reproduces.

[szb15137]

Hi,
I met a similar problem when I was using the desktop app. However, since I am not familiar with DSH, I will paste what AI found in the following. Thank you very much.

---

Non-PTY data point: same call site, same variable, raw 0xC0000142 from dsh-tool-pwsh

Environment for the measurements below: Windows 11 Pro (10.0.26200), desktop build 0.2.0-rc.2 (DeepSeek Harness.exe FileVersion 0.2.0-rc.2), bundled node v24.21.0, no PowerShell 7, so the pwsh tool resolves to Windows PowerShell 5.1.

The session these measurements come from used the ordinary pwsh tool (dsh-tool-pwsh over dsh-pwsh-sandbox: a fresh pwsh -Command per call, pipes, no PTY), not the PTY terminal tool. In that surface the symptom differs from the title of this discussion, but the cause appears identical: every confined call (workspace-write) returns exit code 3221225794 (0xC0000142) with zero stdout and stderr, and with no windows-acl-run: line, so the seam does not classify it as a runner failure. The identical command under danger-full-access returns normally. The failure is therefore not PTY-specific: PTY shell exited during startup is one surface of it, and the plain non-PTY tool is another.

Same call site, confirmed against the running build rather than a checkout. The desktop bundle is an asar archive, so its packages can be read out of resources\app.asar; the sandbox package inside it is @deepseek-ai/dsh-sandbox-windows-acl@0.2.0-rc.2. Its sibling dsh-sandbox-local contains the call site identified in the opening post: windowsAclRunnerInvocation() returns [process.execPath, <resolved runner.js>]. In the desktop host, process.execPath is the GUI-subsystem DeepSeek Harness.exe, and the host-spawned shell's environment carries ELECTRON_RUN_AS_NODE=1.

Control experiment, driven with the running build's own extracted 0.2.0 code, through the same outer launch layer the job runner uses (@deepseek-ai/dsh-win32-process → spawnCurrentTokenJobProcess → koffi CreateProcessW with dwCreationFlags = 1028 and STARTUPINFO.dwFlags = 257, wShowWindow = 0), with an identical ACL-runner argv (--workspace … --temp … --mode workspace-write -- pwsh -Command "Write-Output …"):

runner argv[0]	result
bundled node.exe (console subsystem, v24.21.0)	✅ child output delivered, exit 0
DeepSeek Harness.exe (ELECTRON_RUN_AS_NODE=1)	❌ exit 0xC0000142, zero bytes
DeepSeek Harness.exe -e "console.log(…)" (ELECTRON_RUN_AS_NODE=1)	✅ exit 0

Electron-as-node is therefore fine on its own; only its role as the ACL runner host fails. The console state also differs between exactly those two binaries, measured with GetConsoleWindow() through koffi: 3345426 for the bundled node.exe and 0 for Electron-as-node, with the same command line and the same parent.

Excluded by direct measurement, so that these do not need to be re-checked: the keep-alive group is present in the restricting list ([logonSid, world, …writeSids]); the Job sets only JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE; there is no detached on win32 (detached: platform !== 'win32'); the fd-7 control channel works when its marker is set; encodeWindowsEnvironment produces a well-formed block and lpEnvironment is bound as PVOID; koffi loads and runs under Electron-as-node (KOFFI_LOAD_OK).

One arm differs from the control table in the opening post. That table records "Electron (RunAsNode) + no ConPTY" as working, whereas on this machine the non-PTY tool path fails deterministically with 0xC0000142. The hypothesis here is that the deciding variable is whether anything in the chain was created with CREATE_NO_WINDOW: launchWindowsJob spawns the job runner with windowsHide: true, but the job-runner→target spawn is a koffi CreateProcessW with dwCreationFlags = 1028 and only SW_HIDE from STARTUPINFO, which does not suppress console allocation, while the fallback (spawnSubprocess) passes windowsHide: platform === 'win32'. If the no-ConPTY arm was taken through the windowsHide shape, that would explain the split; if it was taken through the Job path, then the two machines differ and the selection between those paths becomes the variable to pin. That distinction matters, because it decides whether the observable outcomes are only {0xC0000142, PTY silent death} or also include success.

Fix candidate, verified. Re-running the identical confined chain with the app's own bundled resources\runtime\primary-runtime\dependencies\node\bin\node.exe as the runner program succeeds (child output delivered, exit 0). So either the runner host should not be a GUI-subsystem process.execPath — the app already ships a console-subsystem node — or the whole chain should be made console-less with CREATE_NO_WINDOW.

All arms reported in this discussion are consistent with one rule: under the restricted token the child can inherit an already-attached console or run with no console at all, but it cannot be attached to a console that this spawn created — a ConPTY pseudoconsole, or a freshly allocated console.

Repro scripts can be provided if they would help.

[longxing-alt]

Triage summary for maintainers - everything below is consolidated from this thread (nothing new; all sourced from the posts above): the root cause, the one unexplained arm, the verified fix, and the diagnostics asks. Credit: @asgdf-d (original report and root-cause isolation), @argszero, @longxing-alt, @szb15137 (independent measurements).

(This repo has Issues disabled, so this discussion is the tracking vehicle - please prioritize/label here.)

Summary

On the Windows desktop build, every shell tool invocation fails while sandbox mode is workspace-write — pwsh and even cmd /c ... — with the constant error Error: PTY shell exited during startup. Nothing in the command, path, encoding, or cwd changes the outcome; the process never lives long enough to execute anything. danger-full-access completely fixes it, which pinpoints the failing layer.

A second surface with the same root cause (@szb15137): the plain non-PTY pwsh tool (dsh-tool-pwsh over dsh-pwsh-sandbox, a fresh pwsh -Command per call, pipes) fails on every confined call with exit code 3221225794 (0xC0000142, STATUS_DLL_INIT_FAILED), zero stdout/stderr, and no windows-acl-run: line — so the seam does not classify it as a runner failure, and it looks like a silently-empty tool result.

Environment

• DeepSeek Harness desktop (official) 0.2.0-rc.2; bundled node v24.21.0; sandbox package inside the asar: @deepseek-ai/dsh-sandbox-windows-acl@0.2.0-rc.2
• Reproduced on Windows 11 Pro x64 build 26200 zh-CN (@asgdf-d), Windows 10 Pro x64 build 22631 zh-CN (@longxing-alt), and Windows 11 Pro 10.0.26200 (@szb15137)
• No PowerShell 7 on any of the three machines → resolvePwshPath() falls back to Windows PowerShell 5.1

Reproduction

1. Fresh session on the desktop build (default sandbox mode workspace-write).
2. Invoke any shell tool — echo hello, Get-Content <file>, cmd /c dir C:\.
3. Every call returns immediately with Error: PTY shell exited during startup — no exit code, no stderr, no resolved shell path surfaced.
4. DSH_PERMISSION_MODE=danger-full-access on a fresh session after a full restart, or switching the permission preset inside the session → shell tools work at once.

Session-override semantics (this is what makes the bug look intermittent to users, while it is deterministic per (session mode × sandbox runner path)): a session whose event stream records sandbox/mode: workspace-write stays broken even after the app is restarted with danger-full-access in the host process environment (verified by reading the host process environment block directly); switching the mode inside the session takes effect immediately.

Root cause

Chain: the persistent shell session goes through dsh-terminal-bash's PTY (node-pty / ConPTY). When sandboxPolicy.mode != danger-full-access, the tool argv is wrapped by sandbox.confine() into the windows-acl runner:

[process.execPath, <asar>\dsh-sandbox-windows-acl\lib\runner.js, --workspace …, --temp …, --mode …, --, pwsh …]

In the desktop host, process.execPath is DeepSeek Harness.exe — a GUI-subsystem Electron binary run with ELECTRON_RUN_AS_NODE. A GUI-subsystem runner host owns no console, so the confined console child must attach to a console created by that spawn — a ConPTY pseudoconsole (PTY path) or a freshly allocated console (non-PTY path) — and under the restricted token that fails during process startup → STATUS_DLL_INIT_FAILED.

Unified rule, consistent with every measurement so far: under the restricted token the child can inherit an already-attached console or run with no console at all, but it cannot be attached to a console that this spawn created.

Measurements

Three-way control table (@asgdf-d's machine — one runner, one ConPTY, only the host binary changes):

Host binary	ACL runner	ConPTY	Result
plain node.exe (console subsystem)	yes	yes	✅ works (prompt, OSC 133 marks all correct)
Electron (RunAsNode)	yes	no	✅ works
Electron (RunAsNode)	yes	yes	❌ silent death (0-byte output; non-interactive exits 0 with all output lost; interactive → inner console child gets no console → dies at startup → PTY reports session_exit)

Control table on a second machine (@szb15137, driven with the running build's own extracted 0.2.0 code through the same outer launch layer the job runner uses: @deepseek-ai/dsh-win32-process → spawnCurrentTokenJobProcess → koffi CreateProcessW with dwCreationFlags = 1028 and STARTUPINFO.dwFlags = 257, wShowWindow = 0; identical ACL-runner argv --workspace … --temp … --mode workspace-write -- pwsh -Command "Write-Output …"):

runner argv[0]	result
bundled node.exe (console subsystem, v24.21.0)	✅ child output delivered, exit 0
DeepSeek Harness.exe (ELECTRON_RUN_AS_NODE=1)	❌ exit 0xC0000142, zero bytes
DeepSeek Harness.exe -e "console.log(…)" (ELECTRON_RUN_AS_NODE=1)	✅ exit 0

Electron-as-node is fine on its own; only its role as the ACL runner host fails. GetConsoleWindow() (via koffi) differs exactly between those two binaries (non-zero vs 0) with the same command line and parent.

Excluded by direct measurement (no need to re-check): the keep-alive group is present in the restricting SID list ([logonSid, world, …writeSids]); the Job sets only JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE; no detached on win32 (detached: platform !== 'win32'); the fd-7 control channel works when its marker is set; encodeWindowsEnvironment produces a well-formed block (lpEnvironment bound as PVOID); koffi loads and runs under Electron-as-node.

Process-level evidence during the failure window (@longxing-alt): the Windows PowerShell event log shows zero engine-start events (400/403) at the failure timestamps while unrelated powershell.exe invocations log normal 400/403 pairs — the wrapped child dies before the engine ever initializes. Each failed attempt still creates the ConPTY conhost (conhost.exe --headless --width 160 --height 40 ...), the ACL lock file, and the dsh-* scratch dirs in the redirected temp root: the seam's setup completes, only the confined child is lost. Every failed startup leaks one orphaned conhost.exe (5 failures → 5 orphans still alive 40+ minutes later; a long-running instance accumulated 36 over ~28 hours — rejectAfterStartupCleanup closes the session but does not reap the conhost behind the ConPTY).

One arm to pin: spawn-path selection

• The OP's table records "Electron (RunAsNode) + no ConPTY" as ✅ working.
• On @szb15137's machine the non-PTY tool path fails deterministically with 0xC0000142.

Hypothesis: the deciding variable is whether anything in the chain was created with CREATE_NO_WINDOW. launchWindowsJob spawns the job runner with windowsHide: true, but the job-runner→target spawn is a koffi CreateProcessW with dwCreationFlags = 1028 (CREATE_SUSPENDED | CREATE_UNICODE_ENVIRONMENT) and only SW_HIDE from STARTUPINFO — which does not suppress console allocation — while the fallback (spawnSubprocess) passes windowsHide: platform === 'win32'. Which path gets selected decides the observable outcomes ({0xC0000142, PTY silent death} vs success), and would also explain the one observed self-recovery (recovered mid-session at 20:39 with no restart and no config change, same recorded workspace-write mode).

Related observation: after the shell recovered, the persistent REPL showed up as powershell.exe -NoLogo -NoProfile directly parented by the desktop host, with no node.exe runner sibling visible — the terminal path may apply the restricted token in-process rather than through the argv-prefix runner.

Suggested fixes

1. Runner host — resolve windowsAclRunnerInvocation() to the app's shipped console-subsystem node (resources\runtime\primary-runtime\dependencies\node\bin\node.exe) instead of process.execPath. Verified by @szb15137: the identical confined chain succeeds with that binary as the runner program.
2. Non-PTY spawn — add CREATE_NO_WINDOW (0x08000000) to the koffi CreateProcessW target spawn so the confined child never allocates a console. (The PTY path needs a different treatment, since it must attach the pseudoconsole.)
3. Diagnostics — surface exit code, first lines of stderr, and the resolved shell absolute path in the tool error; with the current constant one-liner users cannot distinguish "shell binary missing" from "sandbox runner killed the child". Additionally, classify a raw 0xC0000142 exit with zero output and no windows-acl-run: line as a runner failure, and log which spawn path (Job vs fallback) was selected.
4. ConPTY reaping — reap the conhost behind the ConPTY on the PTY startup failed cleanup path (each failure currently leaks one).

Workarounds until fixed

• Run the session from a host that owns a console — e.g. the Web UI started from a terminal, whose process.execPath is a real console-subsystem node (reported working under the same confining mode and version).
• danger-full-access confirms the diagnosis but is not a fix (the file sandbox is lost), and note the session-recorded mode is what decides: restarting the app with another mode in the environment does not fix an already-confined session.

Related: #8313 (same host variable seen from the other side, per the thread). Diagnostic tooling: @argszero/cordis-plugin-sandbox-grant-advisor@0.10.0 names the sandbox host alongside the mode and states explicitly that a "working now" attempt in the same session is not evidence of flakiness.

Repro material: @asgdf-d offered node-pty repro scripts / runner logs, @szb15137 offered repro scripts — happy to attach them here if maintainers want them.

---

Addendum (Oct 4) — folding in @OrangeStone446's fourth machine and a mechanism-level analysis from #8775:

• Shell-agnostic, fourth machine: reproduces on Windows 11 Home 10.0.26100 with PowerShell 7.6.6 properly installed (MSI; registry key and %ProgramFiles%\PowerShell\7\ both present) — not only the PowerShell 5.1 fallback the earlier machines hit. On Windows: every confined command dies with 0xC0000142 in workspace-write (default DACL names a capability SID the token does not carry) #8775's machine cmd.exe, 5.1 and MSIX pwsh 7.6.6 all die identically, so the failing shell binary does not matter.
• GUI-subsystem host confirmed at the binary level: the shipped DeepSeek Harness.exe PE header read directly — Machine = 0x8664, Subsystem = 2 (WINDOWS_GUI) — the spawn-side leg no longer rests on the GetConsoleWindow() difference alone.
• One cause, two surfaces (triage trap worth naming): the ephemeral pwsh tool surfaces a bare [exit code: 3221225794] with zero output, while the persistent PTY tool surfaces PTY shell exited during startup — and that string is the PTY service's own open-time rejection when the startup wait settles as session_exit (the top-level shell exited). A raw 0xC0000142 on this build is the same console arm, not a shell-binary or AV problem.
• Filesystem fence re-verified on the fourth machine: writes inside the workspace succeed and outside are denied under workspace-write; the bundled diagnose-windows-sandbox-acl run returned VERDICT=NOT_THIS_CLASS (no missing WRITE_DAC/WRITE_OWNER, no S-1-15-2-* package ACEs). The token and the workspace ACL are fine; only child-process creation fails.
• Mechanism-level candidate root cause — Windows: every confined command dies with 0xC0000142 in workspace-write (default DACL names a capability SID the token does not carry) #8775 (@HuJiaming007): a parameterized bisect varying only the SIDs entering the token isolates the trigger to the token default DACL: when the default-DACL grant is a SID the restricted token does not carry as an enabled group (the workspace capability SID S-1-5-4-…, or present-but-disabled BUILTIN\Guests), every child dies exactly where its first CRT DLL (ucrtbase/msvcrt) would initialize (image-load traces); when the grant is an enabled, resolvable SID (BUILTIN\Users), the identical GUI-host spawn succeeds. This plausibly explains the console rule above — a spawn-created console is one of the objects a child cannot access while its default DACL names an unusable SID — and implies a third fix beyond the two listed above: grant an enabled SID (e.g. the logon SID) in the token's default DACL. The two analyses are complementary, not competing.
• AV confound, recorded not weighted (@OrangeStone446): 360安全卫士 13.0.0.2003 (real-time ZhuDongFangYu.exe; minifilter 360FsFlt.sys among 13 filter drivers). Per-machine confound — not a necessary condition, since the other reproductions report no AV.
• Resolver gap split out: the winget MSIX/Store PowerShell install (app-execution alias only; no PowerShellCore\InstalledVersions key, no %ProgramFiles%\PowerShell\7\; invisible to candidatePwshPaths() and PATH while winget list still reports it) is being filed by @OrangeStone446 as its own item; dsh-win32 doctor should detect the alias-only shape and suggest --installer-type msi.
• Family index for triage (same exit code, same class, across versions): [Bug] pwsh tool crashes with 0xC0000142 when falling back to Windows PowerShell 5.1 under the Windows ACL sandbox #1532 (Aug 14, pwsh 5.1 fallback), Windows 桌面版：受限模式（workspace-write）下 pwsh 工具必然失败 0xC0000142；同一版本经 npx 启动的 Web UI 正常 #8313 (Web UI started from a terminal works), [Windows Desktop 0.2.0-rc.2] All shell tools die with "PTY shell exited during startup" when sandbox mode is workspace-write (root cause: GUI-subsystem Electron as ACL sandbox runner host + ConPTY) #8322 (this thread — root-cause isolation), [Bug] Windows: pwsh 工具在 workspace-write 沙箱下 100% 失败（0xC0000142），同参数 runner 直调正常 #8613 (Oct 2, runner direct-call OK), Windows: every confined command dies with 0xC0000142 in workspace-write (default DACL names a capability SID the token does not carry) #8775 (Oct 3, default-DACL bisect).

[OrangeStone446]

I met a similar problem yet.

Windows: pwsh child process cannot start under Workspace Write (0xC0000142 STATUS_DLL_INIT_FAILED)

Summary

On Windows, with the default Workspace Write permission mode, every call to the model-facing pwsh tool ends immediately with 0xC0000142 (STATUS_DLL_INIT_FAILED) — even a trivial echo hi — with no stdout and no stderr. Switching the same session to full access (danger-full-access) makes the identical command succeed at once. The file sandbox itself works correctly (write inside the workspace succeeds, write outside is denied); only process creation is broken.

Environment

Item	Value
OS	Windows 11 Home (Chinese), 10.0.26100
DSH Desktop	0.2.0-rc.2 (installed at D:\DSH)
Node	24.21.0
PowerShell	7.6.6 x64, MSI install, C:\Program Files\PowerShell\7\pwsh.exe
Account	local Administrator (high integrity)
Security software	360 Total Security (AntiVirusProduct productState = 331776, enabled) + Windows Defender
Workspace	D:\DSH--Test, on drive D:
Host	desktop DeepSeek Harness.exe, profile desktop

Conclusion: the filesystem ACL fence works; only starting a child process under the restricted token fails.

Causes ruled out

Each of the following was tested, not assumed:

1. Not a missing PowerShell installation. C:\Program Files\PowerShell\7\pwsh.exe exists and runs standalone; the registry key HKLM:\SOFTWARE\Microsoft\PowerShellCore\InstalledVersions carries SemanticVersion=7.6.6; the system PATH contains C:\Program Files\PowerShell\7\. Running it from an ordinary terminal prints 7.6.6.

2. Not executable resolution. The first candidate of candidatePwshPaths() in @deepseek-ai/dsh-pwsh-local is %ProgramFiles%\PowerShell\7\pwsh.exe, so it always matches; the profile's cordis.patch.yml contains no pwshPath override.

3. Not a workspace ACL problem. A full diagnose-and-repair run of this repository's bundled diagnose-windows-sandbox-acl script against D:\DSH--Test (run unconfined) reported:

   VERDICT=NOT_THIS_CLASS
   "No package allow ACE and no missing WRITE_DAC or WRITE_OWNER was
    observed on the inspected objects; no ACL change was needed."
   SUMMARY FIXED=0 GRANTED=0 REFUSED=0 RESTORED=0
   

   That is, writeDac=True and writeOwner=True, and no S-1-15-2-* foreign package ACEs to remove. The full record is in the appendix below.

4. Not an unreadable binary. C:\Program Files\PowerShell\7 grants BUILTIN\Users ReadAndExecute, Synchronize; the directory carries no explicit integrity label (it inherits Medium).

Suspected direction

0xC0000142 surfaces at the token-construction layer, not the file-permission layer. DSH's own sandbox documentation names this exact exit code:

The keep-alive group (logon SID + Everyone) is present in both modes: without it, early DLL initialization dies with 0xC0000142 and CNG crashes pwsh with 0xE0434352.

So the suspicion is that the Windows ACL restricted-token runner (@deepseek-ai/dsh-sandbox-windows-acl) fails to create a usable restricted token on this machine. I tried to reproduce the mechanism standalone (CreateRestrictedToken + set the low-integrity label + CreateProcessWithTokenW) but could not complete it, because SetTokenInformation returned 998. So the root cause is not confirmed — only the exclusionary evidence above is offered.

Impact and workaround

• Impact: in Workspace Write the sandboxed shell is entirely unusable; the session must be widened to full access to run any command at all, which removes the file-sandbox protection.
• Workaround: switch the session to full access whenever commands must run.
• Note: the failure predates any installation change on this machine — see WARN powershell: PowerShell 7 not found in the dsh-win32 doctor output.

Aside: a separate installation trap worth confirming

On this machine, winget install --id Microsoft.PowerShell installs the MSIX/Store build (PowerShell-7.6.6.msixbundle), which:

• lands in C:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.6.0_x64__8wekyb3d8bbwe;
• does not write the PowerShellCore\InstalledVersions registry key;
• does not create C:\Program Files\PowerShell\7\;
• exposes pwsh.exe only through the WindowsApps app-execution alias.

DSH's resolver only looks at %ProgramFiles%\PowerShell\7\pwsh.exe and PATH, so it reports "PowerShell 7 not found" even though winget list shows the package as installed. Installing the MSI instead (or --installer-type msi) clears that warning. This may deserve its own hint in dsh-win32 doctor.

Appendix: raw `diagnose-windows-sandbox-acl` record (acl-report-4a4debcf158f497aa3ce78b6b549893a.jsonl, all 12 lines)

{"kind":"invocation","operation":"repair","path":"","status":"started","reason":"Inspect the requested paths, then repair the ACL problems this run can prove, before anything else is attempted.","details":{"paths":["D:\\DSH--Test"],"outputDirectory":"D:\\DSH--Test\\.acl-recovery","allowRoot":"D:\\DSH--Test","recoveryRecord":""}}
{"kind":"action","operation":"prepare_report","path":"D:\\DSH--Test\\.acl-recovery","status":"started","reason":"Create the recovery directory and a new JSONL report that keeps every record, because tool output is truncated to its tail.","details":{"effect":"files","id":1}}
{"kind":"action","operation":"prepare_report","path":"D:\\DSH--Test\\.acl-recovery","status":"completed","reason":"Create the recovery directory and a new JSONL report that keeps every record, because tool output is truncated to its tail.","details":{"effect":"files","id":1}}
{"kind":"action","operation":"initialize","path":"","status":"started","reason":"Load read-only access checks and DACL-only writes before inspecting permissions.","details":{"effect":"none","id":2}}
{"kind":"action","operation":"initialize","path":"","status":"completed","reason":"Load read-only access checks and DACL-only writes before inspecting permissions.","details":{"effect":"none","id":2}}
{"kind":"observation","operation":"caller","path":"","status":"read","reason":"The caller token determines effective access; unconfined execution does not imply elevation.","details":{"integrity":"S-1-16-12288 (High)","sid":"S-1-5-21-2323057633-2177745152-3024662527-500"}}
{"kind":"observation","operation":"inspect_acl","path":"D:\\DSH--Test","status":"read","reason":"Read the ACL and check effective WRITE_DAC and WRITE_OWNER; observed ACEs alone do not identify which rule caused a denial.","details":{"owner":"S-1-5-32-544","acesOmitted":false,"writeOwner":true,"lowLabel":true,"aces":[{"sid":"S-1-1-0","type":"Deny","rights":"DeleteSubdirectoriesAndFiles","inherited":false,"inheritance":"ContainerInherit","propagation":"None"},{"sid":"S-1-4-889669682-638475085","type":"Allow","rights":"DeleteSubdirectoriesAndFiles, Write, Delete, Synchronize","inherited":false,"inheritance":"ContainerInherit, ObjectInherit","propagation":"None"},{"sid":"S-1-5-32-544","type":"Allow","rights":"FullControl","inherited":true,"inheritance":"None","propagation":"None"},{"sid":"S-1-5-32-544","type":"Allow","rights":"268435456","inherited":true,"inheritance":"ContainerInherit, ObjectInherit","propagation":"InheritOnly"},{"sid":"S-1-5-18","type":"Allow","rights":"FullControl","inherited":true,"inheritance":"None","propagation":"None"},{"sid":"S-1-5-18","type":"Allow","rights":"268435456","inherited":true,"inheritance":"ContainerInherit, ObjectInherit","propagation":"InheritOnly"},{"sid":"S-1-5-11","type":"Allow","rights":"Modify, Synchronize","inherited":true,"inheritance":"None","propagation":"None"},{"sid":"S-1-5-11","type":"Allow","rights":"-536805376","inherited":true,"inheritance":"ContainerInherit, ObjectInherit","propagation":"InheritOnly"},{"sid":"S-1-5-32-545","type":"Allow","rights":"ReadAndExecute, Synchronize","inherited":true,"inheritance":"None","propagation":"None"},{"sid":"S-1-5-32-545","type":"Allow","rights":"-1610612736","inherited":true,"inheritance":"ContainerInherit, ObjectInherit","propagation":"InheritOnly"}],"errors":[],"writeDac":true}}
{"kind":"observation","operation":"inspect_acl","path":"D:\\","status":"read","reason":"Read the ACL and check effective WRITE_DAC and WRITE_OWNER; observed ACEs alone do not identify which rule caused a denial.","details":{"owner":"S-1-5-18","acesOmitted":false,"writeOwner":true,"lowLabel":null,"aces":[{"sid":"S-1-5-11","type":"Allow","rights":"-536805376","inherited":false,"inheritance":"ContainerInherit, ObjectInherit","propagation":"InheritOnly"},{"sid":"S-1-5-11","type":"Allow","rights":"Modify, Synchronize","inherited":false,"inheritance":"None","propagation":"None"},{"sid":"S-1-5-18","type":"Allow","rights":"FullControl","inherited":false,"inheritance":"None","propagation":"None"},{"sid":"S-1-5-18","type":"Allow","rights":"268435456","inherited":false,"inheritance":"ContainerInherit, ObjectInherit","propagation":"InheritOnly"},{"sid":"S-1-5-32-544","type":"Allow","rights":"268435456","inherited":false,"inheritance":"ContainerInherit, ObjectInherit","propagation":"InheritOnly"},{"sid":"S-1-5-32-544","type":"Allow","rights":"FullControl","inherited":false,"inheritance":"None","propagation":"None"},{"sid":"S-1-5-32-545","type":"Allow","rights":"ReadAndExecute, Synchronize","inherited":false,"inheritance":"None","propagation":"None"},{"sid":"S-1-5-32-545","type":"Allow","rights":"-1610612736","inherited":false,"inheritance":"ContainerInherit, ObjectInherit","propagation":"InheritOnly"}],"errors":[],"writeDac":true}}
{"kind":"observation","operation":"subtree_scan","path":"D:\\DSH--Test","status":"read","reason":"The caller cannot provision this directory, or it is the authorized root, so explicit package allow ACEs under it were collected in the same run; no reparse point or managed application tree is entered.","details":{"visited":7,"unreadable":0,"packageSources":[],"truncated":false}}
{"kind":"decision","operation":"classify","path":"D:\\DSH--Test","status":"NOT_THIS_CLASS","reason":"No package allow ACE was observed and both required rights are available. Other ACL restrictions and causes of the original failure are not ruled out.","details":{"writeOwner":true,"writeDac":true,"packageObjects":[]}}
{"kind":"decision","operation":"repair","path":"D:\\DSH--Test","status":"skipped","reason":"No package allow ACE and no missing WRITE_DAC or WRITE_OWNER was observed on the inspected objects; no ACL change was needed.","details":{}}
{"kind":"summary","operation":"repair","path":"D:\\DSH--Test","status":"completed","reason":"Operation completion records API execution; verification records the observed result. Only rerunning the original confined operation can confirm its failure is resolved.","details":{"granted":0,"recoveries":[],"operations":[{"id":1,"operation":"prepare_report","path":"D:\\DSH--Test\\.acl-recovery","effect":"files","status":"completed"},{"id":2,"operation":"initialize","path":"","effect":"none","status":"completed"}],"automaticRollback":true,"restored":0,"rollback":"not-needed","report":"D:\\DSH--Test\\.acl-recovery\\acl-report-4a4debcf158f497aa3ce78b6b549893a.jsonl","rollbackCommands":[],"observationFailures":0,"scanTruncated":false,"fixed":0,"nextAction":"stop","refused":0,"exitCode":0}}

[longxing-alt]

@OrangeStone446 Thanks — this is a clean exclusion dataset, and it slots into the consolidated triage summary above without changing the picture. Two notes on the suspected direction:

• Your own checks actually rule out the token-construction hypothesis: the file-sandbox results (write inside the workspace succeeds, write outside is denied) prove the restricted token is created and enforced correctly on this machine. What fails is only the spawn of a console child under that token when the runner host is the GUI-subsystem desktop binary — the console rule in the summary above (under the restricted token a console can be inherited or absent, never newly created by that spawn, whether a ConPTY pseudoconsole or a fresh allocation). Your doc quote about the keep-alive group describes a second, separate 0xC0000142 trigger; @szb15137's control table excludes keep-alive absence by direct measurement, so on these machines it is the console arm.
• Your machine also fails with a proper pwsh 7.6.6 MSI install, which strengthens the shell-agnostic reading — the earlier three reports were all on the PowerShell 5.1 fallback, so the failing shell binary does not matter.

One variable worth keeping visible for maintainers: 360 Total Security on this machine (the other reports don't mention AV). Process creation under restricted tokens is a classic AV-minifilter interaction point, so it is a per-machine confound worth recording — though evidently not a necessary condition, given the other reproductions.

The winget MSIX/Store PowerShell trap (app-execution alias only, no PowerShellCore\InstalledVersions key, no %ProgramFiles% folder, invisible to candidatePwshPaths() and PATH) is a real, separate resolver gap — agreed it deserves its own hint in dsh-win32 doctor; probably worth its own discussion item so it does not get lost inside this thread.

[OrangeStone446]

Thanks — the correction is well taken, and it removes a wrong lead I introduced. Two clarifications from my own reproduction attempt, plus the AV variable you asked to record. 1. Direct confirmation that the host is the GUI-subsystem binary I read the PE header of the shipped desktop executable rather than inferring it: D:\DSH\DeepSeek Harness.exe  Machine   = 0x8664 (x64)  Subsystem = 2  → WINDOWS_GUI   (no console by default) Independently confirmed by parsing the same header from a separate Node process, so this build is squarely the "GUI-subsystem desktop binary as runner host" shape. That is the spawn-side leg only; I have not tested whether a conhost-attached host resolves it on this machine, and I would rather leave that to you than claim it. 2. Two tool paths, one cause, two different error surfaces Worth folding into the triage summary, because the two look unrelated at first sight: PathWhat the user sees on this machine ephemeral pwsh tool (fresh pwsh -Command per call)no output at all, just [exit code: 3221225794] persistent PTY pwsh toolPTY shell exited during startup I confirmed the second string is the PTY service's own open-time rejection: the code throws exactly when the startup wait settles as session_exit, i.e. the top-level shell exited. So a report shaped like "the shell tool prints a raw 0xC0000142 and nothing else" is the same console arm — it just never reaches the PTY layer that produces the friendlier message. A triage reading of 0xC0000142 as a shell-binary or AV problem is therefore a trap on this build. Also consistent with your reading: my standalone attempt to reproduce the token path died in SetTokenInformation (998, insufficient handle rights) before any process was created. That never touched child creation, so it neither supported nor refuted anything — I have dropped the keep-alive quote from my report and will point at @szb15137's table instead. 3. AV variable you asked to keep visible 360 Total Security, complete record for the thread: product 360安全卫士, version 13.0.0.2003, C:\Program Files (x86)\360\360Safe AntiVirusProduct productState = 331776 real-time module running: ZhuDongFangYu.exe (主动防御) minifilter present and running: 360FsFlt.sys, alongside BAPIDRV64.sys, 360AntiHijack64.sys, 360AntiSteal64.sys, 360Box64.sys, 360qpesv64.sys, 360Sensor64.sys (13 drivers total) Given your note that the other reproductions have no such AV, I agree this is a per-machine confound and not a necessary condition — recorded, not weighted. 4. MSIX resolver gap Agreed it should be its own item rather than a footnote here. The shape: winget install --id Microsoft.PowerShell installs the .msixbundle, which exposes pwsh.exe only through the WindowsApps app-execution alias and writes neither PowerShellCore\InstalledVersions nor C:\Program Files\PowerShell\7\, so it is invisible to candidatePwshPaths() and to PATH; winget list still reports it as installed. A --installer-type msi note in dsh-win32 doctor would prevent the misdiagnosis. I will open it separately so it does not get lost in this thread. 橙石流萤 ***@***.*** 原始邮件 发件人：Xingyu Long ***@***.***> 发件时间：2026年10月4日 00:52 收件人：deepseek-ai/deepseek-harness ***@***.***> 抄送：OrangeStone446 ***@***.***>, Mention ***@***.***> 主题：Re: [deepseek-ai/deepseek-harness] [Windows Desktop 0.2.0-rc.2] All shell tools die with "PTY shell exited during startup" when sandbox mode is workspace-write (root cause: GUI-subsystem Electron as ACL sandbox runner host + ConPTY) (Discussion #8322) @OrangeStone446 Thanks — this is a clean exclusion dataset, and it slots into the consolidated triage summary above without changing the picture. Two notes on the suspected direction: Your own checks actually rule out the token-construction hypothesis: the file-sandbox results (write inside the workspace succeeds, write outside is denied) prove the restricted token is created and enforced correctly on this machine. What fails is only the spawn of a console child under that token when the runner host is the GUI-subsystem desktop binary — the console rule in the summary above (under the restricted token a console can be inherited or absent, never newly created by that spawn, whether a ConPTY pseudoconsole or a fresh allocation). Your doc quote about the keep-alive group describes a second, separate 0xC0000142 trigger; @szb15137's control table excludes keep-alive absence by direct measurement, so on these machines it is the console arm. Your machine also fails with a proper pwsh 7.6.6 MSI install, which strengthens the shell-agnostic reading — the earlier three reports were all on the PowerShell 5.1 fallback, so the failing shell binary does not matter. One variable worth keeping visible for maintainers: 360 Total Security on this machine (the other reports don't mention AV). Process creation under restricted tokens is a classic AV-minifilter interaction point, so it is a per-machine confound worth recording — though evidently not a necessary condition, given the other reproductions. The winget MSIX/Store PowerShell trap (app-execution alias only, no PowerShellCore\InstalledVersions key, no %ProgramFiles% folder, invisible to candidatePwshPaths() and PATH) is a real, separate resolver gap — agreed it deserves its own hint in dsh-win32 doctor; probably worth its own discussion item so it does not get lost inside this thread. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today! You are receiving this because you were mentioned.

[HuJiaming007]

Independent reproduction: the GUI host is the trigger condition, the token default DACL is the defect

Note: the full report and the patch also live in #8775. Everything needed to act is
inline below as well — the controlled experiment, the upstream status, the patch, and the
caveats on the two fixes listed in the consolidated summary — so nothing here depends on
following a link.

I filed #8775 (the parameterized default-DACL bisect). Folding the two together, I ran the
missing controlled arm on a fourth machine — Windows 11 build 22635.5305 x64, desktop
0.2.0-rc.2 — with the shipped runner and the unmodified host binary. Only the token
changed between arms.

1. The console shape is not the deciding variable

Held constant across all four arms: GUI-subsystem host (Electron 44.0.0 run as node, no
console), ConPTY created by node-pty inside that host, pty child = shipped runner,
target = cmd.exe /c echo PTY-CHILD-OK. Exit code is the confined child's own exit status,
reported through a file because the ConPTY delivered 0 bytes in every arm (see §3).

sandbox mode	SID in the token's default DACL	confined child exit	ConPTY bytes
read-only	EVERYONE (enabled group of the token)	0	0
workspace-write	capability SID S-1-4-… (current code)	3221225794 (0xC0000142)	0
workspace-write	logon SID (one-line patch)	0	0
read-only	logon SID (patch, control)	0	0

Same host binary, same ConPTY, same argv, same target: flipping only the default-DACL SID
flips the outcome. So "the confined child cannot be attached to a console this spawn created"
describes when the defect bites, not the defect itself.

A model that fits every table in this thread: the default-DACL ACE must satisfy both
access checks for any object the confined child creates — pass 1 against the token's own
enabled SIDs, and pass 2 (WRITE_RESTRICTED) against the restricting list. A capability
SID satisfies pass 2 only, so the ACE grants nothing in the intersection and the child cannot
use an object it just created.

• Host owns or inherits a console → the confined child inherits it, creates nothing →
  works even unpatched. This is why "plain node.exe + ACL runner + ConPTY" works and why
  Windows 桌面版：受限模式（workspace-write）下 pwsh 工具必然失败 0xC0000142；同一版本经 npx 启动的 Web UI 正常 #8313 ("Web UI started from a terminal works") works.
• Host has no console (the GUI-subsystem desktop host) → the confined child must create
  the console object itself → its DACL comes from the poisoned token default → dies during
  init. That is the desktop PTY surface and the non-PTY cmd /c / pwsh surface.

This also covers the arm marked "one arm to pin": the question for the ✅ "Electron +
no ConPTY" row is whether anything in that chain owned a console the child could inherit —
under this model, an inherited console makes the shape pass without any patch.

2. On the two suggested fixes

Runner host → the shipped console node.exe. Reproduced here as a workaround: with a
console-subsystem runner host, the confined child inherits a console instead of creating one.
Two caveats:

1. It does not repair the defect — the default DACL is still poisoned for every other object
   the child creates.
2. The shipped node.exe cannot run runner.js out of app.asar: measured on this
   machine, exit 1 with the module loader failing on that path (only Electron carries the
   asar fs shim). So that fix also requires shipping the runner unpacked, or as a native
   runner executable — which matches @szb15137 verifying it against "the running build's own
   extracted 0.2.0 code".

CREATE_NO_WINDOW on the koffi target spawn. This one is contraindicated by the
package's own documentation — dsh-sandbox-windows-acl/README.md:127:

Console isolation is unavailable — children created with CREATE_NO_WINDOW /
CREATE_NEW_CONSOLE die during DLL initialization with STATUS_DLL_INIT_FAILED
(0xC0000142); children share the host console, and pipe-based stdio redirection is
unaffected.

CREATE_NO_WINDOW still creates a console object, so the poisoned default DACL still applies.
Prediction (not measured): once the default DACL is fixed, that documented limitation should
disappear and console isolation may become available — worth re-testing rather than adding the
flag first.

Recommended instead: the one-line change already attached to #8775 —

-setTokenDefaultDaclGrant(api, restrictedToken, this.tempWriteSidPtr ?? this.writeSidPtr ?? worldSid)
+setTokenDefaultDaclGrant(api, restrictedToken, logonSid)

worldSid also works and is what read-only already resolves to; the logon SID is the
narrower choice (session-scoped) and preserves the intent of the existing comment at
src/index.ts:292. On this machine it repairs both surfaces with the host binary
untouched: the ephemeral one (0xC0000142, zero stdout/stderr) and the ConPTY one above.

3. Diagnostics asks — confirmations from these runs

• Confirmed the seam does not classify a bare 3221225794 as a runner failure: no
  windows-acl-run: line is emitted, so it surfaces as a silently empty tool result.
• For the PTY surface, note that the ConPTY delivered 0 bytes even on the successful arms;
  the exit status only survived because it was written to a file. "Silent death" is therefore
  partly a capture property of a GUI-subsystem pty child, not only the startup failure.
• ConPTY reaping: after my arms, 2 conhost.exe were still alive (0.3 min and 18 min old) —
  consistent with the leak report, though I cannot attribute each one precisely.

Upstream status at the time of writing

• master still carries the pre-fix call site:
  setTokenDefaultDaclGrant(api, restrictedToken, this.tempWriteSidPtr ?? this.writeSidPtr ?? worldSid);
• src/index.ts was last modified 2026-09-25 and src/token.ts 2026-09-19 — nothing since;
• the newest release (dsh-v0.2.1-alpha.1, 2026-10-03 03:48 UTC) predates this report, so the defect is live on every shipped build.

Patch (inline, self-contained)

diff --git a/packages/sandbox/sandbox-windows-acl/src/index.ts b/packages/sandbox/sandbox-windows-acl/src/index.ts
index 5de5d47..4fc7746 100644
--- a/packages/sandbox/sandbox-windows-acl/src/index.ts
+++ b/packages/sandbox/sandbox-windows-acl/src/index.ts
@@ -290,18 +290,21 @@ export class AclSandbox {
       restrictTokenIntegrity(api, restrictedToken, lowLabelSid)
       this.token = restrictedToken
       // The restricted token's default DACL still names only the user's
-      // ambient SIDs — none of the restricting SIDs. Every NEW object the
+      // ambient SIDs — none of the capability SIDs. Every NEW object the
       // confined process creates (anonymous stdio pipes, sync objects) takes
-      // its DACL from that default, so the write pass-2 check would deny
-      // pipe creation (ERROR_ACCESS_DENIED; Node EPERM) and break every
-      // piped-stdio grandchild spawn. Merge a full-access ACE for a
-      // restricting SID (the PRIVATE temp SID when present, otherwise the
-      // workspace SID, or Everyone under read-only): new-object creation
-      // stays gated by the parent object's DACL, while the new object's own
-      // DACL passes pass-2. Choosing the temp SID prevents default-DACL
-      // objects in one session's temp tree from acquiring the shared
-      // workspace capability.
-      setTokenDefaultDaclGrant(api, restrictedToken, this.tempWriteSidPtr ?? this.writeSidPtr ?? worldSid)
+      // its DACL from that default, and such an object must pass BOTH access
+      // checks: pass 1 against the token's own enabled SIDs, and pass 2
+      // (WRITE_RESTRICTED) against the restricting list. An ACE naming a
+      // capability SID satisfies pass 2 only, so the confined process cannot
+      // write an object it just created and dies during early CRT
+      // initialization (STATUS_DLL_INIT_FAILED / 0xC0000142; reproduced on
+      // Win11 22635 with cmd.exe, powershell.exe and pwsh). The logon SID is
+      // the SID that satisfies both: an enabled group of the token (pass 1)
+      // that the restricting list already carries in either mode (pass 2).
+      // Session-scoped, it is also narrower than Everyone — which is what
+      // read-only effectively uses — and it never propagates the shared
+      // workspace or temp capability into default-DACL objects.
+      setTokenDefaultDaclGrant(api, restrictedToken, logonSid)
       if (api.closeHandle(currentToken) === 0) throwLastError(api, 'CloseHandle', 'current process token')
       currentTokenOpen = false
       this.api = api
diff --git a/packages/sandbox/sandbox-windows-acl/src/token.ts b/packages/sandbox/sandbox-windows-acl/src/token.ts
index d78bac0..79f9afe 100644
--- a/packages/sandbox/sandbox-windows-acl/src/token.ts
+++ b/packages/sandbox/sandbox-windows-acl/src/token.ts
@@ -100,11 +100,15 @@ export function makeWellKnownSid(api: Win32Bindings, type: number): NativePtr {
  * 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 merged ACE names a RESTRICTING SID (the
- * write SID under workspace-write, Everyone under read-only), so each new
- * object's own DACL passes pass-2 while object creation itself stays gated by
- * the parent container's DACL (files outside the granted trees remain
- * uncreatable). Fails closed: any Win32 failure throws before the spawn.
+ * piped-stdio grandchild spawn. The merged ACE must name a SID that passes
+ * BOTH checks: an enabled group of the token itself (pass 1) and a member of
+ * the restricting list (pass 2). A capability SID satisfies pass 2 alone, and
+ * the confined process then cannot write the objects it creates — it dies in
+ * early CRT initialization with STATUS_DLL_INIT_FAILED. The logon SID is the
+ * SID that satisfies both, so each new object's own DACL passes pass-2 while
+ * object creation itself stays gated by the parent container's DACL (files
+ * outside the granted trees remain uncreatable). Fails closed: any Win32
+ * failure throws before the spawn.
  * @param api - the binding table.
  * @param token - the restricted token to adjust (requires TOKEN_ADJUST_DEFAULT).
  * @param sidPtr - the restricting SID whose full-access ACE joins the default DACL.

4. Limits

• My PTY harness is an emulation (node-pty inside a GUI-subsystem Electron-as-node driver,
  spawning the shipped runner), not dsh-terminal-bash itself.
• The filesystem fence is independently excluded here too: manageDacls:false reproduces with
  zero ACL/label changes, and the bundled diagnose-windows-sandbox-acl returns
  NOT_THIS_CLASS — same result as @OrangeStone446.
• Repro scripts (bisect driver, PTY driver, ETW image-load tracer) are available on request.