Windows 10: workspace-write sandbox kills every child process with 0xC0000142 (default DACL names a capability SID)

[AndySze]

Summary

On Windows 10 22H2 (10.0.19044) every child process started under the workspace-write sandbox dies in DLL initialization with 0xC0000142 (STATUS_DLL_INIT_FAILED) and no stdout/stderr, so every agent shell command fails. read-only and danger-full-access are unaffected.

The trigger is the ACE that setTokenDefaultDaclGrant adds to the restricted token's default DACL: when it names the derived capability SID (S-1-4-x-y) instead of a well-known SID, creating the child's image section fails the second access check. Naming the logon SID instead fixes it while keeping workspace confinement.

Environment

• Windows 10 Education 10.0.19044 (x64). The sandbox-windows-acl token comments record verification on Win11 26200.
• @deepseek-ai/dsh 0.2.1-rc.3, Desktop Host (apps/desktop-host), default desktop profile.
• Permission preset workspace-write.
• pwsh (PowerShell 7) is not installed; the executor falls back to powershell.exe (5.1). The failure is not specific to the target: powershell.exe, cmd.exe and whoami.exe all die the same way.

Reproduction

1. Start the Desktop app, open a new session (default preset = workspace-write).
2. Ask the agent to run cmd /c echo hello.
3. Tool result: (no output) / [exit code: 3221225794].

Evidence from the session store (job/settled events): "detail":"exit code: 3221225794", no stderr. Last known-good run on this machine was 2026-10-28T16:31Z under the same preset — its stderr carried CannotCreateTypeConstrainedLanguage, i.e. the restricted token was in effect and working.

Isolated cause (controlled experiments, same machine, same code)

#	Variant	Created from	Result
1	CreateProcessW + Job + CREATE_SUSPENDED (no sandbox)	plain node	exit 0
2	full subprocess-local runner path (IPC + fd 4/5/6)	plain node	exit 0
3	same	electron-as-node	exit 0
4	AclSandbox read-only token → powershell / cmd	app host process	exit 0
5	AclSandbox workspace-write token (real capability SID) → powershell / cmd / whoami	app host process	0xC0000142
6	workspace-write, default-DACL SID replaced with S-1-5-11	app host process	exit 0
7	workspace-write, real capability SID, cwd = C:\Windows\Temp	app host process	0xC0000142

So: not the Job, not CREATE_SUSPENDED, not stdio inheritance, not cwd, not the workspace ACE/Low label, not administrator/High-IL — it is the capability SID in the default DACL.

One observation we could not explain: the same token built from a plain node process (same user, same integrity level, identical TokenDefaultDacl, identical TokenIntegrityLevel, zero restricting SIDs on the source token) starts children normally; only tokens built inside the Desktop Host fail. We did not isolate whether it is a token property we did not dump (owner/primary group/session/capabilities) or something about the host's process creation. The fix below works regardless, but the mechanism is not fully closed.

Proposed fix (validated end to end)

packages/sandbox/sandbox-windows-acl/src/index.ts, in init():

-      setTokenDefaultDaclGrant(api, restrictedToken, this.tempWriteSidPtr ?? this.writeSidPtr ?? worldSid)
+      // The ACE names the LOGON SID (a well-known SID already in the
+      // restricting list), never a derived capability SID (S-1-4-x-y): on
+      // Windows 10 a capability SID in the default DACL makes every child
+      // process die in DLL initialization with 0xC0000142.
+      setTokenDefaultDaclGrant(api, restrictedToken, logonSid)

Why this is safe:

• The default DACL only shapes kernel objects the confined process creates without an explicit security descriptor (pipes, events, image sections); file writes take their DACL from the parent directory, so workspace confinement is unchanged.
• The logon SID is already in the restricting list, so the pass-2 check that motivated the grant still passes.
• It is narrower than read-only, which already grants this ACE to Everyone.
• The original intent — never tag default-DACL objects with the shared workspace capability — still holds.

Verified after the change on this machine: cmd /c echo returns exit 0 in a workspace-write session; cmd /c "echo x > C:\Users\...\Desktop\escape.txt" returns access denied and creates nothing; an in-workspace write succeeds.

Questions

1. Is the capability-SID default DACL intentional, or could it use the logon SID everywhere?
2. Has this been seen on Windows 10 hosts (the token comments only record Win11 26200)?
3. Is there any objection to the patch above? We are running it locally; we would be glad to hand over the diff (external PRs are not accepted per CONTRIBUTING, so we are posting here instead).

[PerryLink]

Your variant 6 is the one that isolates it, and the code says why that SID is there.

packages/sandbox/sandbox-windows-acl/src/index.ts:304:

setTokenDefaultDaclGrant(api, restrictedToken, this.tempWriteSidPtr ?? this.writeSidPtr ?? worldSid)

In workspace-write the token's default DACL names the derived capability SID (S-1-4-…); in read-only it names the world SID. The comment directly above (:301-303) records the intent: default-DACL objects created in one session's temp tree must not acquire the shared workspace capability. So the SID you replaced is deliberate, and swapping it for a well-known SID is what that comment is trying to avoid.

Two things worth adding before this goes in as a root cause.

1. S-1-5-11 is Authenticated Users, much wider than the per-logon SID. findLogonSid already exists in the same package (token.ts) and is imported at index.ts:55, so the tighter experiment is repeating variant 6 with the logon SID. If that works, the fix can be "add the logon SID to the default DACL alongside the capability SID" instead of replacing it — same effect on image-section creation, cross-session property preserved.
2. On the asymmetry you could not explain: the restricted token is built from the host process's token, so anything the Electron host's token carries that your dump did not cover is inherited. Matching TokenDefaultDacl and TokenIntegrityLevel is necessary but not sufficient for "identical token".

I read the source at f3803c96; I have not run your variants.