[Bug Report] Windows: sandbox permanently fails after Storage Sense deletes the session's private temp directory

[Chen-Zz1]

[Bug Report] Windows: sandbox permanently fails after Storage Sense deletes the session's private temp directory

TL;DR

On Windows, a low-disk-space Storage Sense cleanup can delete the sandbox provider's private %TEMP%\dsh-* directory while the dsh server is still running. After that, every confined command fails with windows-acl-run: --temp is not an existing directory until the server is restarted — because the provider caches the temp path per session and never re-validates it on cache hits.

---

Environment

• Package: @deepseek-ai/dsh v0.1.0-rc.6 (running via npx @deepseek-ai/dsh web)

• OS: Windows 10 Pro (22H2, build 19045); the mechanism should be OS-version independent

• Sandbox mode: workspace-write (session default)

• C: drive free space at diagnosis time: ~6.7 GB (low-space condition)

Symptoms

Every pwsh execution fails with:

Error: sandbox mode "workspace-write" is requested but no sandbox backend is
usable on this host; refusing to run the command unconfined. ...
Runner failure: windows-acl-run: --temp is not an existing directory:
C:\Users\<user>\AppData\Local\Temp\dsh-au2XNB

The reported path is the session's private temp directory that the provider itself created earlier in the same server lifetime — it no longer exists on disk. Read/write/edit file tools keep working; only confined command execution breaks.

Root cause

In dsh-sandbox-local (packages/sandbox/sandbox-local), materializeAclGrant(sessionId, workspaceRoot) caches the private temp capability per [sessionId, workspaceRoot] key:

const key = JSON.stringify([String(sessionId), workspaceRoot]);const existing = this.tempCapabilities.get(key);if (existing !== void 0) return existing;   // ← returns stale path, no existence checkconst tempDir = mkdtempSync(join(tmpdir(), "dsh-"));

The cache-hit path performs no existence check, so once anything external deletes the directory, the provider keeps handing the stale path to the ACL runner, which fail-closes on startup (requireDirectory("--temp", …) → exit 127). The README documents OS temp hygiene reclaiming crash residue, but the same hygiene can also reclaim the live directory of a running provider — a case the design doesn't cover.

How I traced the trigger (evidence from the affected machine)

The session was only ~20 hours old, so the "files older than N days" rule could not apply (session artifacts are timestamped 00:31–00:56 the same day). The actual trigger was the low-disk-space immediate cleanup by Windows Storage Sense:

Evidence | Value -- | -- Free space on C: | ~6.7 GB Storage Sense enabled | HKCU\...\StorageSense\Parameters\StoragePolicy 01 = 1 StoragePoliciesLastTrigger (FILETIME decoded) | same day 20:50:34 local — shortly before the failures appeared (first diagnosed at 21:41) StoragePoliciesLastFailure (FILETIME decoded) | 20:50:44 local — Storage Sense recorded a failure 10 s after the trigger (consistent with, but not proof of, a deletion failure on locked/ACL-protected files) Session temp dir dsh-au2XNB | gone from %TEMP% by diagnosis time; session artifacts are timestamped 00:31 (spill dir) and 00:56 (ACL locks) Survivors | dsh-acl-locks, dsh-spill-* still present

So: low disk space → Storage Sense immediate cleanup → private temp dir deleted → cached path goes stale → permanent fail-closed sandbox for the session.

Impact / why this matters

This is likely a fairly common Windows scenario:

1. dsh web server keeps running (normal usage), and

2. Storage Sense fires — routinely triggered by low disk space, which is very common on Windows laptops.

The session is then permanently broken for confined commands until restart. Fail-closed is the correct runner behavior; the bug is the provider trusting a cached path forever.

Suggested fix

Re-validate on cache hit and re-materialize transparently:

const existing = this.tempCapabilities.get(key);if (existing !== void 0) {  if (existsSync(existing.dir) && statSync(existing.dir).isDirectory()) {    return existing;  }  // External cleanup (Storage Sense / disk hygiene) deleted our private temp  // dir. Best-effort revoke the stale grant, drop the entry, and fall through  // to materialize a fresh directory + SID below.  try { existing.grant.dispose(); } catch { /* log */ }  this.tempCapabilities.delete(key);}

This extends the documented design philosophy ("a fresh provider always chooses a new path; residue is inert") to mid-lifetime invalidation.

Workaround for affected users

• Restart the dsh server (new provider creates a fresh temp dir).

• Stop Storage Sense from deleting Temp: Settings → System → Storage → Storage Sense → disable automatic temp-file cleanup, or free up space.

• Stop-gap: run affected commands with danger-full-access (unconfined).

---

Thanks for the great work on the harness — happy to provide more logs or test a patch if you have a preferred fix direction.

[Electricitysheep]

Storage Sense 删掉沙箱私有临时目录 → 沙箱永久失败——这和第 12 章记录的"Windows 沙箱临时目录清理后崩溃"（#758 同族）是同一根因。临时 workaround：把 dsh 的临时目录排除出 Storage Sense 清理范围，或重置沙箱状态。

第 12 章 Windows 速查表 + 第 13 章沙箱机制：https://github.com/Electricitysheep/dsh-handbook/blob/main/docs/12-limitations.md