DeepSeek Harness runner hang and silent sandbox denials

Sandbox problems on Windows have two extreme manifestations: one is "everything was said but nothing ran" — a tool call hangs forever in the running state, the interface keeps spinning, and it never returns even after two hours; the other is "it ran and was denied, but nobody told the model", so the model sees no denial marker and finds another spelling to bypass the sandbox. The former comes from the sandbox child process's start handshake having no timeout at all: the runner has forked and IPC is connected, but the start frame is lost in the pipe, so the two sides wait on each other forever (the community's source review confirms setTimeout appears 0 times in the entire runner.js file); the latter comes from the denial classification's match surface being too narrow: the sandbox only matches the denial signature against stderr, while some runtimes print EACCES on stdout, so sandbox.denied is never set and neither the [sandbox: file access denied …] marker nor the escalation hint ever appears (#9515, #9497). This article gives "how to judge" and "how to fix / how to work around" respectively; both can be handled without restarting all of DSH.

DeepSeek Harness: tool calls hang forever, the start frame is lost with no timeout

In one line: the essence of this hang is a "lost start handshake", not a slow command — because from the parent to the runner to the tool layer, no layer ever put a timeout on it. The symptom is: the GUI keeps showing running (up to two hours or more), the session has neither tool/result nor an error, and only restarting the app recovers it (#9515).

DSH plugin: mechanism, why all three timeout layers miss it

According to the community's line-by-line source review, there are three places missing a timeout, layer by layer:

1. The runner itself has no timeout: dsh-subprocess-local/lib/runner.js enters a wait while awaiting the IPC start message, with no setTimeout anywhere in the file, so a lost start frame means both sides wait forever;
2. Session stats have no watchdog: sessionStats.pendingCalls is only a count and takes part in no timeout decision;
3. The tool layer is a cooperative timeout: tools/execute's timeout wrapper only aborts exec.signal then continues to await next(), and cannot race out a promise that never settles; moreover it arms only when the tool declares timeoutMs, and on the scene no tool ever declared it (#9515).

Connecting the three makes it clear: a "lost frame" is a low-probability event, but once it happens no layer along the chain cuts it off — so it hangs indefinitely until you restart.

DeepSeek Harness: three-step judgment, this is a zombie runner

The test is three things holding at once — the process is alive, uses almost no CPU, and has no child processes. Three steps:

1. See whether the runner process is still there. In a non-confined PowerShell list the candidates:

Get-Process node -ErrorAction SilentlyContinue |
  Where-Object { $_.Path -like "*dsh-subprocess-local*" } |
  Select-Object Id, ProcessName, StartTime, CPU

Expected: you see a process whose StartTime is clearly earlier than now and whose CPU value is very small.

2. See whether it has child processes. Run:

$runner = <the Id from the previous step>
Get-CimInstance Win32_Process -Filter "ParentProcessId=$runner" | Select-Object ProcessId, CommandLine
#   -> expected no output: the runner started, but the target command was never launched

3. See whether it is "alive but not moving". Sample CPU twice 30 seconds apart; if the two are nearly identical and under 1 second, while StartTime is already more than 3 minutes ago, it can be judged a zombie runner (#9515).

Cross-check: at this point the session should have no tool/result event for that tool — if a result already exists, this is not the family, so look elsewhere (a child that fails to start at loader init with 0xC0000142 is another family, covered in DSH plugin: Windows subprocess fails with 0xC0000142).

DSH plugin: handling, kill the zombie and add a non-cooperative backstop

Recovery is quick; preventing recurrence relies on a non-cooperative timeout. Two steps:

1. End the zombie runner (the fastest recovery). According to tests in the thread, after killing the process it self-heals in about 2 seconds and the tool call returns immediately, without restarting DSH:

Stop-Process -Id $runner -Force
#   -> expected: the stuck tool call returns as a failure within about 2 seconds and the session is usable again

2. Install a non-cooperative deadline backstop. The community plugin @argszero/cordis-plugin-tool-deadline-guard hooks tools/pre-execute and force-ends a call with a wall-clock bound independent of the underlying promise — exactly the layer that "cooperative timeout" lacks:

npm i @argszero/cordis-plugin-tool-deadline-guard

Mount it in the profile's patch layer:

- insert:
    - id: tool-deadline-guard
      name: '@argszero/cordis-plugin-tool-deadline-guard'

3. Verify: after reopening, run a command that will time out (for example pwsh -Command "Start-Sleep 600"); expect a timeout error within the plugin's wall-clock bound, rather than infinite spinning.

Boundary reminder: this family and "sandbox path hang" are two different things — the latter only appears under workspace-write and is fine once you switch to danger-full-access; whereas a zombie runner reproduces even in a no-sandbox scenario. So check "does switching to full access recover it" first; that immediately separates the two (#9515).

DeepSeek Harness: sandbox denials are not reported because the classifier misses stdout

In one line: the sandbox really did deny this write, but "denied" is recognized in only one place — the signature match on stderr; when the denial code appears on stdout, neither the marker nor the escalation hint is rendered, so the model sees "the command failed" rather than "you were blocked by policy". The consequence is more serious than it looks: the model does not know this is a policy boundary and switches to another spelling to bypass it (the example in the thread is overriding XDG_CONFIG_HOME to write config inside the workspace), so "the security control is silently dissolved"; another member of this family is failure being silently dropped (pipe stdio discarding output as 0 bytes, CIM returning silent defaults, and so on), covered in DeepSeek Harness command failures (#9497).

DSH plugin: mechanism, three conditions unmet at once so the marker never appears

According to the community's source review, the chain controlling the marker rendering has three gates:

1. Classification only recognizes stderr: classifyDenial / matchesSignature match DENIAL_SIGNATURES only against the command's stderr;
2. Some tools print the denial code on stdout: for example some runtimes' telemetry writes EACCES to stdout, leaving only the launcher's info lines on stderr, so not a single signature matches;
3. The render layer has another gate: the marker and hint are produced by the render layer, gated on result.sandbox?.denied; the escalation hint also needs the composition to provide a non-empty escalationModes. And DENIAL_SIGNATURES is a module-private constant, not exported, so a plugin cannot directly reuse it to add the judgment (#9497).

DeepSeek Harness: three-step judgment on whether this really was a sandbox denial

1. See whether the path is really outside the workspace. Check the target path being written in the failing command and confirm it is not inside the current workspace (the workspace path is visible under Settings → Workspace).
2. See the exit code and the result text. Expect "a non-zero exit code" + "the result has no [sandbox: file access denied …] marker" + "no escalation hint". "Really denied, but with no sandbox marker" is this family's fingerprint (#9497).
3. Manually verify which stream the denial happens on. In the confined session run:

pwsh -Command "echo probe > $env:USERPROFILE\probe-denied.txt"
#   expected: the file is not created and the command exits non-zero
#   Change the same content to write an in-workspace path; expected to succeed — this control rules out "the command was written wrong"

DSH plugin: handling, add the marker in post-execute

The core idea is not to change the sandbox, but to set sandbox.denied explicitly true after the result comes out, so the upper layer renders the standard marker itself. Three steps:

1. Install the community plugin @argszero/dsh-stdout-denial-guard (it sets sandbox.denied = true in tools/post-execute, and the hint is delivered via additionalContexts):

npm i @argszero/dsh-stdout-denial-guard

2. Mount it in the profile's patch layer:

- insert:
    - id: stdout-denial-guard
      name: '@argszero/dsh-stdout-denial-guard'

3. Verify: after reopening the session, run the denied command from step 2 again; expect the [sandbox: file access denied …] marker to appear in the result, and the model to receive a hint saying "this is a policy denial and you can request an escalation" instead of routing around it.

A boundary you must know: the plugin only covers the model side — it tells the model "you were denied" but does not change the sandbox's actual behavior. And for paths assembled on a shell command line it only does a best-effort scan and cannot be treated as a security boundary (#9497).

DSH plugin troubleshooting notes

The two symptoms look unrelated, but both belong to "the sandbox's behavior was not correctly expressed to the upper layer" — one is a missing timeout, the other a missing marker. The recommended order is to separate the two first, then dig in. Seven points:

1. Do one separation first: switching to danger-full-access makes the problem disappear → leans toward the sandbox path; does not disappear → leans toward the runner/process layer (#9515).
2. When it hangs, do not rush to restart DSH: first run the three-step judgment to confirm a zombie runner, then kill just that one process — restarting interrupts all sessions (#9515).
3. "Runner alive ≥3 minutes + CPU < 1 second + no child processes" directly means zombie; no need to wait longer (#9515).
4. Cooperative timeouts are unreliable: for any "it timed out but still does not return" phenomenon, suspect first that the underlying promise never settles, not that the timeout value is too small (#9515).
5. 2>&1 merged streams do not save the denial marker: the denial code was never on stderr to begin with, and after merging it is still not a match target (#9497).
6. When the model "cleverly changes its approach", check the marker first: the model routing around the sandbox is often because it was not told it was denied, not because it is fighting the policy (#9497).
7. State the fix status honestly: both are unfixed — the timeout patch and the denial classification are still in community-plugin form, and the plugin layer can only "backstop" (add a deadline, add a marker), not fix the root cause for the core.

When troubleshooting cross-process problems like these, besides watching process state, it is worth centralizing install/uninstall-type operations in one place to reduce variables. If you want plugin install/uninstall, updates and system logs all in one panel, use DSH Plugin Hub instead of typing commands everywhere — it gathers plugin install/uninstall, update confirmation, diagnostics and logs together, helping you rule out the "plugin layer" variable first.

Source: Discussion #9515, Discussion #9497.