Bug: dsh web freezes (event loop blocked) when the agent executes the pwsh tool on Windows — reproducible in clean profile

[emicovi]

Bug: dsh web freezes (HTTP dead, process alive) when the agent executes the pwsh tool on Windows

Version: @deepseek-ai/dsh@0.1.0-rc.7
Environment: Windows 10 (10.0.26200.9168) · Node v22.22.3 · PowerShell 7.6.3 · Chrome 2026

Summary

dsh web becomes completely unresponsive (the page at http://127.0.0.1:3080/ stops answering even for static assets; the port stays LISTENING and the process stays alive, but every request times out). The server has to be killed to recover. This happens while the agent is executing a pwsh tool call.

Repro (clean environment, no extensions, no user profile)

1. Start dsh web.

2. Open the UI in a clean browser profile (reproduced with Playwright chromium headless, no Chrome extensions loaded).

3. Send this message in the chat:

   Esegui Pwsh: Get-ChildItem Env: | Sort-Object Name | Format-List | Out-String -Width 300. Quando hai finito rispondi solo ok.

4. ~10 seconds later http://127.0.0.1:3080/ stops responding. The port remains LISTENING; the Node process is alive but the event loop appears fully blocked (no HTTP response for >40 s; only taskkill recovers it).

A second observed trigger: the agent runs Invoke-WebRequest (e.g. a DuckDuckGo search) inside a pwsh tool call; after the call is interrupted/retried, the same freeze occurs. Every incident so far (3/3) followed a pwsh tool execution.

Notes

• The UI itself works fine in a clean browser (typing, backspace, page loads — verified with Playwright). The freeze is in the server process, not the frontend.
• The freeze reproduces with both the built-in deepseek-official provider and a custom OpenAI-compatible route, so it does not depend on the model provider.
• This is 0.1.0-rc.7; 0.1.0-rc.6 fails to boot at all on this machine (launcher produces no output and hangs), so downgrading is not a workaround.

Possible cause (from reading the shipped bundles)

@deepseek-ai/dsh-subprocess-local (bundled in dsh rc.7) performs synchronous subprocess operations on the main thread:

• spawnSync("taskkill", ["/PID", pid, "/T", "/F"], ...) in the Windows process-tree teardown path;
• a process inspector that calls execFileSync(...) per poll tick (e.g. DEFAULT_INTERNALS.exec) inside while (treeAlive()) await sleepTick() loops.

If any of these synchronous calls stalls while a pwsh/conhost child is wedged, the Node event loop freezes and the HTTP server stops responding — matching the observed symptom.

Impact

Any user on Windows whose agent calls the pwsh tool (very common for Windows workflows) can hit a hard freeze of the whole harness; work in progress is interrupted (sessions are persisted but the loop dies mid-turn).

What I'm doing meanwhile

External watchdog that restarts dsh when the port stops responding, plus a diagnostics snapshot at freeze time. Happy to attach the snapshot (child processes, CPU, connections) and the Playwright repro script if useful.

---

UPDATE (2026-08-18): root cause refined — CPU busy-loop in the dsh process, not a blocked teardown

Captured with a live sampler while the freeze was happening (port 3080 still LISTENING, HTTP dead for 170+s, then force-killed):

• The dsh Node process burns 100% of one CPU core continuously (process CPU counter climbs ~2.2s of CPU per ~2.3s wall-clock, monotonically, never stopping).
• Thread count jumps from 12 → 13 at the freeze instant and stays constant.
• No child processes exist during the freeze (no pwsh, no OpenConsole, no conhost under the dsh PID) — so my earlier spawnSync(taskkill) hypothesis does NOT apply on Windows for this symptom.
• The process never recovers on its own; only taskkill /F resolves it.

Conclusion: the event loop is stuck in an infinite (or pathologically long) JavaScript busy loop in dsh rc.7, triggered by the agent/tool/Llm path (reproducible with a simple pwsh tool prompt in a clean browser). Machine-specific angle: detected on Windows 11 build 26200 (Insider/2026) with Windows Terminal 1.24 (Microsoft Store) and PowerShell 7.6.3 — but plain spawn and node-pty spawns of pwsh work fine in isolation on the same machine.

If needed I can attach the full sampler dump and a live CPU/proc snapshot.

---

UPDATE 2 (2026-08-18): ROOT CAUSE IDENTIFIED + WORKAROUND

• The freeze is a kernel-mode CPU spin in a dedicated thread (Win32 UserModeTime ≈ 4.5s vs KernelModeTime ≈ 54s on the hot thread; process at ~100% of one core), while the main thread is stuck in uninterruptible native code (V8 Debugger.pause cannot interrupt it; CPU profile shows main thread idle).
• It happens when the agent executes a pwsh tool call under the Windows ACL sandbox (@deepseek-ai/dsh-sandbox-windows-acl, a koffi/Win32 FFI restricted-token implementation). The pwsh executor itself uses plain child_process.spawn (not ConPTY).
• Workaround that completely fixes it (verified 150s clean repro): run dsh with DSH_PERMISSION_MODE=danger-full-access (ACL sandbox disabled, tools still work, pwsh at FullLanguage).
• Machine: Windows 11 build 26200 — the very build already flagged in the sandbox README ("on Windows 11 26200 CreateWellKnownSid(WinLocalLogonSid) fails with ERROR_INVALID_PARAMETER"), suggesting this sandbox has build-26200-specific issues. Please check the ACL-restricted-token spawn path (koffi FFI calls) on 26200.

---

UPDATE 3 (2026-08-18): environment detail + question for maintainers

• Reporter OS: Windows 11 25H2, build 26200.9168 (cumulative updates installed through Aug 2026; WindowsSelfHost registry keys are present — the machine has been on an Insider channel at some point).
• The kernel-mode spin survives current cumulative updates, so "update Windows" is not confirmed as a remedy. Everything points to the koffi/Win32 ACL-sandbox port having a 26200-specific defect (the package README already documents 26200-specific CreateWellKnownSid(WinLocalLogonSid) failure workarounds).
• Maintainers, please check: does the dsh-sandbox-windows-acl runner/restricted-token path busy-spin in kernel on Windows 11 build 26200? Is there a known Win32 quirk with CreateRestrictedToken / SetNamedSecurityInfoW / job objects on that build? Would a dsh-side patch (e.g., fall back to unconfined or a different Win32 API path on 26200) be the proper fix, or do you have a repro/knowledge that a newer or different Windows build resolves it?
• Interim fix confirmed working (150s clean run, no freeze): DSH_PERMISSION_MODE=danger-full-access.

[obiwankenobi699]

Thanks for the detailed update. The CPU-busy-loop evidence is very useful. I checked the current subprocess
implementation: the execFileSync process inspector is used by the POSIX inspectors, while Windows uses the
separate taskkill termination path. Since the freeze occurs with no child process and persists at 100% CPU, the
original teardown hypothesis may not explain this case.

Could you attach a CPU profile or repeated stack samples from the frozen dsh process, plus the exact dsh
commit/package version? That should help identify the JavaScript loop before anyone attempts a fix. A
comparison using the direct pwsh tool versus a normal shell command would also help narrow the triggering path.

[emicovi]

Thanks for the quick look! One clarification that matches your note: on Windows the spin is kernel-mode (the hot thread shows KernelModeTime ≈ 54s vs UserModeTime ≈ 4s) and it happens inside the dsh-sandbox-windows-acl (koffi/Win32 restricted-token) path — every pwsh tool call goes through it under the default workspace-write mode, and with DSH_PERMISSION_MODE=danger-full-access (sandbox disabled) the freeze disappears entirely (150s clean repro, no freeze). Could you check the koffi ACL runner for a busy-loop on Windows 11 build 26200 (25H2)? The module README already documents a 26200-specific quirk (CreateWellKnownSid(WinLocalLogonSid) fails). Happy to attach the sampler/diagnostics dump and the reproduction script.

[emicovi]

UPDATE 4 (2026-08-24): independent reproduction on dsh 0.1.1-rc.2 + isolation test of the ACL sandbox wrapper

Same symptom reproduced on a second machine/setup: @deepseek-ai/dsh@0.1.1-rc.2 (pnpm global), web profile, Windows, default workspace-write sandbox.

Live measurements at freeze time (identical to UPDATE 1/2):

• :3080 stays LISTENING but every request times out; the Node process is alive.
• CPU delta 5.0 s over 5 s wall-clock → 100% of one core, monotonically.
• Attached V8 inspector (--inspect=9229): Runtime.evaluate and Debugger.pause never respond → main thread stuck in non-interruptible native/FFI code (consistent with the kernel-mode spin captured in UPDATE 2; I can't sample kernel/user times from this machine, but the signature matches).
• Win32_Process under the web PID: no children at all (no pwsh, no browser-use, no confined runner) during the freeze.
• Socket to the LLM gateway in CLOSE_WAIT — consequence, not cause.
• Trigger: any sufficiently long-running pwsh tool call (browser-use tasks reproduce it every time; short ones like print(2+2) do not).

Isolation test of the ACL sandbox wrapper itself (same module dsh-sandbox-windows-acl@0.1.1-rc.2, used directly, outside dsh, workspace-write + workspace ACE materialization enabled):

• Child pwsh -NoProfile -Command 'Start-Sleep 3600' (alive, silent): wait() correctly stays pending, main event loop free, CPU ≈ 0 (the documented async drainPipe polling).
• Child 'print(page_info())' | browser-use (real harness, 165 B stdout): wait() resolves, exit 0, no freeze (completed in ~60 s).
• Conclusion: the koffi AclSandbox wrapper alone does not spin in a standalone process. The freeze appears only when the same library runs inside the web-runner host through the seam (dsh-sandbox-local runner-in-argv / ACE materialization + confined runner + job object). This narrows the defect to the seam integration on 26200, not to the raw wrapper spawn/pipe path — worth testing the whole sandbox-local seam in-process for a repro harness.

No fix on our side yet; we'll evaluate DSH_PERMISSION_MODE=danger-full-access next. Happy to attach the full diagnostics (CDP behavior, process tree dump, gateway logs) to this thread.

[emicovi]

UPDATE 5 (2026-08-24): workaround CONFIRMED on 0.1.1-rc.2 + browser-use/Bizneo

Workaround successfully verified end-to-end in the setup of UPDATE 4 (dsh 0.1.1-rc.2, web profile, Windows):

set DSH_PERMISSION_MODE=danger-full-access
dsh web

• The exact scenario that froze 100% of the time before (agent using the pwsh tool with the browser-use harness against a real SPA — Bizneo HR, multi-step navigation) now runs completely without freezing.
• No ACL sandbox in the path → no koffi/Win32 spin, no event-loop death, no child/pipe anomalies.
• Confirms the UPDATE 2-3 narrowed root cause: the freeze is in the Windows ACL restricted-token path (koffi) on this build, and disabling the sandbox removes it entirely.

Still pending a proper upstream fix for the ACL path on 26200 (this is a workaround, not a solution). If helpful, I can describe the exact seam invocation (dsh-sandbox-local runner-in-argv + ACE materialization) that the UPDATE 4 isolation test points to.