windows-acl sandbox: cached private temp dir is never re-validated — one external delete permanently bricks the sandbox mid-session

[UncleBright]

Environment

• @deepseek-ai/dsh 0.1.5-rc.1
• @deepseek-ai/dsh-sandbox-local 0.1.5-rc.2
• @deepseek-ai/dsh-sandbox-windows-acl 0.1.5-rc.2
• Windows 11 (10.0.26200), Node v24.13.0, npm 11.16.0
• Sandbox mode: workspace-write

Summary

dsh-sandbox-local creates one private temp dir per [sessionId, workspaceRoot] and caches it.
On a cache hit it returns the cached path without checking that the directory still exists.
dsh-sandbox-windows-acl's runner requires --temp to exist, so once that directory is deleted
by anything outside DSH, every subsequent command in the session fails — and the session
never recovers on its own.

Symptom

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\AppData\Local\Temp\dsh-XXXXXX

The identical error (same dir name) recurs for every later command until the
session/provider is recreated.

Root cause

packages/sandbox/sandbox-local/lib/index.js (materializeAclGrant):

const key = JSON.stringify([String(sessionId), workspaceRoot]);
const existing = this.tempCapabilities.get(key);
if (existing !== void 0) return existing;      // <-- no existsSync() check
const tempDir = mkdtempSync(join(tmpdir(), "dsh-"));
...
this.tempCapabilities.set(key, capability);

packages/sandbox/windows-acl/lib/runner.js:

function requireDirectory(label, path) {
  if (!existsSync(path) || !statSync(path).isDirectory())
    fail(`${label} is not an existing directory: ${path}`);
}
...
requireDirectory("--temp", parsed.temp);

existsSync is already imported in index.js (used elsewhere), so the check is simply missing here.

Minimal reproduction (fully reversible)
Start a workspace-write session and run any command → materializes %TEMP%\dsh-XXXXXX.
Run a second command → no new dir appears, confirming the path is cached and reused.
Move that directory away from outside DSH.
Run any command → the exact error above; it recurs for every later command with the same path.
Move the directory back → the sandbox works again immediately.
Steps 3–4 reproduced the error verbatim; step 5 restored it. No DSH state was harmed.

Real-world trigger (why this is not exotic)
On Windows the built-in scheduled task \Microsoft\Windows\DiskCleanup\SilentCleanup runs cleanmgr.exe /autocleanstoragesense /d %systemdrive% when the machine is idle and wipes %TEMP%, deleting the private temp dir behind DSH's back. Observed sequence: the task last ran at 10:07:30; every command after that failed with the error above; a new session created a fresh dir and worked normally.

Impact
A single external temp cleanup silently and permanently disables the sandbox for the rest of the session, forcing the user to fall back to danger-full-access. On Windows this is default OS behaviour, not an edge case.

Suggested fix
Re-validate on cache hit and re-materialize when stale:

const existing = this.tempCapabilities.get(key);
if (existing !== void 0) {
  if (existsSync(existing.dir)) return existing;
  // stale: revoke the old grant, drop the cache entry, then re-create below
  try { existing.grant.dispose(); } catch { /* re-creation below supersedes */ }
  this.tempCapabilities.delete(key);
}

Consider also logging a warning when re-materializing so the cause is visible.

Still present in alpha
Checked @deepseek-ai/dsh-sandbox-local@0.1.6-alpha.1 by unpacking the npm tarball — the cache-hit line is unchanged (if (existing !== void 0) return existing;). Not fixed as of that version.


---