Skip to content
dshdocs

Windows Sandbox Crash — DeepSeek Harness Guide

P0 · reporter-assigned severity

Symptom

Section titled “Symptom”

After a routine cleanup of your Windows Temp folder, for example:

Terminal window
Remove-Item 'C:\Users\<user>\AppData\Local\Temp\*' -Recurse -Force

any subsequent sandboxed dsh command fails, including relaunching npx @deepseek-ai/dsh web itself. The error is:

Error: sandbox mode "workspace-write" is requested but no sandbox backend is usable
on this host; refusing to run the command unconfined. Install bubblewrap or run a
Landlock-enforcing kernel (Linux), ensure sandbox-exec is usable (macOS), or ensure
the ACL restricted-token runner can start (Windows) -- otherwise switch the consumer
to danger-full-access. Runner failure: windows-acl-run: --temp is not an existing
directory: C:\Users\m1354\AppData\Local\Temp\dsh-2hxmDi

None of that message’s three suggestions apply on Windows: bubblewrap and Landlock are Linux, sandbox-exec is macOS. The cause is the last clause, windows-acl-run: --temp is not an existing directory, buried at the end.

Cause

Section titled “Cause”

The Windows sandbox runner (windows-acl-run) uses one fixed, session-level temp directory under %TEMP%\dsh-XXXXXX. The reporter saw the same directory name, dsh-2hxmDi, across repeated failures, so the path is stable for the session rather than generated per command. Any Temp cleanup will delete it, nothing dsh-specific required, and the runner doesn’t recreate it. It reports that no sandbox backend is usable, and every sandboxed command after that fails until you step in.

Solution

Section titled “Solution”

Verified workaround: recreate the directory named in the error message, empty, with full access permissions:

Terminal window
New-Item -ItemType Directory -Path 'C:\Users\<user>\AppData\Local\Temp\dsh-2hxmDi' -Force

(Swap dsh-2hxmDi for whatever directory name your own error message reports.) The reporter confirmed the sandbox works again right away.

Longer term, don’t clear all of %TEMP% while a dsh session or server is running. It takes the sandbox’s working state with it.

The report proposes three upstream fixes. Have the runner mkdir its temp directory before use, or pick a fresh random name per command. Move the sandbox’s state directory out of %TEMP%, which is shared and routinely cleaned, to somewhere like $DSH_HOME. And have the error name the missing path instead of suggesting tools that don’t exist on the platform. None had landed as of this report.

Section titled “Related issues in the same report”

The same Discussion bundles four more Windows-specific issues from the same environment sweep. All are lower severity than the Temp-cleanup crash above, and all are worth knowing if you depend on dsh’s sandbox on Windows. The P0–P2 labels are the reporter’s own, not a DeepSeek classification.

P2 PowerShell’s -ErrorAction SilentlyContinue swallows the sandbox’s own [sandbox: file access denied ...] diagnostic marker along with everything else, leaving a generic exit code that looks identical to an OS ACL denial.

P1 The Windows restricted token blocks read-only WMI/CIM queries (Get-Volume, Get-NetTCPConnection, Get-PSDrive). Disk space and port-listener information can’t be read from inside the sandbox.

P1 UAC elevation (Start-Process -Verb RunAs) fails silently inside the sandbox. No prompt, no error, and the target command doesn’t run.

P2 Every sandboxed PowerShell command prints two Only core types are supported in this language mode errors to stderr, because the executor’s own init boilerplate uses constructs that PowerShell’s Constrained Language Mode blocks.

See the full guide: Running dsh on Windows.

Source

Section titled “Source”

Discussion #758 — Windows sandbox (workspace-write): permanent crash after Temp cleanup (P0) + 4 related issues

Section titled “Related errors”