[Bug][Desktop][0.2.0-rc.1] Windows ACL sandbox cannot start any child under an Electron host (0xC0000142)

[SeleneXX]

Summary

On DSH Desktop (Windows), @deepseek-ai/dsh-sandbox-windows-acl cannot start any child process. The confined spawn dies with STATUS_DLL_INIT_FAILED (0xC0000142) before any user code runs.

The distinguishing variable is the executable hosting the ACL runner, not the token construction, not the ACLs, and not the target program:

Host executable for the ACL runner	Target	Result
real node.exe	pwsh.exe	✅ works
real node.exe	cmd.exe	✅ works
Electron (DeepSeek Harness.exe, ELECTRON_RUN_AS_NODE=1)	pwsh.exe	❌ 0xC0000142
Electron	cmd.exe	❌ 0xC0000142
Electron	cmd.exe — read-only mode, no ACL grants at all	❌ 0xC0000142
desktop's own independent node.exe	pwsh.exe / cmd.exe	✅ works

Web is unaffected because its host is a real node.exe; Desktop is affected because its host is the Electron executable.

This is a separate root cause from two adjacent reports, both of which I read carefully before filing (see Relation to existing reports).

Environment

• Windows 10.0.26200
• DSH Desktop 0.2.0-rc.1 (resources/runtime/primary-runtime/runtime.json), Electron 44.0.0
• @deepseek-ai/dsh / @deepseek-ai/dsh-sandbox-windows-acl 0.1.7-rc.1
• Desktop profile (~/.dsh/profiles/desktop), session file policy workspace-write
• PowerShell 7.6.6 (C:\Program Files\PowerShell\7\pwsh.exe)
• Bundled standalone Node: resources/runtime/primary-runtime/dependencies/node/bin/node.exe (v24.21.0)
• PATH Node: v24.15.0

Symptom

Any shell tool call in a confined session returns immediately with no output:

(no output)
[exit code: 3221225794]

3221225794 = 0xC0000142 = STATUS_DLL_INIT_FAILED. pwsh, cmd, and node all fail identically. File tools (read / write / glob / grep) are unaffected, since they do not go through the process sandbox.

Session log confirms the policy was confined and no error detail was surfaced:

{"type":"sandbox/mode","seq":1,"data":{"mode":"workspace-write"}}

{"type":"tool/result","data":{"message":{"role":"tool",
  "content":[{"type":"text","text":"(no output)\n[exit code: 3221225794]"}],
  "isError":false}}}

Failing code path

packages/sandbox/sandbox-local/src/index.ts — windowsAclRunnerInvocation():

const builtEntry = this.internals.windowsAclRunnerEntry
  ?? fileURLToPath(import.meta.resolve("@deepseek-ai/dsh-sandbox-windows-acl/runner"));
if (existsSync(builtEntry)) return [process.execPath, builtEntry];
// ...
return [process.execPath, "--import", `data:text/javascript,...`, sourceEntry];

process.execPath is the Electron binary in Desktop. The same process.execPath pattern appears in packages/subprocess/subprocess-local/src/runner-launch.ts.

Desktop's launcher shim makes this structural — apps/desktop/scripts/node-bin/node.cmd:

@echo off
set ELECTRON_RUN_AS_NODE=1
"%DSH_DESKTOP_NODE_EXECUTABLE%" --expose-internals %*

So every "node" the harness needs is the Electron executable in Node mode.

Process tree: the failure is in the SECOND runner

Live process monitoring (30 ms polling of Win32_Process) on Desktop shows two distinct spawn chains:

# Chain 1 — only the subprocess-local runner.  WORKS.
[10:30:07.307] pid=52860 DeepSeek Harness.exe   parent=56976(DeepSeek Harness.exe)
    cmd: "...\app.asar\dsh\node_modules\@deepseek-ai\dsh-subprocess-local\lib\runner.js"
         -- "...\pwsh.exe" -NoLogo -NoProfile -NonInteractive -Command "..."
