[Windows][sandbox] workspace-write: every shell command dies at startup with 0xC0000142

[Ola-la21]

Question: is this a known regression on Windows, and is there a supported workaround short of escalating every single command to danger-full-access? If anyone else sees it, please add your Windows build — that would help pin it down.

What happens
With the file policy set to workspace-write, every shell command fails before producing any output. Exit code is 3221225794 = 0xC0000142 (STATUS_DLL_INIT_FAILED). The identical command with danger-full-access succeeds, so the interpreter is fine and the failure is in the confined spawn path.

Environment
OS: Windows 11 Pro 23H2, 10.0.22631, x64
Shell: PowerShell 7.6.6 (Core), C:\Program Files\PowerShell\7\pwsh.exe
DSH desktop: nightly channel, update feed
https://download.deepseek.com/dsh-desk/feeds/win-x64/
Workspace: D:\Deepseek Harness
File policy: workspace-write
Steps to reproduce
Open a session whose file policy is workspace-write.

Run any shell command, including a trivial one:

powershell

echo hi
Result: no stdout, no stderr, exit code 3221225794.

Control experiment
Same session, same command, one-shot escalation to danger-full-access:

powershell

$PSVersionTable.PSVersion.ToString(); "ok"
Prints 7.6.6 and ok, exit code 0. So pwsh, its DLLs and the environment are healthy; only the confined path fails.

Frequency and scope
100% reproducible. The first command of a session fails, and so does every subsequent one. Not transient, not command-specific, and nothing needs to be written to the workspace for it to happen.

Ruled out
PowerShell installation — the same binary works unconfined (7.6.6, standard MSI layout under C:\Program Files\PowerShell\7).
Global DLL injection — HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows has an empty AppInit_DLLs and LoadAppInit_DLLs = 0.
Crash in a specific module — no Application Error events (Event ID 1000) for pwsh.exe; the process exits rather than crashing with a faulting-module report.
Workspace contents — an empty command fails, so no project file is involved.
Hypothesis
0xC0000142 at startup is what the loader reports when a DLL's DllMain returns failure, which is almost always about the environment the process is created in, not about the executable. The confined spawn appears to hand the child a stdio/console state it cannot initialize — and the sandbox is documented to deny named pipes, which piped stdio needs. A child whose CRT cannot set up its console state fails inside DllMain, which surfaces as exactly this code, with no output and no Event Log entry.

Related items in the same area:

anywhere-labs/dsh-desktop PR #1575 "fix(desktop): give confined shells a console in Next and Beta"
discussions #1847 ("Workspace-write sandbox: external processes fail with 0xC0000142 on Windows 10 (build 19041)«) and #10046 (»DSH Windows sandbox 0xC0000142 — community fix recipe")
Impact
On Windows workspace-write is the default policy, and the shell is the only way to run git, builds, tests and Python. With this bug the whole toolchain is unusable: every command needs a manual escalation to danger-full-access, which defeats the purpose of the sandbox.

Suggested directions
Give the confined child a real console (CREATE_NEW_CONSOLE, or properly inherited console handles) instead of a detached/piped setup.
If valid std handles cannot be inherited under confinement, do not spawn with pipes in the first place — fall back to inherit/ignore stdio.
Fail loudly: when the confined spawn cannot initialize, put the reason into the tool result instead of surfacing a bare exit 0xC0000142, so users can tell a sandbox problem apart from their own command failing.
Happy to test a nightly build with a fix and report back.

[argszero]

This is a known failure, and the code in your title is not your command's exit status.

0xC0000142 is STATUS_DLL_INIT_FAILED: the loader terminated the child while it was initializing its native images, before the program's entry point. A command that ran and then failed exits with its own status and prints its own output; this one produced neither — which is why the failure is identical whatever command you were running.

It is documented, and not new in 0.2.2-rc.1

packages/sandbox/sandbox-windows-acl/README.md records it as a limitation of the backend rather than a crash:

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.

0.2.2-rc.1 did move one leg of this area — the LUA_TOKEN removal (bdd75ca1, present in the dsh-v0.2.2-rc.1 tag) — but the console limitation predates that release, so this is not a regression 0.2.2-rc.1 introduced.

The mechanism has been measured, in three producers

@argszero/cordis-plugin-sandbox-grant-advisor@0.27.0 (npm) recognizes this exact failure as native-init and collects thirteen reports of the one code. The two measurements worth handing you:

