Sandbox unusable on Win11 build 26200: runtime LoadLibraryExW denied under restricted token (E_ACCESSDENIED 0x80070005)

[Leo-Carp0105]

TL;DR

@deepseek-ai/dsh-sandbox-windows-acl appears unusable on Windows 11 build 10.0.26200. Any child process spawned under the ACL restricted token dies at runtime library load with E_ACCESSDENIED (0x80070005):

• processes that only load image dependencies at startup survive (cmd.exe, icacls.exe);
• processes that load libraries at runtime all fail (pwsh -> hostfxr.dll, Windows PowerShell 5.1 -> CLR init, node -> CNG).

Consequences on this machine: the pwsh terminal tool cannot start at all (surfaces as PTY shell exited during startup), and every sandboxed one-shot bash/node/python call fails too. In-process file tools still work, which made this hard to spot.

I ran a controlled experiment matrix - 8 variables (ConPTY vs plain pipes, integrity level, token flags 8/9/12/13, token default DACL, restricting SID list, icacls /reset after robocopying the tree, target location, transport method). None of them change the outcome, which points at a kernel-level rule rather than any policy knob.

Full report attached (DIAGNOSIS.md); the re-runnable drivers are matrix.js, variant.js and pty-driver.js.

Two specific things worth a look:

1. dsh-sandbox-windows-acl/README.md line 189 - the "objects another AppContainer-based tool has ACL'd with a package SID" exception appears wider than documented on this machine: it reaches ordinary Program Files and user directories, and clearing ACEs with icacls /reset does not lift it.
2. The source comment above createRestrictedToken in acl-types.js claims this design was "verified on Win11 26200". Here the keep-alive group is verifiably in place, the build is 26200, and runtime DLL init plus CNG still fail.

I cannot localize the responsible kernel rule from userspace (needs a kernel debugger or ETW), but for affected users the outcome is the same: the sandbox cannot be used.

---

中文摘要

Windows 11 build 10.0.26200 上，被 @deepseek-ai/dsh-sandbox-windows-acl 的受限令牌启动的子进程无法在运行期加载库：LoadLibraryExW 返回 E_ACCESSDENIED (0x80070005)。

• cmd.exe / icacls.exe（只在启动期加载映像依赖）正常；
• pwsh / Windows PowerShell 5.1 / node（需要运行期加载托管运行时或 CNG）全部失败；
• 与目标文件 ACL、完整性级别、令牌标志、令牌默认 DACL、restricting 列表、目标位置均无关。

后果：该沙箱在本机完全不可用，任何被它包装的子进程都起不来（终端工具直接不可用）。

---

Environment

OS	Windows 11, build 10.0.26200
Host	DeepSeek Harness desktop app, dsh 0.2.0-rc.2
@deepseek-ai/dsh-sandbox-windows-acl	0.0.1-rc.1
@deepseek-ai/dsh-terminal-bash	0.0.1-rc.3
@deepseek-ai/dsh-subprocess-local	0.2.0-rc.2
node-pty	1.2.0-beta.15

Symptom

Any sandboxed pwsh invocation dies during startup. Exact stderr:

Failed to load [C:\Program Files\PowerShell\7\hostfxr.dll], HRESULT: 0x80070005
The library hostfxr.dll was found, but loading it from C:\Program Files\PowerShell\7\hostfxr.dll failed
exit = 0x80008082

At the tool layer this surfaces as PTY shell exited during startup (terminal-bash.js: waitReason === "session_exit"), which is misleading - the PTY itself is fine.

Minimal reproduction

On build 26200, launch a child process under the ACL restricted token this package uses (token flags 13, keep-alive restricting group [logon SID, Everyone]), then have it call LoadLibraryExW at runtime:

• startup-time image dependency loading -> OK (cmd.exe, icacls.exe survive)
• runtime library load -> E_ACCESSDENIED (0x80070005)

Additional failures observed, same root cause:

Process	Failure
pwsh	hostfxr.dll load denied, exit = 0x80008082
Windows PowerShell 5.1	CLR init, exit = 0xffff0000
node	CNG / CSPRNG assertion

Ruled out (all measured on this machine; no effect on the outcome)

Variable	Result
ConPTY vs plain pipes (no PTY at all)	both fail identically
Sandbox-wrapped cmd.exe inside ConPTY	exits 0 - so this is not a PTY/handoff problem
Integrity level (Low)	no change
Token flags (8 / 9 / 12 / 13)	no change
Token default DACL (incl. explicit Everyone)	no change
Restricting SID list + BUILTIN\Users	no change
robocopy the whole PowerShell tree to a user directory + icacls /reset (clearing package-SID ACEs)	no change
Target location, transport method	no change

Every policy-level knob was varied without effect, so the denial appears to come from a kernel-level rule specific to this machine - consistent with the class your README already flags as unconfirmed.