[10:30:08.066] pid=62288 pwsh.exe               parent=52860(DeepSeek Harness.exe)   ← ran fine

# Chain 2 — subprocess-local runner → windows-acl runner → pwsh.  FAILS 0xC0000142
desktop host (56976, Electron)
  └─ dsh-subprocess-local runner          (Electron; creates children fine)
       └─ dsh-sandbox-windows-acl runner  (derives WRITE_RESTRICTED + Low token)
            └─ pwsh.exe                   ← 0xC0000142

The same monitoring captured the Desktop host successfully launching git.EXE and rg.exe through the first-layer runner. So the first runner works under an Electron host; only the second one fails — i.e. the breakage is specifically in deriving a WRITE_RESTRICTED + Low-integrity token from an Electron process token and spawning under it.

Reproduction (does not need the Desktop UI)

Invoke the ACL runner directly over the seam's argv contract, varying only the host executable. $writeSid / $tempSid must be derived with the package's own algorithm (sha256, 30-bit subauthorities; temp sid carries a trailing -1).

$ws      = 'C:\Users\<user>\WeeklyReport'            # any existing dir
$temp    = 'C:\Users\<user>\AppData\Local\Temp\dsh-x3'   # must be created first
$writeSid = <workspaceWriteSid($ws)>                 # S-1-4-x-y
$tempSid  = <tempWriteSid($temp)>                    # S-1-4-x-y-1
$runner  = '...\app.asar\dsh\node_modules\@deepseek-ai\dsh-sandbox-windows-acl\lib\runner.js'

# (A) host = real node   -> exit 71
& node.exe $runner --workspace $ws --temp $temp --mode workspace-write `
    --write-sid $writeSid --temp-write-sid $tempSid -- pwsh.exe -NoProfile -Command "exit 71"

# (B) host = Electron    -> 0xC0000142
$env:ELECTRON_RUN_AS_NODE = '1'
$env:DSH_DESKTOP_NODE_EXECUTABLE = '...\DeepSeek Harness.exe'
& '...\DeepSeek Harness.exe' $runner --workspace $ws --temp $temp --mode workspace-write `
    --write-sid $writeSid --temp-write-sid $tempSid -- pwsh.exe -NoProfile -Command "exit 71"

Between (A) and (B) nothing else changes: same workspace, same temp dir, same mode, same two SIDs, same target, same runner file (identical sha256 in both installed copies).

Control: the Electron executable spawns cmd /c ver correctly when it does not go through AclSandbox (spawnSync returns status 0 with normal output) — so the Electron process itself can create children; it is the combination with the restricted token that fails.

What was ruled out

