【Bug】[Windows] Workspace at user home dir breaks all shell commands ("Windows ACL temp root must be outside the workspace") and the agent then repeats one identical failing tool call 150 times with no circuit breaker

[ymb27]

Environment

• DSH Desktop 2.0.13 (Electron shell, dsh-plugin-desktop), Windows
• Session cwd / workspace: C:\Users\<user> (user home directory chosen as workspace)
• Sandbox: preset workspace-write, approval policy ask
• Model: router/coding, reasoning effort high, preset spec-react
• Affected module: windows-pwsh-sandbox (error surfaces from shell tool execution)

Summary

When the session workspace is the user's home directory on Windows, every shell tool call fails before execution because the sandbox temp root (C:\Users\<user>\AppData\Local\Temp) is inside the workspace. The agent then falls into a retry loop: it issues the exact same tool call with byte-identical arguments 150 times over ~19 minutes, receives the same error every time, and only stops when the user manually aborts the turn.

Steps to reproduce

1. Open/start a DSH session with cwd C:\Users\<user> on Windows (default shell tool: pwsh).
2. Ask anything that requires running a shell command (e.g. "why won't WSL start?").
3. Agent calls pwsh with any command.

Actual behavior

Every call fails at sandbox setup, before the command runs:

Error: Windows ACL temp root must be outside the workspace: workspace=C:\Users\<user>; temp=C:\Users\<user>\AppData\Local\Temp

The agent then adds sandbox_permissions: "workspace-write" to the arguments (without the required justification field), producing a second repeating error:

Error: invalid escalation: sandbox_permissions requires a justification

From that point the agent repeats the identical call until interrupted.

Evidence (from one session export)

Session had a single turn, 151 steps, 152 shell tool calls:

calls	arguments
150	identical: pwsh {"command":"wsl --status; ...","sandbox_permissions":"workspace-write","workdir":"C:\\Users\\<user>"}
1	same command without sandbox_permissions (first call)
1	different command (also failed with the temp-root error)

• Duration from first call to last assistant message: ~19 minutes (1138 s).
• Calls containing the required justification field: 0 of 152. The assistant repeatedly stated the correct diagnosis in its visible text ("missing the justification field, will add it and retry") but never actually included the field in the emitted arguments.
• The harness's repeated-call detector injected warnings 3 times (generic warning, then consecutive_calls: 5, then consecutive_calls: 8). The agent ignored them; no further warnings were injected for the remaining ~140 repetitions, and the turn was only ended by a user abort.

Expected behavior

Any of the following would have prevented the incident:

1. A workspace at the user home dir should be rejected or handled at session start (or the temp root should fall back to a directory outside the workspace), instead of failing lazily on every tool call.
2. A hard circuit breaker: after N consecutive identical failing tool calls (e.g. 10), the harness should end the turn with an error instead of continuing to feed the same error back to the model.
3. The repeated-call warning should escalate rather than stop after 3 injections.

Suggested fixes

• windows-pwsh-sandbox: when the resolved temp root lies inside the workspace, either pick an alternative temp root outside the workspace or fail fast with a session-level error ("this workspace location is unsupported on Windows, choose a different folder").
• Escalation validation: the error sandbox_permissions requires a justification is returned identically on every retry; consider one-shot enrichment of the error text (e.g. echo the exact expected field name and a schema example), or auto-reject loops where the fix requires changing emitted arguments, not retrying.
• Add a harness-level circuit breaker: track consecutive identical (tool, arguments-hash) calls; on the Nth consecutive failure, terminate the turn with a repeated-failing-call stop reason.

Notes

• Full session export is available on request (paths/username redacted).
• The model-side behavior (announcing a fix without applying it to the arguments) is a model-quality issue, but a harness circuit breaker would have capped the damage at ~10 calls instead of 150.