• The runner's console, not its token. #8208 captured three lines: conhost.exe is created by the restricted child, exits 0xC0000022 STATUS_ACCESS_DENIED, and the child then dies with 0xC0000142. The same report compared whoami /groups and /priv from children of a working and a failing host: identical.
• Console topology varied alone. #9238 held machine, workspace, temp directory, mode, argv and restricted token constant and changed only how the runner was created: DETACHED_PROCESS (no console at all) died with 0xC0000142 and zero output, while CREATE_NO_WINDOW on the runner, CREATE_NEW_CONSOLE, an inherited console, and a hidden-console wscript → cmd carrier all reached the program with stdout intact. CREATE_NO_WINDOW on the child is the fatal direction.

So the question that decides your case is not your Windows build but whether the process that creates the confined child owns a console.

The workspace-write half of your report

There is a second, independent leg that your mode selects. The restricted token's default DACL receives one restricting ACE, and which SID it names is mode-dependent (packages/sandbox/sandbox-windows-acl/src/token.ts):

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

Under workspace-write that write SID is the temp write SID when the session has a private temp root, otherwise the workspace write SID — both path-derived capability SIDs (S-1-4-x-y, deterministic from the canonical workspace). Under read-only it is Everyone. Issue #1 of the advisory holds the arm that changes only that ACE — it is not deleted, only the SID it names is changed — and reports 0xC0000142 for a capability SID against 0x00000000 for Everyone, with the restricting list held fixed.

The cheap test that separates the two legs is one command in the same workspace, in read-only:

• it spawns → your build is failing on the default-DACL leg that workspace-write selects;
• it dies the same way → it is the console leg, and the mode is irrelevant.

read-only is not a workaround for writing; it is a discriminator. If it does turn out to be the console leg, #8313 measured the useful one: the same version in the same mode, dying as the packaged desktop app and working as the Web UI launched from a terminal, because a GUI-subsystem binary never owns a console.

Your "fail loudly" suggestion

You are right about the symptom, and the reason it cannot be expressed where you would expect is a deliberate invariant. RunnerFailureRule (packages/sandbox/sandbox/src/index.ts) carries fatalSignatures — "non-empty substrings identifying a fatal runner diagnostic on one stderr line" — and allowedExitCodes, which is only a gate: "Exit status alone never proves runner failure." A rule that fires on the exit code with no stderr line is not representable, and the exclusion is the point: the same missing evidence would let a confinement denial be reported as a runner failure.

The shape that would work runs the other way, and it is expressible with today's types: the Windows runner already holds the child's exit status, so it can emit one stderr line when that status is STATUS_DLL_INIT_FAILED, and sandbox-local can register a rule whose allowedExitCodes gates it. That needs the runner and sandbox-local changed together — a core change, not something a plugin can install — so this is a design suggestion for the maintainers, not a promise on their behalf.

