Windows sandbox: every subprocess dies with 0xC0000142 (STATUS_DLL_INIT_FAILED) in the desktop app

[yxlyzmh]

Windows sandbox: every subprocess dies with 0xC0000142 (STATUS_DLL_INIT_FAILED) in the desktop app
Version: DSH desktop 0.2.1-rc.2 (Electron 44.7.0, bundled node 24.21.0) OS: Windows 10 Pro 10.0.19045 (win32 x64, zh-CN) Severity: sandbox mode (workspace-write) is unusable — every pwsh tool call returns no output and exit code 3221225794 (0xC0000142). danger-full-access works fine.

Symptom
With the session file policy set to workspace-write, any shell call:

代码块

Write-Output "probe-ok"
→ (no output) [exit code: 3221225794]
Zero bytes of stdout and stderr — the command never starts executing.
Happens regardless of command content, working directory, or whether PowerShell 7 is installed.
Switching the same session to danger-full-access makes the identical command succeed immediately:
代码块

Write-Output "probe-ok"
→ probe-ok
C:\Program Files\PowerShell\7\pwsh.exe
7.6.7
So it is not a missing/misconfigured shell, not PATH, not an endpoint-security product (plain powershell.exe -Command "echo hi" from a normal console works; Windows Application log has no Id 1000 crash records for pwsh/node, so the child never reaches the WER stage).

Root cause (from the shipped code)
@deepseek-ai/dsh-pwsh-sandbox/lib/index.js — danger-full-access bypasses ctx.sandbox.confine(); every other mode wraps the argv through the Windows ACL restricted-token runner chain.

@deepseek-ai/dsh-sandbox-windows-acl/lib/types-*.js documents the boundary:

console isolation is unavailable — children share the host console (CREATE_NO_WINDOW / CREATE_NEW_CONSOLE children die with STATUS_DLL_INIT_FAILED under the restriction)

@deepseek-ai/dsh-subprocess-local/lib/index.js — launchWindowsJob() spawns the runner with windowsHide: true unconditionally (Node maps this to CREATE_NO_WINDOW).

The desktop app is a GUI process, so it has no host console to share. The combination restricted token + CREATE_NO_WINDOW + no inherited console kills the runner during DLL/conhost initialization, before the target program is ever resolved — which is why installing PowerShell 7 changes nothing.

Reproduction
Fresh Windows 10 x64 machine (desktop app installed via NSIS).
Start DeepSeek Harness from Explorer (i.e. a GUI launch with no attached console).
New session, file policy workspace-write.
Ask the agent to run any shell command, e.g. echo hi.
Observe zero output + exit code 3221225794.
Switch the session to danger-full-access, repeat → succeeds.
Notes / hypothesis for the fix
The failure is plausibly absent when the harness is launched from a terminal, because the child can inherit the parent's console handles instead of allocating a new conhost under the restricted token. Confirming that A/B would pin the fix:

avoid windowsHide: true when a sandbox token is applied (spawn with the inherited console, per the documented boundary), or
route sandboxed launches through a runner that already owns a console, or
document that Windows sandbox mode requires launching the harness with a console.
Impact
On this configuration the Windows ACL sandbox provides zero usable shell capability, so users are forced to choose danger-full-access — i.e. the safe default is unavailable exactly where it is supposed to protect the user.

[PerryLink]

This is documented. The package also ships a repair.

The sandbox README lists two ways a confined child dies with 0xC0000142 (packages/sandbox/sandbox-windows-acl/README.md): the keep-alive group (logon SID + Everyone) missing from the token (:102), and children created with CREATE_NO_WINDOW / CREATE_NEW_CONSOLE (:127 — console isolation is unavailable). The process layer deliberately avoids those creation flags for this reason (packages/subprocess/win32-process/src/process.ts:454).

There is a third case that fits "every pwsh call, regardless of content or cwd": a path the child must read carries another sandbox's AppContainer package SID in its DACL, which a low-integrity token cannot open — the README lists it among the structural limits. If a previous sandbox tool (or an older DSH) stamped the workspace or the install tree, every child fails at DLL init.

For that case the package bundles a diagnostic that repairs in the same run (README.md:78-80), invoked unconfined:

& '<skill-dir>\scripts\diagnose-windows-sandbox-acl.ps1' -Path '<failing-path>' -AllowRoot '<authorized-dir>' -Out '<recovery-dir>'

It backs up and verifies every DACL change, removes foreign package allow ACEs at their source, refuses reparse points and managed application trees, and prints rollback commands.

If it reports nothing to repair, the remaining two causes are on the token/creation side and the useful next datapoint is whether a child started with an explicit console behaves differently — that is the distinction README:127 describes.

You are on rc.2 (687f282e); the asset exists in that tag too, so you do not need rc.3. I read the trees and the source, I did not run the script.

[yxlyzmh]

这是来自QQ邮箱的假期自动回复邮件。   您好，我最近正在休假中，无法亲自回复您的邮件。我将在假期结束后，尽快给您回复。