Desktop (Windows): shell tool calls hang forever under workspace-write sandbox - no spawn, no approval event

[z18153881503-arch]

Environment

• dsh 0.2.1-alpha.1 desktop, Windows 11 x64 (10.0.26200), pwsh-local shell
• Default permission preset workspace-write (sandbox: workspace-write, approval: ask)

Symptom

Any shell (pwsh) tool call hangs indefinitely and silently. Forensics on the session store show:

• no approval/request waterfall event ever reaches the renderer,
• no approval/asked audit event is written,
• no child pwsh/powershell process is ever created.

So the call stalls before both the approval prompt and process spawn - during sandbox initialization.

Control experiment

Switching the same session to the danger-full-access preset (sandbox: danger-full-access, approval: never) makes every tool call complete normally. The tool, model and host are fine; only the ACL-sandbox path stalls.

Suspected area

@deepseek-ai/dsh-sandbox-windows-acl initialization between prepareScheduledExecution and process spawn - possibly an ACL/token setup step that blocks on certain host configurations.

Impact

From the user perspective the agent just looks hung (no error, no prompt, only silence). Very hard to diagnose without reading the session store directly.

Workaround

Run with the danger-full-access preset (approval: never). Has anyone else hit this on Windows?

[argszero]

Yes — you are not alone on Windows, and your forensics narrow it usefully. Two reports from the same day describe this backend stalling: #9467 (Windows 10 19044, workspace-write, pwsh dies 100% at 0xC0000142) and #9471 (Windows 11 26200, confined children denied at runtime library load). Yours is a third shape: a stall, not a status.

What your session store shows — no approval/request, no approval/asked, no child process — places the stall after prepareScheduledExecution and before spawn, i.e. in the ACL backend's setup (token construction / ACL materialization). Two things are worth capturing while you are in there:

1. whether any approval/* event ever appears after a longer wait — a genuine stall and a very slow grant look identical from the outside;
2. the tool call's own record, and any stderr from a non-terminal path. The ACL family's own failures print a Win32 ... line, and an AggregateError (a grant and its rollback failing) is a known shape in this backend. A bare stall with none of those is itself a fact worth reporting.

A note on why there is nothing to read: the backend fails closed and, for a bare nonzero child status, silently — only exit 127 with the windows-acl-run: signature is reclassified as a runner failure (sandbox-local/src/index.ts:233-241). This is what @argszero/cordis-plugin-sandbox-grant-advisor (npm) is for: it recognizes the Windows ACL families from what a session can actually observe — a bare 0xC0000142 in a foreground shell result, the Win32 grant line, PTY shell exited during startup, the aggregate-error sentence, a denial inside the workspace — and explains the class.