[Bug][Windows] workspace-write sandbox: every spawned console app dies with 0xC0000142 and raises a modal Windows error dialog on each tool call

[Night-fly986]

Version @deepseek-ai/dsh 0.1.5-rc.2 · @deepseek-ai/dsh-sandbox-windows-acl 0.1.5-rc.2 OS Windows 11 Pro 25H2, build 26200.9457 · Node v24.19.0 · Executor shell Windows PowerShell 5.1.26100.9444 (no PS7 on this host) Mode workspace-write (default, sandbox confirmed active) · launched with npx dsh from an interactive PowerShell with a console · zh-CN locale

Symptom

Console children started inside a Pwsh tool call raise a modal Windows "Application Error" dialog and die with STATUS_DLL_INIT_FAILED (0xC0000142) — but only on some spawn paths. Because agent activity constantly reaches cmd.exe-dependent tooling (.cmd/.bat shims = the npm.cmd/npx.cmd/pnpm.cmd path), the user gets a popup on essentially every conversation turn. GUI processes are unaffected.

The decisive matrix (all inside ONE sandboxed Pwsh call)

Spawn method | Result -- | -- Start-Process cmd.exe (PS 5.1 default = ShellExecute) | -1073741502 + popup ❌ .NET ProcessStartInfo, UseShellExecute=$true (WindowStyle Normal or Hidden) | -1073741502 + popup ❌ .NET ProcessStartInfo, UseShellExecute=$false, CreateNoWindow=$true | -1073741502 + popup ❌ Start-Process -NoNewWindow | throws Access is denied ❌ UseShellExecute=$false + CreateNoWindow=$false + WindowStyle=Normal | cmd /c "echo OK" prints OK, exit=0 ✅ … same path | where.exe node → prints path, exit=0 ✅ … same path | node.exe -e "console.log(...)" → prints output, exit=0 ✅ … same path | python.exe -c "print(1)" → prints 1, exit=0 ✅ … same path | _probe_shim.cmd (exit /b 5) → prints SHIM-RAN, exit=5 ✅ … same path via cmd /c | _probe_shim.cmd → runs, exit=0 ✅ CREATE_NO_WINDOW (either direct or via cmd /c) | _probe_shim.cmd → -1073741502 + popup ❌ (never runs) GUI (notepad.exe) | exit=0 ✅

A .cmd child that writes a probe file succeeds on the direct path and never executes on the CREATE_NO_WINDOW path — a real execution difference, not a reporting artifact. -WindowStyle Hidden still allocates a console, so window visibility is not the factor.

Interpretation

The restricted token is not the blocker: the same token runs cmd.exe/node.exe/.cmd fine when the child gets a console. The failing paths are exactly those where the caller does not create a console (CREATE_NO_WINDOW, and the ShellExecute route through Explorer), leaving cmd.exe to AllocConsole() itself and fail. Note this contradicts a literal reading of the documented boundary ("CREATE_NO_WINDOW/CREATE_NEW_CONSOLE children die during DLL initialization"): in my tests CREATE_NEW_CONSOLE works and CREATE_NO_WINDOW alone is sufficient to kill.

The host console is not the trigger — this host is launched from a console-attached PowerShell, and a sandboxed CreateProcess that creates a console succeeds, so #810's "console-less host" does not describe this machine.

Sandbox is demonstrably active

复制

Set-Content C:\Users\28139\_dsh_sandbox_probe.txt      → Access to the path ... is denied.
Set-Content D:\Deepseek Harness\_dsh_sandbox_probe.txt → success
TMP = C:\Users\28139\AppData\Local\Temp\dsh-wT3NhX     (private per-session temp)

