Windows: sandbox crashes Cygwin/MSYS tools and node — exit 3221225794 (0xC0000409)

[Parsec123]

Bug: Windows sandbox crashes Cygwin/MSYS tools and node — exit 3221225794 (0xC0000409)

Environment:

• Windows 11 Pro 10.0.26200.9168 (26100+)
• Node.js v24.14.1 (E:\nodejs)
• dsh 0.1.0-rc.5, built from source (deepseek-ai/deepseek-harness @ HEAD, 2026-08-13)
• Git for Windows (Cygwin/MSYS tools on PATH, e.g. C:\Program Files\Git\usr\bin\grep.exe)

Summary:
With the default workspace-write sandbox on Windows, the ACL restricted-token runner crashes many real programs. Cygwin/MSYS executables (e.g. git's grep) and node both die with exit code 3221225794 (= 0xC0000409, STATUS_STACK_BUFFER_OVERRUN — the Windows fast-fail path Cygwin and V8 use on fatal init errors). Simple commands like echo work fine.

Steps to reproduce:

1. Start dsh web on Windows (default permission mode workspace-write).
2. In a session, ask the agent to run node --version or a node script via the pwsh tool.
3. Ask the agent to search files with grep (tool-fs-search or shell).

Observed behavior:

The pwsh tool running a node script returns empty output with a crash exit code:

(no output)
[exit code: 3221225794]

The filesystem search tool fails identically:

Error: grep search failed (exit 3221225794)

Running the Cygwin grep directly inside the sandboxed shell reveals the underlying failure:

0 [main] grep (39476) C:\Program Files\Git\usr\bin\grep.exe: *** fatal error - CreateFileMapping S-1-5-21-4012803404-4064757952-1132577122-1001.1, Win32 error 5. Terminating.

(3221225794 = 0xC0000409 = STATUS_STACK_BUFFER_OVERRUN.)

Root cause analysis:
The Windows ACL sandbox runner (packages/sandbox/sandbox-windows-acl) wraps every command with a restricted token via CreateRestrictedToken. Cygwin/MSYS programs create a shared file mapping named after the user's SID at startup; under the restricted token that CreateFileMapping call is denied (Win32 error 5 / access denied), and Cygwin aborts immediately with a fast-fail exit code. node (V8) hits the same crash in this environment when running scripts that exercise similar paths. There is no error output because the crash happens before the program can print anything.

Impact:
On Windows with the default sandbox, the pwsh shell tool and the file-search tool (grep) are effectively unusable for anything beyond trivial commands — a significant first-run blocker for Windows users.

Workaround:
Set the permission mode to danger-full-access (e.g. DSH_PERMISSION_MODE=danger-full-access, or a profile patch over sandbox-policy). The sandbox then skips process wrapping entirely and everything works.

Suggested fixes (any one):

• Make the ACL runner compatible with Cygwin/MSYS (e.g. allow the user-SID-named file mapping, or detect Cygwin executables and skip wrapping them).
• When wrapping fails at process init, surface the actual Win32 error (like Cygwin's Win32 error 5) instead of a bare 0xC0000409 exit code with no output, so users can diagnose it.
• Document the Windows sandbox limitations for Cygwin/MSYS and node.

Happy to provide more logs or test a patch.

[argszero]

Verified against master (47f9438) — your root cause is consistent with the sandbox's actual token configuration, and the diagnostic gap has a concrete fix site. Three additions:

1. The restricted token is exactly the shape that would break Cygwin's init

packages/sandbox/sandbox-windows-acl/src/token.ts:203-215: the restricted token is built with DISABLE_MAX_PRIVILEGE | LUA_TOKEN | WRITE_RESTRICTED plus a restricting-SID list. LUA_TOKEN strips the admin/no-admin-elevation state, WRITE_RESTRICTED intersects all write accesses through the restricting list, and setTokenDefaultDaclGrant (index.ts:52) re-writes the token's default DACL to carry the capability-SID grants. Cygwin's startup CreateFileMapping for its SID-named shared section inherits that altered default DACL and the stripped privilege set — access denied (error 5) is the expected outcome, not a surprise. So the hypothesis holds up against the actual configuration.

This is also a documented class of failure, not a novel one: the package's own "Known boundaries" note (index.ts:23-31) already lists console isolation — "CREATE_NO_WINDOW / CREATE_NEW_CONSOLE children die with STATUS_DLL_INIT_FAILED under the restriction". Cygwin's fast-fail abort and V8's fast-fail are the same family: restricted-token environments break programs that need init-time kernel objects/privileges, and those programs die via the Windows fast-fail channel (0xC0000409), which produces no output.

2. The bare exit code is the runner's verbatim propagation — the diagnostic gap has an exact fix site

packages/sandbox/sandbox-windows-acl/src/runner.ts:187, 218: the runner mirrors the child's exit code straight through (return result.exitCode / process.exitCode = exitCode), and spawn.ts:128 deliberately passes 0 creation flags ("suspended/no-window variants are unusable under the restriction"). There is no fast-fail decoding — 0xC0000409 / 3221225794 passes through as an opaque number. Your suggested fix #2 (surface the real Win32 error) can be done in one place: in the runner, detect exitCode === 0xC0000409 (and the sibling 0xC0000005/0xC000013A family) and attach a hint like "child fast-failed at init — the Windows restricted-token sandbox (LUA_TOKEN/WRITE_RESTRICTED) can break programs that need init-time kernel objects (Cygwin/MSYS, V8); consider danger-full-access or a per-tool sandbox override". That converts an opaque number into an actionable diagnosis for every Windows first-run user.

3. The durable fix is image detection, not path-based exemptions

Suggested fix #1 (detect Cygwin/MSYS and skip wrapping) is right, but "skip wrapping" is the blunt end. A precise, cheap detector: scan the child PE's import table for cygwin1.dll / msys-2.0.dll (Git for Windows' grep/find/awk are Cygwin images; MSYS2 ships the same family) — or check the executable's magic + import directory once at spawn. Then route those images through a capability-compatible path (e.g. the sandbox-local no-wrap runner) while keeping the ACL runner for native Windows images. Path-based exemption (C:\Program Files\Git\usr\bin\...) is brittle — users install Git anywhere, and WSL interop binaries would need their own entry.

Cross-thread

This is the platform family: #1420 (Windows arg quoting via shell:true) and #1588 (Termux/Android — link() forbidden) are the same "the default runner on this platform breaks otherwise-fine programs" class. Worth a shared platform-compat checklist in the sandbox docs when the Windows matrix gets its own CI lane.

[sjh9714]

The Cygwin half of this matches what we measured independently, and I can add signatures plus what actually survives. The node half I have not reproduced, so I am splitting them.

On the Cygwin/MSYS side, this is now four independent sightings with two distinct signatures. Yours is CreateFileMapping S-1-5-21-.... We measured a different one first, from Git Bash starting under workspace-write.

cygheap_user::init: NtSetInformationToken (TokenDefaultDacl), 0xC0000022

A user later reported your signature on their own machine, and confirmed it still reproduces with an explicit shellPath, which rules out path resolution as a factor. Both are the same wall from two directions. 0xC0000022 is STATUS_ACCESS_DENIED on the token operation, Win32 error 5 is access denied on the section object, and cygheap initialization needs both. @argszero's read of token.ts:203-215 explains why. WRITE_RESTRICTED plus LUA_TOKEN is exactly the shape that denies a named shared section to a process whose whole startup depends on mapping one.

This is not fixable at the plugin layer, and I do not think it is fixable at the config layer either. It is not the sandbox misconfigured, it is the MSYS runtime model and a restricted token being incompatible. That also explains something that looked like laziness across the ecosystem, which is that every Windows shell solution requires danger-full-access. Their authors were not cutting corners, Git Bash simply cannot start in the sandbox.

What survives is a shell with no POSIX emulation layer. busybox-w32's ash is a native Win32 implementation with no cygheap, so the initialization that gets denied never happens. We run a full send and read round trip through the restricted token on windows-latest as a required CI job, and the same job reproduces the MSYS death on the identical path so the contrast stays honest rather than asserted. One command reproduces it locally.

SANDBOX_MODE=workspace-write node scripts/sandbox-smoke.mjs

The cost is real and worth stating. ash is not bash, so no arrays and no [[ ]].

On node dying with 0xC0000409, I have nothing. We have not reproduced that and it is a different failure from the Cygwin one, so I would not assume the same fix applies. One thing that might be worth eliminating before chasing the token, though. Your node lives on E:\nodejs. If the ACL runner grants the workspace and the usual system paths but not another volume, a node that cannot read its own installation would fast-fail early and look identical to a token problem. Worth a run with node on C: to see whether the crash follows the drive or the token, because those two lead to completely different fixes.

The three tool failures you listed are probably not one bug. grep.exe is Cygwin and lands on the wall above. node is unexplained. echo working is consistent with both, since it is a shell builtin that never spawns anything.

[zoahdev]

Shipped the diagnostic half (argszero's #2) — the durable Cygwin/MSYS interop fix (#1) is a separate, larger image-detection change.

• Branch: zoahdev/deepseek-harness@fix/windows-acl-fast-fail-hint (cherry-pick-ready against 47f943859b)
• packages/sandbox/sandbox-windows-acl/src/fast-fail.ts + runner.ts: the runner now decodes STATUS_DLL_INIT_FAILED (0xC0000142), STATUS_STACK_BUFFER_OVERRUN (0xC0000409), and STATUS_ACCESS_VIOLATION (0xC0000005) into a stderr hint naming the restricted-token cause and the danger-full-access/per-tool override workaround. The exit code itself is still mirrored unchanged (so the seam's existing contracts don't move).
• Regression in fast-fail.spec.ts; pnpm typecheck clean.

One correction on the thread: the observed 3221225794 is 0xC0000142 (STATUS_DLL_INIT_FAILED), not 0xC0000409 (STATUS_STACK_BUFFER_OVERRUN = 3221226505). Both are in the decoded family, so the hint covers it either way — but worth keeping the NTSTATUS names straight if this turns into the image-detection follow-up.