Blast radius

Not limited to terminals. Any child process spawned under this sandbox that loads libraries at runtime fails: sandboxed pwsh terminals, plus one-shot bash/node/python calls routed through ctx.sandboxPolicy. In-process file tools (which spawn no children) still appear to work, which made this hard to spot.

Two documentation / assumption points worth a look

1. dsh-sandbox-windows-acl/README.md line 189 (the "objects another AppContainer-based tool has ACL'd with a package SID ... the kernel rule is unconfirmed" entry). Here the effect is wider than described: it reaches ordinary Program Files and user directories, and clearing ACEs with icacls /reset does not lift it.

2. The source comment above createRestrictedToken in acl-types.js claims the keep-alive group design was "verified on Win11 26200":

The logon SID + EVERYONE keep-alive group is shared by both modes: early DLL init dies with 0xC0000142 and CNG fails without them.

That premise does not hold here. The keep-alive group was verifiably in place (workspace-write = [logonSid, Everyone, workspaceSid, tempSid], checked item by item against source), the build is 26200, and runtime DLL init plus CNG still fail.

Honest boundary

I can prove this is none of the configurable knobs listed above. I cannot localize which kernel rule is responsible from userspace - that needs a kernel debugger or ETW tracing. For affected users the distinction does not change the outcome: the sandbox is unusable on such a machine.

Workaround we used

Ran the profile with danger-full-access, which bypasses the provider entirely (spawnArgv: if (policy.mode === "danger-full-access") return argv).

Related observation worth a separate look: sandbox-policy.mode and approval.policy must be changed as a pair. Changing only sandbox-policy.mode composes {danger-full-access, ask}, which matches no preset, so dsh-permission-presets throws and Cordis then silently isolates the plugin - no /permission command, no composer permission control, and no log line anywhere. That failure mode is very hard to diagnose.

Attachments

• DIAGNOSIS.md - full report: error text, experiment matrix, timeline, exact commands
• matrix.js, variant.js - experiment matrix and variant driver (re-runnable)
• pty-driver.js - standalone ConPTY + restricted-token driver used for the minimal repro
  DIAGNOSIS.md
  matrix.js
  pty-driver.js
  variant.js

[argszero]

Thanks for the controlled matrix — the split "processes that only load image dependencies at startup survive, runtime loaders all die" is what makes this report usable, and the host-swap control in the follow-ups is what turned it from a curiosity into a reproduce-the-cause claim. Two source-side notes and one pointer.

1. On your two documentation points. Your reading is fair. Both places state a single-machine verification at build granularity: token.ts:183 ("verified on Win11 26200, see the POC-worktree restrict-variant harness") and runner.ts:213 ("verified empirically on this machine (Windows 11 build 26200, Node 24)") — the latter inside a comment about exit-code mirroring, not about DLL init. A build number is not a guarantee across patch levels, hardware or host type, and your report is the evidence that the narrower reading is the correct one. The README.md:189 AppContainer package-SID entry is already flagged as an unconfirmed kernel rule, so the "wider than documented, and icacls /reset does not lift it" half is new information rather than a contradiction.

2. This is not the family our advisor recognizes, and I want to be exact about why. @argszero/cordis-plugin-sandbox-grant-advisor's native-init family is keyed on the bare status 0xC0000142 (either 3221225794 or -1073741502) in a foreground shell projection — a child that never reaches its entry point and leaves no message of its own. Your symptom has the opposite shape: the process starts, loads at runtime, and dies with a message (hostfxr.dll / HRESULT: 0x80070005, exit 0x80008082; PS 5.1 0xffff0000; node via CNG). It is plausibly the same class — a console-less host plus the restricting list that workspace-write necessarily carries — expressed after the loader instead of inside it, but the code differs, so the plugin deliberately does not claim it. That is a design rule there (only STATUS_DLL_INIT_FAILED is classified; 0xC0000409 and 0xC0000135 are deliberately not folded in), not an oversight.

3. The silent-isolation observation is the one I would file on its own — it is a different failure mode, and it is diagnosable today. When dsh-permission-presets throws on a {danger-full-access, ask} composition, the plugin simply never comes up and core writes no line about it. @argszero/dsh-activation-doctor (npm; repo argszero/dsh-activation-doctor) exists for exactly that: it reads the runtime's own per-entry status and reports every entry that failed to activate or never started, including the composition stage where a bundle or entry is skipped — so "no command, no composer permission control, no log line" becomes a named entry instead of silence. Mount it next to the profile and it will name the fiber.

Your workaround (danger-full-access) and the pair requirement — sandbox-policy.mode and approval.policy must move together or the composition matches no preset — are worth keeping in this thread; the second one is a trap that presents as an unrelated disappearance.