Hypothesis	Evidence against
Broken/conflicting workspace or temp ACLs	The repo's bundled diagnosis script returns verdict NOT_THIS_CLASS, packageAllowSids empty, writeDac/writeOwner both available
Stale deny ACEs on C:\Windows\Temp (this host has 14 of them, injected by a different sandbox product's capability-SID registry, keyed per workspace path)	Those SIDs are machine-SID-shaped and only deny themselves; icacls shows the interactive user and Everyone still at full control on the temp tree
Missing Low integrity label on the private temp dir	Applying the Low label by hand changed nothing (confined pwsh still exited 41, i.e. succeeded)
Missing/extra Low label on the workspace	The workspace does carry Low Mandatory Level:(OI)(CI)(NW); but read-only mode (which performs no label or grant work) fails under an Electron host too
Version skew between Desktop and Web copies	Both are dsh-sandbox-windows-acl@0.1.7-rc.1; runner.js is 7807 bytes with identical sha256 B58ACCC8… in both
pwsh resolution	Only one pwsh.exe on PATH (C:\Program Files\PowerShell\7\pwsh.exe), no shim
AppContainer/package-SID hardening of the user profile	Electron's renderer/utility processes are not AppContainers (TokenIsAppContainer = false); and the unconfined Electron spawn control above succeeds

Relation to existing reports

I read both before filing; this looks like a third, distinct cause.

#8170 (Windows ACL sandbox: native children with piped stdio silently never run; 0xC0000142 hard-error dialog, web profile) attributes the 0xC0000142 part to the documented boundary:

Console isolation is unavailable — children created with CREATE_NO_WINDOW / CREATE_NEW_CONSOLE die during DLL initialization with STATUS_DLL_INIT_FAILED (0xC0000142)

My measurements refine that boundary: it is not CREATE_NO_WINDOW by itself. dsh-win32-process already spawns with creationFlags = 0x404 (CREATE_SUSPENDED | CREATE_NO_WINDOW), and with a real-node host that path succeeds for both pwsh.exe and cmd.exe. The same flags under an Electron host fail. So the flag is a necessary-but-insufficient ingredient; the host process token is the discriminator. #8170's reported case may well be the same mechanism if a non-node executable hosted the runner there — worth checking, since that author still has the exit-code watcher armed.

#8174 (Desktop leaks ELECTRON_RUN_AS_NODE into every child process) is the same underlying subsystem but a different failure. It correctly describes ELECTRON_RUN_AS_NODE being inherited as a selector. Here the Electron binary is not merely inherited configuration — it is the process image that hosts the ACL runner and whose token the restricted token is derived from, so the [process.execPath, builtEntry] line is the direct cause.

⚠️ One interaction to watch: if #8174's suggested fix tombstones ELECTRON_RUN_AS_NODE in the shared child environment, the Desktop ACL runner (an Electron binary) may stop being able to execute runner.js at all. Whatever fixes #8174 should land together with, or before, this one.

Suggested fix

Prefer a real node executable over process.execPath for the sandbox runner (and the subprocess-local Windows runner). Desktop already ships exactly that:

resources/runtime/primary-runtime/dependencies/node/bin/node.exe   (v24.21.0)

Verified: with that binary as host, the confined pwsh.exe / cmd.exe spawns above succeed (exit 81 / 82).

Implementation options, least invasive first:

1. In windowsAclRunnerInvocation(), use the bundled standalone node path when process.versions.electron !== undefined, instead of process.execPath.
2. Make apps/desktop/scripts/node-bin/node.cmd point at the standalone node, so DSH_DESKTOP_NODE_EXECUTABLE means "node interpreter" again.
3. Guard the process.execPath choice with an Electron-host check (process.versions.electron / ELECTRON_RUN_AS_NODE) and fall back to the standalone node.

Also worth fixing independently: surface the failure. Today the user/agent sees (no output) + a raw STATUS_DLL_INIT_FAILED code, with no windows-acl-run: <detail> line and no indication that the sandbox — not the command — failed. Every shell tool call in a Desktop confined session is affected, so the practical effect is that Windows Desktop users must escalate to full access for all shell work, which silently removes the sandbox on that platform.

Please do not "fix" this with --disable-sandbox / --disable-gpu-sandbox. Those disable Chromium's renderer sandbox, which is a different layer from the DSH file policy; they are not the root cause and weaken browser-side isolation.

Scope

• Windows + Desktop only (Electron host). Web hosts a real node.exe and is unaffected.
• All ctx.sandbox-mediated shell execution: pwsh, cmd, and anything wrapped.
• File tools unaffected.

---

Diagnostics from a single machine; the four-row host comparison is deterministic and reproducible. I have the monitoring script and raw captures available and can re-run against a specific build.

[argszero]

Thanks — this is the third report of 0xC0000142 STATUS_DLL_INIT_FAILED under a confining Windows mode (#7876 and #7877 are the other two), and it is the one that shows the packaged desktop host has two distinguishable shapes rather than the single one #7876 suggested.

Why nothing in the pipeline acts on it. The code is never treated as a runner failure. RUNNER_FAILURE_RULES['windows-acl'] admits exactly one exit code — [{ allowedExitCodes: [127], fatalSignatures: ['windows-acl-run: '] }] (packages/sandbox/sandbox-local/src/index.ts:233) — and classifyRunnerFailure skips every other code before it looks at stderr (packages/sandbox/sandbox/src/diagnostics.ts). So SandboxUnavailableError is never thrown, the shell tool reports the call the way it reports any finished command (packages/shell/tool-pwsh/src/render.ts: non-zero exits are reported, not errored), and the code survives only as ToolExecutionSuccess.value.exitCode — the tool's execution-local canonical value, deliberately omitted from durable events and not carried on failure results at all.

One correction to the report's causal note. 0x404 is not CREATE_NO_WINDOW. It is CREATE_SUSPENDED (0x4) | CREATE_UNICODE_ENVIRONMENT (0x400). CREATE_NO_WINDOW is 0x08000000, and it is not even a constant in packages/subprocess/win32-process/src/abi.ts. What the repository does have is a comment at packages/subprocess/win32-process/src/process.ts:454 recording that a child started with CREATE_NO_WINDOW can fail restricted-token DLL initialization — worth keeping distinct from this report, because it is a caution about a flag this codebase explicitly avoids, not the flag in your stack.

The mechanism your report measures. The restricted token is derived from the current process's token (packages/sandbox/sandbox-windows-acl/src/token.ts:23, openCurrentProcessToken). Under the packaged desktop, that process is Electron — so the token's image is the Electron image, and the runner is started from it. That is consistent with your matrix: real node.exe → pwsh.exe and cmd.exe both work, and the same commands die under the Electron host. Your report is also what splits the desktop host into two measured shapes: #7876 measured the runner not starting at all (process.execPath is the Electron executable, which launches as an application unless the child carries ELECTRON_RUN_AS_NODE=1), while your launcher sets exactly that variable — the runner runs, and the child still dies because of the token above. From inside a session the two are indistinguishable; the check that separates them lives outside it (is ELECTRON_RUN_AS_NODE set for that host, and does the ACL runner appear among its processes while the command runs?).

Plugin-form stopgap. @argszero/cordis-plugin-sandbox-grant-advisor@0.7.0 — https://www.npmjs.com/package/@argszero/cordis-plugin-sandbox-grant-advisor (repo: https://github.com/argszero/cordis-plugin-sandbox-grant-advisor). I am not claiming you ran it; it is released against this class. It observes the public tools/post-execute waterfall, classifies the loader status structurally from the shell projection's own exitCode (never from rendered text, so a command that merely prints [exit code: …] is not claimed), resolves the sandbox mode through the policy capability guard, and attaches one durable user-role advisory per agent per family. For this family, 0.7.0 names both measured desktop shapes instead of asserting one — the sentence "so the runner never runs" that 0.6.0 shipped is gone, and three injection arms keep it gone — states the check that separates them, carries the one conversion a model can make itself (rewrite an MSYS2 job as cmd or PowerShell), and is explicit about the producers it does not know (a program that cannot load one of its own DLLs, and the hidden-console child). It never edits an ACL, never sets another process's environment, never changes a preset or a mode, and never offers a widened mode as a fix.

Thanks for the matrix — it is what made the second shape visible.

[argszero]

Follow-up on the same class, and the piece of your report I had not acted on: @argszero/cordis-plugin-sandbox-grant-advisor@0.7.1 now leads the Electron branch with your fix rather than a widened mode.

0.7.0 named the two measured shapes of the desktop host (your report's contribution to the family) but still sent an Electron reader to danger-full-access first. Your "Suggested fix" section already said why that is the wrong order, and you gave the reason:

the practical effect is that Windows Desktop users must escalate to full access for all shell work, which silently removes the sandbox on that platform

The advisory now says: host the runner on a real node.exe — the desktop's own resources/runtime/primary-runtime/dependencies/node/bin/node.exe, where your matrix shows the same confined pwsh.exe / cmd.exe spawns succeeding (exit 81 / 82) with workspace, temp, mode, SIDs, target and runner sha256 all held constant — with node apps/cli/lib/bin.js web as the second spelling. danger-full-access is described as a way to confirm the diagnosis rather than a fix.

Two more things from your report are in the text now, because they are the parts a session reader would get wrong without them:

• The flag vocabulary. Your "Relation to existing reports" section refines #8170 correctly, and I had been repeating the backend's own recording ("children created with CREATE_NO_WINDOW … die during DLL initialization") without that refinement. The advisory's honest-boundary clause now states what the source actually does: the restricted-token path spawns with CREATE_SUSPENDED alone (packages/subprocess/win32-process/src/process.ts:537-545) and the ordinary current-token path with CREATE_SUSPENDED | CREATE_UNICODE_ENVIRONMENT (:567 — the 0x404 you spotted), and CREATE_NO_WINDOW is not a constant anywhere in that source. So those flags are a necessary-but-insufficient ingredient, and the host process image is what turns them fatal.
• The #8174 interaction, warned in the direction you flagged. The advisory tells the reader not to unset ELECTRON_RUN_AS_NODE as a workaround: the desktop's runner is that Electron binary, so without the variable it cannot execute runner.js at all. That is the same coupling you describe — a fix that tombstones the variable in the shared child environment has to land together with this one.

It is still a stopgap. It names the situation to a session that is stuck; it does not change windowsAclRunnerInvocation() or the desktop's node.cmd, so suggestions 1–3 in your report remain the real fixes.

Thanks — the host matrix in your report is what made the second shape visible, and the remedy ordering came from your "Suggested fix" section, not from us.

[Avalianfeng]

Why a comment and not a new thread: 0xC0000142 matches 64 discussions and sandbox 737; #8193 is the best-analyzed one and already names the likely root cause. A 65th thread would only fragment it. This reply adds (a) confirmation on the newest release, (b) a correction to row 3 of the matrix, and (c) a set of controls so you do not have to re-run them.

---

Confirming this on 0.2.0-rc.2, plus one result that differs from row 3 of your table — this time measured in a real Desktop session, not just a standalone harness.

Environment: DSH Desktop 0.2.0-rc.2, Windows 11 25H2 build 26200, Electron 44.0.0 / Node 24.18.1 (bundled node v24.21.0), session file policy read-only.

1. The root cause you identified is still present in 0.2.0-rc.2

dsh-sandbox-local/lib/index.js still resolves the ACL runner host from process.execPath:

const builtEntry = this.internals.windowsAclRunnerEntry
  ?? fileURLToPath(import.meta.resolve("@deepseek-ai/dsh-sandbox-windows-acl/runner"));
if (existsSync(builtEntry)) return [process.execPath, builtEntry];

So your suggested fix has not landed in the newest release. Your supporting claim also holds — 0.2.0-rc.2 ships exactly the interpreter you propose using:

resources/runtime/primary-runtime/dependencies/node/bin/node.exe   (v24.21.0)

2. Row 3 of your matrix does not reproduce: read-only works under an Electron host

Real Desktop session (not a harness), file policy switched to read-only, same machine and build as your report:

Observation	Result
Foreground pwsh tool call	✅ exit 0, normal output
Background pwsh job	✅ exit 0
Token integrity of the confined shell	Low Mandatory Level (S-1-16-4096) — the confinement is real, not an unconfined run
Writing a file into the workspace	❌ DENIED, file not created
Reading files	✅
Child process (cmd /c echo)	✅
python.exe / node.exe from the bundled runtime	✅ 3.12.14 / v24.21.0

workspace-write on the same host still dies with 0xC0000142 for every target, foreground and background.

This agrees with #8062, which reports for an Electron parent: "workspace-write 必死 3221225794，read-only 正常". So two independent machines measure read-only working under an Electron host, and only row 3 of your table reports it failing.

Why I think this matters for the fix rather than just for the table. If the Electron host alone were fatal, read-only would have to die too — it derives its restricted token from the same Electron process token through the same openCurrentProcessToken path. It does not. That points at the combination rather than the host:

(Electron-hosted runner) × (write-restricted token carrying capability SIDs) is fatal; neither factor alone is.

Concretely, that is consistent with the two things workspace-write adds on top of read-only:

• the workspace/temp capability SIDs join the restricting list, and createRestrictedToken() returns at types-Cl_DXjhk.js:897 — they never enter the token's normal SID list (:852-853, :884-893, Flags 13 = … | WRITE_RESTRICTED);
• the token default DACL gets a merged FILE_ALL_ACCESS ACE naming the write SID, where read-only names Everyone (:786-796, :801-823).

I am not claiming that fully explains the mechanism — only that "the host image is the discriminator" cannot be the whole story while read-only survives under the same host. If you want a single discriminating run: keep the Electron host, use workspace-write, and drop the write SIDs from the restricting list (or name Everyone in the default DACL instead of the write SID).

Note also that the real argv differs by two variables at once, which is worth holding constant in any comparison: read-only is invoked without --write-sid/--temp-write-sid (standalone, manageDacls: true, --temp tmpdir()), while workspace-write carries the pair (seam, manageDacls: false). I tested standalone workspace-write as well — it fails identically, so the seam split is not the variable.

3. Controls that may save you a re-run (all on rc.2, Electron host)

• Target executable is irrelevant — Store/MSIX pwsh, Windows PowerShell 5.1, cmd.exe and node.exe all die the same way.
• Path and ambient ACL state are irrelevant — clean directories outside %TEMP%, a brand-new workspace (bypassing the standing-ACE reuse cache), and a %TEMP% tree already littered with inherited ACEs from another sandbox product all gave identical results.
• A broken TMP/TEMP is not sufficient — read-only with TMP/TEMP pointed at a non-existent path still spawned successfully, so the TMP/TEMP rewrite in runner.js:153-156 is not what kills the load.
• Do not tune the CREATE_NO_WINDOW boundary — as you noted, the restricted-token path spawns with CREATE_SUSPENDED alone; I independently read the installed dsh-win32-process and confirm it passes creationFlags = 4 for the inherited-stdio path and 0 for the piped path, both modes alike.

4. Side observation: confined sessions land in ConstrainedLanguage

In the confined session, $ExecutionContext.SessionState.LanguageMode is ConstrainedLanguage — .GetType(), .NET static calls and similar are refused ("此语言模式仅支持核心类型"). This matches #8219. It is not the 0xC0000142 bug, but it does mean shell snippets written for an unconfined session can fail in confined ones, and it may deserve its own note.

5. Agreed on the diagnosis gap

Your "surface the failure" point is what makes this expensive in practice. Confirming the shape from rc.2: dsh-pwsh-sandbox/lib/index.js:68-81 classifies a runner failure only from non-zero exit + a matching stderr line, and the windows-acl rules admit only exit 127 with the windows-acl-run: signature. Here the runner succeeds and the child dies at load with empty stderr, so nothing matches and the raw code is all the user sees. Treating 0xC0000142 / 0xE0434352 as confinement-induced child death even with empty stderr would turn this class from silent into self-explaining.

6. Practical note for the other reports in this family

Until the host is changed, read-only is a working confined mode on Windows Desktop — the shell runs at Low integrity with writes denied, and the bundled Python/Node toolchains still work. That is a better default answer for the ~64 threads in this family than "escalate to danger-full-access", which silently removes the sandbox. The obvious tradeoff is that it cannot write to the workspace, so it is only a fit for read-and-inspect work.

Thanks for the host matrix — it is what made the second shape visible, and it is why we did not file a 65th report.