[Windows] Desktop app cannot spawn any child process: pwsh tool always returns 3221225794 / 0xC0000142, while dsh-win32 verify passes on the same machine

[zhuo-max]

Environment

• Windows x64, desktop app 2.0.18-next (core 0.2.0-rc.2, profile: desktop)
• PowerShell 7.6.7 (MSI) installed at C:\Program Files\PowerShell\7\pwsh.exe
• Install dir: C:\Users\Administrator\AppData\Local\Programs\DSH NEXT

Symptom

Every pwsh tool call fails with no output and exit code 3221225794 (0xC0000142, STATUS_DLL_INIT_FAILED). The process dies before running the command.

Reproduction

Any pwsh call reproduces it, including minimal commands:

• cmd /c echo SHELL_OK
• Get-Date
• & "<abs path>\node.exe" -e "console.log('ok')"
• & "<abs path>\python.exe" -c "print('ok')"

Same result in new sessions and in a subagent session. Work directory does not matter.

Already ruled out

• Missing Python: the failure happens before any interpreter is launched.
• Bad command: cmd /c echo and Get-Date fail identically.
• PATH resolution: absolute paths are used; a missing file is ENOENT/0x2, not 0xC0000142.
• Missing PowerShell 7: Get-Command pwsh originally returned nothing and Test-Path "C:\Program Files\PowerShell\7\pwsh.exe" returned False. After installing MSI 7.6.7 and restarting the app, the failure is unchanged.
• Store-alias pwsh being unusable in the sandbox: configured include:pwsh-sandbox.pwshPath to the MSI path. No change.
• Console-less host: launching the app from a console-attached PowerShell via Start-Process made no difference.
• Old desktop build: upgraded 2.0.17 -> 2.0.18-next. No change.
• Corrupted system PowerShell: the system Windows PowerShell 5.1 runs Get-Date fine manually.

Key contrast evidence (same machine)

npx dsh-win32 doctor reports everything OK (node 24.19.0, powershell path, no koffi, official persistent PowerShell and Windows ACL sandbox available) with no remediation items.

npx dsh-win32 verify passes all checks, including:

• ok powershell_launch: PowerShell launched through the confined official persistent-tool chain
• ok powershell_7: the same child is 64-bit PowerShell 7+, has PSHOME, and reports an existing executable path
• ok persistent_state: two model-facing pwsh calls retained cwd and environment in one PTY
• ok live acceptance passed

So on this machine the official terminal/subprocess/policy/local-sandbox chain can spawn and drive PowerShell successfully in an isolated acceptance run, while the desktop app instance cannot spawn any child process at all.

Impact

Terminal, command execution, archive extraction, and bundled Python are all unusable; features that depend on the pwsh tool fail (cannot unzip course archives, cannot parse .ppt/.pptx, cannot batch-process files).

Related upstream reports

• [Bug] Windows: sandboxed pwsh always dies with 0xC0000142 under console-less host (desktop launch path) #810 Windows: sandboxed pwsh always dies with 0xC0000142 under console-less host
• 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
• [Windows] Rscript/Python crash with 0xC0000142 / 0xC0000005 under read-only ACL sandbox #5013 [Windows] Rscript/Python crash with 0xC0000142 under read-only ACL sandbox

[argszero]

Thanks — this is one of the better-instrumented reports of this exit code, and the pair you drew (dsh-win32 verify passing while the desktop app cannot spawn anything) is the observation that resolves the case rather than contradicting it.

The verifier and the app are different carriers

sandbox-local/src/index.ts:575 launches the windows-acl runner as [process.execPath, builtEntry]. In a packaged desktop build process.execPath is the Electron executable, which is a GUI-subsystem program and owns no console. The confined child inherits the runner's console, so a runner that owns none leaves the child to ask for one of its own — and a restricted token may not create it: conhost.exe comes up from the restricted child, exits 0xC0000022 (STATUS_ACCESS_DENIED), and the child then dies 0xC0000142 before its entry point. That is why your symptom reads as "no child process at all" rather than "this command failed".

dsh-win32 verify runs from a shell you started in a console, so its isolated acceptance run sits on the working side of exactly that input. Nothing about your machine, PATH, the PowerShell build or the install layout has to differ for both readings to be true at once — which is also why the earlier doctor/7.6.7/Start-Process attempts changed nothing.

A discriminator that costs nothing to run

Look for a windows-acl-run: line in the failed command's stderr. sandbox-local/src/index.ts:233-242 declares:

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

with WINDOWS_ACL_RUNNER_FAILURE_EXIT = 127 (:218). A runner-side failure therefore announces itself before any confined child is created. Its absence alongside 0xC0000142 places the death inside the restricted child, not in the runner — it separates "the runner never ran" from "the child never initialized".

Why the model only ever sees a bare status

classifyRunnerFailure (sandbox/src/diagnostics.ts:73) drops every rule whose allowedExitCodes does not contain the exit code, and it does so before reading stderr; tool-pwsh/src/render.ts:80 appends [exit code: N] to a result it does not treat as an error. This code is therefore structurally not a sandbox failure as far as the pipeline is concerned — an ordinary non-zero exit that gets rendered, not classified. That is a missing class rather than a missing message, and it is why the model retries a command that cannot start.

A caution before you go changing tokens

Do not read 0xC0000142 as "the token is wrong" or "the mode is wrong". The token constructor's own docstring records the opposite direction with the same code — sandbox-windows-acl/src/token.ts:184-192:

read-only: [logon SID, EVERYONE]
workspace-write: [logon SID, EVERYONE, workspace SID, optional temp SID]
The logon SID + EVERYONE keep-alive group is shared by both modes: early DLL init dies with 0xC0000142 and CNG (\Device\CNG write trustee — pwsh crashes 0xE0434352) fails without them.

Too few restricting entries and too many die with one code, so the code alone reaches only as far as "native initialization failed". Two readings narrow it: whether the same command works under another confining mode (mode is step one of two), and whether the host owns a console (step two). Your verify-passes / app-fails pair is the second one.

Cheapest first moves

1. Run the same session from a host that owns a console — the Web UI started from a terminal, same machine, same workspace, same mode. If confined children work there, the input is the carrier's console, not the token, the ACL, or the install.
2. danger-full-access is worth one run as confirmation of the mechanism — not as a fix.
3. If the session has to stay in the packaged desktop app, this is an upstream shape problem rather than a configuration one; no setting in your profile reaches it.

An existing asset for the transcript side

The failure text you are staring at is already recognized by a plugin I publish: @argszero/cordis-plugin-sandbox-grant-advisor (0.23.0, npm and source both under that name). It matches [exit code: -1073741502] / (0xC0000142) on the public tools/post-execute seam — the one seam that has the failure, an agent identity and a same-step channel back to the model — and reports, as a measured fact rather than an assumption, whether this process is an Electron binary (process.versions.electron), so the model gets the mechanism in the same step instead of retrying. It repairs nothing: no ACL, no privilege, no mode, no environment variable. If it saves you a round trip here, that is the whole of what it does.

I have no upstream channel to file this on — issues and PRs are disabled on this repository — so this comment is the whole of it.