What exists today is the advisory: it repairs nothing, but it recognizes this code and tells the model that the child never reached its entry point and that the retry is wasted. For one producer there is also a conversion the model can make itself: an MSYS2/Git-Bash command re-expressed as PowerShell or cmd runs in the identical mode (#7877).

What I cannot tell you

There is no Windows host here, so I cannot reproduce this, and 23H2 is not among the builds those measurements cover (19044, 19045 and the 26xxx reports). Your report is exactly the build datum your last line asks for. If you can add the read-only arm and whether the failing host is the desktop app or a terminal, that would place your case in one of the three producers rather than in the open build dimension.

[Ola-la21]

Read-only arm: run, and it passes.

Same workspace (D:\Deepseek Harness), same host, same shell, same DSH build.
Only the mode changed:

• read-only — echo hi, $PSVersionTable.PSVersion, (Get-Location).Path,
  git --version all run and print normally.
• workspace-write — the identical commands die before the entry point with
  3221225794 (0xC0000142), zero output, every time.

So this is the default-DACL leg that workspace-write selects, not the console
leg.

Details for the console question: the host is the packaged desktop app (GUI
subsystem, no console), and stdio is piped — [Console]::IsOutputRedirected is
True inside the working read-only child. No console exists in either arm, yet
the child starts in one and dies in the other, which matches your note that
pipe-based redirection is unaffected.

Build datum you asked for: Windows 11 Pro 23H2, build 22631, x64, PowerShell
7.6.6, DSH desktop nightly channel.

One variable worth testing for the SID arm: this workspace is on D:\ and its
canonical path contains a space (D:/Deepseek Harness), so the capability SID
is derived from a non-default-drive, space-containing path. If the write SID is
what fails in the restricting ACE, a plain C:\work\repo-style workspace is the
control.

Minor and probably separate: under read-only every call also emits two
InvalidOperation lines on stderr ("only core types are supported in this
language mode"), even for a bare echo hi. No effect on the result.

Thanks for the pointers — #9238 and the RunnerFailureRule explanation stopped
the guessing at our end.

[Ola-la21]

Update after further testing: this is not an environment/PATH problem.

I fully restarted the machine and the DSH app. git --version now resolves
correctly in a fresh shell process (2.56.0.windows.4), so the child
environment is up to date — yet the very first command under
workspace-write still dies with exit code 3221225794 (0xC0000142), with no
output at all.

Excluded so far: stale PATH/environment in the app process, the PowerShell
installation itself, global DLL injection (AppInit_DLLs is empty), and any
workspace content problem — a bare echo hi fails identically.

So the failure survives both a full reboot and a refreshed environment, which
supports the "the confined spawn cannot initialize the child" hypothesis.
Still reproducible on Windows 11 22631 with PowerShell 7.6.6.

Happy to run diagnostics if you tell me what to collect.

[argszero]

Here is exactly what to collect. Five steps; step 2 decides which of the others matter.

1 — the same command under read-only

Same workspace, same trivial command (echo hi), mode read-only. Two routes exist in the build you run (dsh-v0.2.2-rc.1): the permission preset named read-only (packages/bundle/base/cordis.patch.yml, preset read-only → sandbox: read-only), or DSH_PERMISSION_MODE=read-only in the environment that starts the app (same file: mode: !!js process.env.DSH_PERMISSION_MODE ?? 'workspace-write'). Both are read from that tag's tree here; neither has been executed on Windows by me.

• read-only runs while workspace-write dies → the default-DACL leg: workspace-write merges a capability SID into the child token's default DACL, read-only merges Everyone.
• both die identically → the failure is mode-independent, and the console leg is the remaining producer. #8208 measured exactly this on the desktop host: read-only and workspace-write both die with no output, danger-full-access fine.

2 — the same pair under a console-hosted Web UI

Start the Web UI from a PowerShell window (dsh web, or the npx form) and repeat step 1 in both modes. #8313 measured this contrast on one machine at one version: the desktop app died in workspace-write while the npx Web UI ran the same pwsh calls normally — and confirmed the sandbox was active by reading the child's private TEMP. The difference it landed on was the host binary: DeepSeek Harness.exe (GUI subsystem, run with ELECTRON_RUN_AS_NODE=1) against a real node.exe.

• works under the console-hosted Web UI, dies in the desktop app → the console leg, on your machine.
• dies in both → console is not the whole story for your build, and step 3 becomes the point.

The direction matters: a GUI-subsystem binary does not acquire a console by being started from one, so "start the desktop app from a terminal window" is not the experiment. The host binary is.

3 — the child's default DACL, from inside the confinement

Reachable only where children actually spawn — which on the desktop host they do not, so this runs under the Web UI host of step 2. The method is already recorded and I would rather you reuse it than have me re-derive it: argszero/cordis-plugin-sandbox-grant-advisor issue #1, Arm B — GetTokenInformation(TokenDefaultDacl) run from inside the confinement, in read-only. That issue also offers the script that produces it (dump-dacl.mjs) on request; ask there.

Needed: four entries, each with its mask and SID, plus one answer on top — whether the merged grant names Everyone (S-1-1-0) or a capability SID (S-1-4-…). Under read-only the shipped source merges Everyone (packages/sandbox/sandbox-windows-acl/src/token.ts, read from the tree, not executed), so a capability SID there is a fact about your build's merge rather than about the command.

4 — GetConsoleWindow() of the mediator

As seen by the process that creates the confined child. The recorded route for that measurement is in the same issue #1 (the packaged GUI host launched with --expose-internals, measured GetConsoleWindow() = null).

5 — a non-PowerShell child

Same tool path, same mode, cmd.exe /c "echo hi". The child program itself splits this family: #7877 measured, in one workspace under --mode read-only, cmd.exe and pwsh both at exit 0 while MSYS2 bash.exe died creating its signal pipe (Win32 error 5, exit -1073741502). If cmd succeeds where pwsh dies on your machine, that is a third producer.

What to paste back

#	field
1	full Windows build (22631.____)
2	pwsh --version
3	step 1: read-only exit code, and whether any output appeared
4	step 2: desktop vs console-hosted Web UI, per mode
5	step 3: four entries — mask + SID each — and which SID the merged grant names
6	step 4: GetConsoleWindow() of the mediator
7	step 5: cmd.exe /c "echo hi" exit code

What I cannot supply

There is no Windows host here, so none of this is something I can run for you, and 22631 is outside every build it has been measured on (19044, 19045, 26200). Your machine is the only one that can produce these numbers. Send them and I will read them against what we already hold and name the producer your case belongs to — rather than ask you to collect it again.