Bug report: Windows desktop shell commands fail with 0xC0000142 under workspace-write

[ZQQQing]

Bug report: Windows desktop shell commands fail with 0xC0000142 under workspace-write

Upstream report for DeepSeek Harness (Windows desktop / Electron host).
Everything below was reproduced on the reporter's machine; the upstream
reviewer has confirmed the direction and supplied the two implementation notes
in §5 and §6.

---

1. Summary

Under the default workspace-write permission, every shell command on the
Windows desktop app exits immediately with 3221225794 (0xC0000142,
STATUS_DLL_INIT_FAILED). File tools (read / write / edit / glob /
grep) keep working — only the shell is affected.

Nothing in the command matters: cmd.exe, powershell.exe, python.exe all
fail identically, including cmd.exe /c echo hello. Installing PowerShell 7
does not help.

The practical consequence is severe: the only way to get a working shell is to
switch the session to danger-full-access, which gives up all file
isolation. This forces every Windows desktop user to choose between "no shell"
and "no sandbox".

---

2. Reproduction

1. Windows desktop app, default profile.
2. Session permission workspace-write (the default for a new session).
3. Run any shell command via the pwsh tool:

pwsh: echo hello
→ [exit code: 3221225794]      # 0xC0000142, no output

Also reproduces with cmd.exe /c echo hello, and with Python.

---

3. Root cause (two axes, one signature)

3.1 The signature is not self-diagnosing

0xC0000142 is shared by at least two distinct producers:

• restricting-list side — createRestrictedToken requires a keep-alive
  group (logon SID + EVERYONE) precisely because a token without it dies
  during DLL initialization with the identical code;
• carrier side — the Electron host is a GUI-subsystem process, so the
  restricted child can inherit a console but can never create one; creating
  one (CREATE_NO_WINDOW / CREATE_NEW_CONSOLE) under the restriction is the
  documented death path.

So 0xC0000142 alone cannot name the cause. Two discriminators are needed, and
both are cheap:

3.2 Discriminator 1 — the mode split (narrows it to the token side)

Mode	Result
read-only	exit 0 — child runs
workspace-write	0xC0000142 — child dies

read-only is alive and workspace-write is dead. The difference between the
two is the restricting list plus the token default DACL, so this narrows the
fault to the token side.

3.3 Discriminator 2 — the carrier (the second independent prerequisite)

Same runner, same arguments, same workspace, only the carrier process differs:

Carrier	workspace-write
node.exe	exit 0
DeepSeek Harness.exe (Electron)	0xC0000142

This is the axis that determines whether the console can be inherited at all,
and it is independent of 3.2. Both axes must hold for the shell to work.

3.4 The culprit