Outside the sandbox (user's own terminal) the identical command returns 0.

Windows System log, provider Application Popup (ID 26), one entry per failure: Application popup: cmd.exe - Application Error : 应用程序无法正常启动(0xc0000142)。请单击“确定”关闭应用程序。

Popup census by day: 0 cmd.exe/node.exe popups from 08-25 to 09-07 (before DSH was ever launched; the ~19 entries there are SakuraCat.exe/audiodg.exe/steamwebhelper.exe), then 188 on the first DSH session day (cmd.exe×122, node.exe×27, where.exe×19, ipconfig×4, whoami/HOSTNAME/python/tasklist×3 each, attrib×2, PING×1, powershell×1). 53 of them (cmd.exe×30, node.exe×23) occurred in the first 27 minutes, before any of my own bulk testing — plain agent activity is enough.

Ruled out here

Valid Microsoft signature on cmd.exe; no malicious/unknown DLLs in System32; AppInit_DLLs empty + LoadAppInit_DLLs=0 (both bitnesses), no AppCertDlls, no cmd AutoRun; no IFEO hijack; Huorong 6.0 AV very likely irrelevant (its hipsdaemon.log shows no interception of cmd.exe/node.exe; disabling hardening, whitelisting the binaries and a reboot changed nothing); no console/terminal delegation misconfiguration; 32-bit and 64-bit console apps behave identically; CRT DLLs present.

Questions

1. Why does the spawn path use CREATE_NO_WINDOW/ShellExecute for command execution when CREATE_NEW_CONSOLE/inherited-console spawns work under the same token? Relaxing that flag appears to fix both the popups and the outright failure of .cmd-based tooling.
2. Failing that, can the modal dialog be suppressed (STARTF_USESHOWWINDOW + SW_HIDE, or SetErrorMode(SEM_FAILCRITICALERRORS))? A silent failure beats a modal box on every turn (cf. #1344).
3. Should console-dependent spawns be surfaced as a structured SANDBOX_UNAVAILABLE/denial fact instead of a bare Access is denied?

Related: dsh-win32 compatibility notes list this signature (0xC0000142 / STATUS_DLL_INIT_FAILED associated with restricted-token launch) and point at Desktop PR #266 — https://raw.githubusercontent.com/sjh9714/dsh-win32/refs/heads/master/docs/windows-first-run.md

Happy to run any diagnostic on this machine — it reproduces 100% of the time. Environment is stock: no packaged runtime files modified, AV not disabled, permissions not widened.

Version @deepseek-ai/dsh 0.1.5-rc.2 · @deepseek-ai/dsh-sandbox-windows-acl 0.1.5-rc.2 OS Windows 11 Pro 25H2, build 26200.9457 · Node v24.19.0 · Executor shell Windows PowerShell 5.1.26100.9444 (no PS7 on this host) Mode workspace-write (default, sandbox confirmed active) · launched with npx dsh from an interactive PowerShell with a console · zh-CN locale

Symptom
Console children started inside a Pwsh tool call raise a modal Windows "Application Error" dialog and die with STATUS_DLL_INIT_FAILED (0xC0000142) — but only on some spawn paths. Because agent activity constantly reaches cmd.exe-dependent tooling (.cmd/.bat shims = the npm.cmd/npx.cmd/pnpm.cmd path), the user gets a popup on essentially every conversation turn. GUI processes are unaffected.

The decisive matrix (all inside ONE sandboxed Pwsh call)
Spawn method Result
Start-Process cmd.exe (PS 5.1 default = ShellExecute) -1073741502 + popup ❌
.NET ProcessStartInfo, UseShellExecute=$true (WindowStyle Normal or Hidden) -1073741502 + popup ❌
.NET ProcessStartInfo, UseShellExecute=$false, CreateNoWindow=$true -1073741502 + popup ❌
Start-Process -NoNewWindow throws Access is denied ❌
UseShellExecute=$false + CreateNoWindow=$false + WindowStyle=Normal cmd /c "echo OK" prints OK, exit=0 ✅
… same path where.exe node → prints path, exit=0 ✅
… same path node.exe -e "console.log(...)" → prints output, exit=0 ✅
… same path python.exe -c "print(1)" → prints 1, exit=0 ✅
… same path _probe_shim.cmd (exit /b 5) → prints SHIM-RAN, exit=5 ✅
… same path via cmd /c _probe_shim.cmd → runs, exit=0 ✅
CREATE_NO_WINDOW (either direct or via cmd /c) _probe_shim.cmd → -1073741502 + popup ❌ (never runs)
GUI (notepad.exe) exit=0 ✅
A .cmd child that writes a probe file succeeds on the direct path and never executes on the CREATE_NO_WINDOW path — a real execution difference, not a reporting artifact. -WindowStyle Hidden still allocates a console, so window visibility is not the factor.

Interpretation
The restricted token is not the blocker: the same token runs cmd.exe/node.exe/.cmd fine when the child gets a console. The failing paths are exactly those where the caller does not create a console (CREATE_NO_WINDOW, and the ShellExecute route through Explorer), leaving cmd.exe to AllocConsole() itself and fail. Note this contradicts a literal reading of the documented boundary ("CREATE_NO_WINDOW/CREATE_NEW_CONSOLE children die during DLL initialization"): in my tests CREATE_NEW_CONSOLE works and CREATE_NO_WINDOW alone is sufficient to kill.

The host console is not the trigger — this host is launched from a console-attached PowerShell, and a sandboxed CreateProcess that creates a console succeeds, so #810's "console-less host" does not describe this machine.

Sandbox is demonstrably active
复制
Set-Content C:\Users\28139_dsh_sandbox_probe.txt → Access to the path ... is denied.
Set-Content D:\Deepseek Harness_dsh_sandbox_probe.txt → success
TMP = C:\Users\28139\AppData\Local\Temp\dsh-wT3NhX (private per-session temp)
Outside the sandbox (user's own terminal) the identical command returns 0.

Windows System log, provider Application Popup (ID 26), one entry per failure: Application popup: cmd.exe - Application Error : 应用程序无法正常启动(0xc0000142)。请单击“确定”关闭应用程序。

Popup census by day: 0 cmd.exe/node.exe popups from 08-25 to 09-07 (before DSH was ever launched; the ~19 entries there are SakuraCat.exe/audiodg.exe/steamwebhelper.exe), then 188 on the first DSH session day (cmd.exe×122, node.exe×27, where.exe×19, ipconfig×4, whoami/HOSTNAME/python/tasklist×3 each, attrib×2, PING×1, powershell×1). 53 of them (cmd.exe×30, node.exe×23) occurred in the first 27 minutes, before any of my own bulk testing — plain agent activity is enough.

Ruled out here
Valid Microsoft signature on cmd.exe; no malicious/unknown DLLs in System32; AppInit_DLLs empty + LoadAppInit_DLLs=0 (both bitnesses), no AppCertDlls, no cmd AutoRun; no IFEO hijack; Huorong 6.0 AV very likely irrelevant (its hipsdaemon.log shows no interception of cmd.exe/node.exe; disabling hardening, whitelisting the binaries and a reboot changed nothing); no console/terminal delegation misconfiguration; 32-bit and 64-bit console apps behave identically; CRT DLLs present.

Questions
Why does the spawn path use CREATE_NO_WINDOW/ShellExecute for command execution when CREATE_NEW_CONSOLE/inherited-console spawns work under the same token? Relaxing that flag appears to fix both the popups and the outright failure of .cmd-based tooling.
Failing that, can the modal dialog be suppressed (STARTF_USESHOWWINDOW + SW_HIDE, or SetErrorMode(SEM_FAILCRITICALERRORS))? A silent failure beats a modal box on every turn (cf. #1344).
Should console-dependent spawns be surfaced as a structured SANDBOX_UNAVAILABLE/denial fact instead of a bare Access is denied?
Related: dsh-win32 compatibility notes list this signature (0xC0000142 / STATUS_DLL_INIT_FAILED associated with restricted-token launch) and point at Desktop PR #266 — https://raw.githubusercontent.com/sjh9714/dsh-win32/refs/heads/master/docs/windows-first-run.md

Happy to run any diagnostic on this machine — it reproduces 100% of the time. Environment is stock: no packaged runtime files modified, AV not disabled, permissions not widened.

[PerryLink]

This is a documented boundary of the Windows restricted-token sandbox, and the repository states it in
three places. What it does not state is that every console child fails -- and that distinction matters,
because a Windows-only test in the tree asserts the opposite. Here is what I could and could not establish.

1. The failure mode is written down

packages/sandbox/sandbox-windows-acl/README.md:117

• 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.

The module header lists the same under "Known boundaries (inherent to restricted tokens, not this port)"
(packages/sandbox/sandbox-windows-acl/src/index.ts:26-28), and a design note from 2026-09-16 records the
decision that produced the current arrangement
(.agents/notes/implemented/bug-fix/2026-09-16-windows-subprocess-console-visibility.md:13-15,21): window
hiding is done with STARTF_USESHOWWINDOW plus SW_HIDE, deliberately without either console flag.

2. The restricted child is not created with those flags

packages/subprocess/win32-process/src/process.ts:455-456 sets
dwFlags: abi.STARTF_USESTDHANDLES | abi.STARTF_USESHOWWINDOW and wShowWindow: abi.SW_HIDE; the creation
flags at :542 and :567 are only CREATE_SUSPENDED (plus CREATE_UNICODE_ENVIRONMENT), and abi.ts
defines no console flag at all. A restricted child is created through sandbox.spawn(...)
(packages/sandbox/sandbox-windows-acl/src/runner.ts:182), so it takes that native path.

The windowsHide: platform === 'win32' you will find at
packages/subprocess/subprocess-local/src/spawn.ts:466 is real, but it belongs to the fallback
containment path (packages/subprocess/subprocess-local/src/index.ts:184-185, taken only when the Win32 Job
runner is unavailable) and to the private Node Job runner itself
(packages/subprocess/subprocess-local/src/windows-job.ts:141) -- an unrestricted helper that then creates
the target natively. I checked this because it looks exactly like the contradiction one would hope to find
here, and it is not one.

3. What that means for your report

I am not going to tell you those flags are the cause. Your report establishes that a console program fails
to start for you under workspace-write, and I cannot reproduce that here -- but the repository expects the
opposite. packages/sandbox/sandbox-windows-acl/tests/control.spec.ts:20-46 is Windows-only and spawns a
real console child through the real subprocess seam and the ACL runner in both modes, asserting
exitCode: 0 (:39), empty stderr (:40) and { visible: false } (:41). I could not execute it -- this
checkout is read-only -- so I am reporting it as evidence about intent, not as a result.

That turns the open question into "what differs in your environment" rather than "which flag is wrong". The
three things worth capturing next: dsh --dump-config for the active composition, whether the same command
succeeds under read-only, and the exact child command line.

4. The modal dialog is a separate, also-unhandled thing

Nothing in the tree calls SetErrorMode, ThreadErrorMode or passes SEM_FAILCRITICALERRORS -- I grepped
the whole repository at ddefc45fbc and there are zero hits. STARTF_USESHOWWINDOW with SW_HIDE governs
window visibility (packages/subprocess/win32-process/README.md:35), not Windows' hard-error reporting. So
a child failing during DLL initialization can still raise a dialog even though its own window is hidden.
That part is a genuine gap, and it is independent of the question in section 3.

For what it is worth, #2730 is the same symptom a month earlier on Windows 10 22H2 and is also unanswered.
If they are one defect, the two threads are probably worth joining rather than answering twice.

[ase-sketch]

Confirmed still reproducing on DeepSeek Harness Desktop 0.1.7-alpha.2 (Windows 11), and I narrowed it down with a controlled experiment that isolates the exact breaking link.

Symptom

• File policy workspace-write / read-only: every pwsh tool call returns exit code 3221225794 (0xC0000142, STATUS_DLL_INIT_FAILED) with empty stdout/stderr and no windows-acl-run: runner signature.
• danger-full-access: the exact same command succeeds.

Controlled experiment (runner extracted from the installed app)

I extracted @deepseek-ai/dsh-sandbox-windows-acl/lib/runner.js + deps from the desktop install and drove it standalone with the exact seam contract (--workspace/--temp/--mode workspace-write, tested both the agentless flow and the seam-managed --write-sid/--temp-write-sid flow with ACEs pre-materialized via AclWriteGrant):

Runner interpreter	Confined child	Result
system node.exe	cmd.exe /c echo	✅ exit 0
system node.exe	powershell.exe -Command	✅ exit 0
system node.exe	MSIX Store pwsh.exe (WindowsApps alias)	✅ exit 0
DeepSeek Harness.exe (ELECTRON_RUN_AS_NODE=1)	any of the above	❌ child exit 0xC0000142

Instrumenting runner.js shows the whole runner chain succeeds under the Electron interpreter — win32 API loaded, restricted token created (AclSandbox.init() ok), sandbox.spawn() returns — and then the confined child itself dies at DLL initialization (child exit 3221225794). The runner mirrors the child's exit code, which is why no windows-acl-run: signature is printed and the seam surfaces a bare 0xC0000142.

Conclusions

• The WRITE_RESTRICTED token, the workspace/temp capability-SID grants, and even MSIX-packaged pwsh are all exonerated — everything works when the runner interpreter is a console-subsystem binary.
• The failure appears only when the runner's interpreter is the console-less GUI-subsystem Electron binary: confined CUI children then fail console initialization under the restricted token → 0xC0000142. This matches the "console-less host" framing in [Bug] Windows: sandboxed pwsh always dies with 0xC0000142 under console-less host (desktop launch path) #810.
• In 0.1.7-alpha.2, dsh-sandbox-local's windowsAclRunnerInvocation() still returns [process.execPath, runner.js]; in the packaged desktop app process.execPath is the Electron binary, and dsh-desktop-host does not override windowsAclRunnerArgs. So the desktop host still runs the ACL runner on the Electron binary — this looks like an incomplete fix / regression of the root cause behind the desktop issues dsh prints `failed to load .env: EISDIR` when a directory named `.env` exists in the working directory #71/加油小鲸鱼🐳 #83/能否支持vscode插件模式？ #84 (note: ELECTRON_RUN_AS_NODE=1 alone does not help — the binary stays GUI-subsystem and console-less).

Suggested fix directions

1. Don't use process.execPath as the runner interpreter when it is a GUI-subsystem Electron binary; resolve a real console-subsystem node.exe (or ship a tiny console-subsystem trampoline).
2. Alternatively make the confined spawn console-safe from a console-less host — e.g. create the child with CREATE_NO_WINDOW/DETACHED_PROCESS-style flags (or pre-allocate a console) when stdio is piped, so the restricted child never goes through console initialization.
3. Error surfacing: when the confined child dies before producing output, wrap the mirrored exit code with context (e.g. windows-acl-run: child failed during process initialization (0xC0000142)) instead of surfacing a bare NTSTATUS.

Happy to share the full repro scripts if useful.