On Windows the desktop host spawns the sandbox runner with process.execPath,
which is DeepSeek Harness.exe — the Electron GUI binary. It is a
GUI-subsystem process with no console, so the WRITE_RESTRICTED child it
creates has no console to inherit and cannot create one. The backend's own
documented boundary ("children created with CREATE_NO_WINDOW / CREATE_NEW_CONSOLE
die with STATUS_DLL_INIT_FAILED under the restriction") is reached here
through the carrier, not through a creation flag — which is why removing
the flags does not help.

3.5 Producer confirmation (no rebuild needed)

The reporter's recorded capture distinguishes the two producers with a single
check, exactly as the reviewer suggested:

• runner-side failure → the runner prints windows-acl-run: on stderr
  before the child is created;
• reporter's capture → exit=0xC0000142, stdout empty, stderr empty, no
  windows-acl-run: line.

The line's absence alongside 0xC0000142 places the death inside the
restricted child, before main() — the runner itself never failed.

---

4. Impact

• Shell is completely unusable under the default permission on Windows desktop.
• Users are forced into danger-full-access, losing isolation silently.
• Easy to misdiagnose as a broken PowerShell/Python install.

---

5. Why this surfaces as a bare exit code — one missing rule

The reviewer's implementation notes, reproduced here for the record.

sandbox-local's windows-acl runner-failure rule is:

{ allowedExitCodes: [WINDOWS_ACL_RUNNER_FAILURE_EXIT],   // exit 127
  fatalSignatures: ['windows-acl-run: '] }

and sandbox's match loop continues on allowedExitCodes before it ever
looks at stderr. So:

• 0xC0000142 is not 127, and
• its stderr is empty, so no signature matches either,

which means it can never become a RunnerFailureMatch → no
SandboxUnavailableError → tool-pwsh then reports it as an ordinary non-zero
exit ("non-zero exits are reported, not errored").

This is one missing classification rule, not one missing error message. The
runner did not fail — the restricted child died before main() — and the rule
table has no entry for "the restricted child never started". A rule covering
that case would turn this from a silent bare exit code into a diagnosable
sandbox failure. That is the single highest-value change in this report, and
it is what would have made this bug findable without the carrier table.

---

6. Suggested fixes

6.1 Durable fix (upstream)

Carry the Windows sandbox runner with node.exe rather than
process.execPath. The reviewer confirmed the Electron-vs-node carrier
distinction is a real prerequisite, so this is a mitigation that addresses the
cause rather than working around a misdiagnosis.

6.2 Diagnostic fix (upstream, independent)

Add the classification rule from §5 so "the restricted child died before
main()" is reported as a sandbox failure instead of a bare exit code. This is
worth doing regardless of 6.1 — it is what makes the next occurrence of this
class cheap to diagnose.

6.3 Local mitigation (what the reporter shipped)

Until the above lands, the reporter is using the runnerCommand hook to carry
the genuine runner via node.exe; the write boundary is unchanged and
enforcement still reports full. The local mitigation is not a substitute
for 6.1/6.2, and should not be treated as making them optional.

---

7. Local verification of the mitigation

Verified in the reporter's own harness (not just by direct invocation):

Case	Expect	Result
workspace-write: PowerShell runs	allowed	pass
workspace-write: write outside the workspace	denied	pass
read-only: write inside the workspace	denied	pass
cmd / PowerShell exit-code fidelity	preserved (42)	pass
stdin passthrough	works	pass
large output (2000 lines)	intact	pass
cancellation leaves no orphan	no leak	pass

A separate observation, worth noting because it bounds the reproduction: from
inside the sandbox, spawning any executable outside the granted roots
returns EPERM. The sandbox is therefore unable to re-spawn the original
broken carrier from within a confined session — any reproduction of the failure
must run unconstrained, or go through the host's own tool.

---

8. Environment

• Windows 11 (build 26200), Chinese locale
• DeepSeek Harness desktop, dsh-sandbox-windows-acl 0.2.0-rc.2
• No PowerShell 7 installed; the tool falls back to Windows PowerShell 5.1
  (irrelevant to the fault — cmd.exe fails identically)

9. Reporter's note

For completeness: a third-party diagnostic plugin
(@argszero/cordis-plugin-sandbox-grant-advisor, 0.20.0) was pointed out as
already classifying this signature. It has not been installed — the
reviewer described it as a diagnosis aid only, and it does not replace the
upstream fixes in §6.

[argszero]

Your carrier table is the right instrument, and it matches a boundary this backend already documents: createRestrictedToken keeps a logon SID plus an EVERYONE keep-alive group precisely because children created without an inherited console die during DLL initialization with STATUS_DLL_INIT_FAILED. Electron is a GUI-subsystem host, so the restricted child can only inherit a console, never create one — hence node.exe ✓ / Electron ✗ / read-only ✓. Two things you cannot see from outside, both worth folding into the report.

1. Why it surfaces as a bare exit code instead of a sandbox failure. The runtime path is:

• packages/sandbox/sandbox-local/src/index.ts:241 — the windows-acl runner failure rule is { allowedExitCodes: [WINDOWS_ACL_RUNNER_FAILURE_EXIT], fatalSignatures: ['windows-acl-run: '] }, i.e. exit 127 plus the runner's own stderr prefix.
• packages/sandbox/sandbox/src/diagnostics.ts:69-83 — the match loop continues on allowedExitCodes before it ever looks at stderr (:73), so 0xC0000142 (3221225794) can never become a RunnerFailureMatch ⇒ no SandboxUnavailableError ⇒ it renders as an ordinary non-zero exit, and packages/shell/tool-pwsh/src/render.ts states the policy explicitly ("non-zero exits are reported, not errored").

So your second suggestion is structurally right and cheap to state: this is one missing rule, not one missing sentence. The runner did not fail — the restricted child died before main() — and the rule table has no entry for "the restricted child never started".

2. 0xC0000142 alone cannot name the cause — keep the mode split as the discriminator. The same source records the opposite direction: too few restricting entries (missing logon SID / EVERYONE) dies with the identical code, and with workspace-write the difference from read-only is the restricting list plus the token default DACL. So the honest reading of your matrix is: read-only alive / workspace-write dead narrows it to the token side, and the carrier axis (your table) is the second, independent prerequisite. Two axes, one signature — which is exactly why the "run the runner via node.exe" suggestion is a real mitigation and not a workaround for a misdiagnosis.

If it helps you confirm which producer you are in: a runner-side failure prints a windows-acl-run: line on stderr before the child is even created, so its absence alongside 0xC0000142 means the death is inside the restricted child, not in the runner. That single check separates "runner failed" from "child never initialized" without a rebuild.

For visibility, the native-init family of @argszero/cordis-plugin-sandbox-grant-advisor (0.20.0, npm) already classifies this exact signature and reports which producer candidates match — mode split, the runner-side windows-acl-run: line, and the console/host axis — as an in-session report, without claiming a cause. It is a diagnosis aid only: the durable fix is upstream (the carrier/console prerequisite plus a classification rule for the "child never initialized" case), and I would not want the plugin to make that fix look optional.