Bug report: Windows windows-acl sandbox dies permanently for a session when its cached private temp dir disappears

[Flen-Plnens]

Product: @deepseek-ai/dsh 0.1.5-rc.2 (npm next; latest at the time of writing is 0.1.5-rc.1)
Host: Windows 10, Node v24.19.0, x64
Backend: windows-acl (restricted-token runner) — the chain's sole win32 candidate
Severity: high for Windows users — a session loses all confined execution until the DSH process restarts

---

1. Symptom

Every confined workspace-write command in an affected session fails with:

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

(Structured error: name: "SandboxUnavailableError", code: "SANDBOX_UNAVAILABLE".)

Two things make this worse than it looks:

1. The backend is not missing. On the same host and the same DSH process, confined commands work
   normally — the ACL runner rewrites TMP/TEMP to a capability-granted private dir and enforces the
   workspace boundary. The error text is therefore misleading, and it invites the model to escalate to
   danger-full-access (which is exactly what happened in practice — see §4).
2. It never recovers for that session. Within one session, every failure names the same
   private temp dir, across 25 minutes. The session is confined-execution-dead until the DSH process
   restarts.

2. Root cause

@deepseek-ai/dsh-sandbox-local caches one private temp directory per (sessionId, workspaceRoot) for
the provider's lifetime and hands that path to the runner on every confined call — without ever
re-validating that the directory still exists:

// node_modules/@deepseek-ai/dsh-sandbox-local/lib/index.js (0.1.5-rc.2, lines ~400-403)
const key = JSON.stringify([String(sessionId), workspaceRoot]);
const existing = this.tempCapabilities.get(key);
if (existing !== void 0) return existing;            // <-- cached dead path is returned forever
const tempDir = mkdtempSync(join(tmpdir(), "dsh-"));

The runner then fails closed on its very first pre-flight check
(dsh-sandbox-windows-acl/lib/runner.js, requireDirectory → existsSync), prints
windows-acl-run: --temp is not an existing directory: … and exits 127, which
RUNNER_FAILURE_RULES["windows-acl"] maps to SandboxUnavailableError.

The deletion itself comes from DSH's own cleanup: in the whole installed tree the only code that removes
these directories is sandbox-local's removeTempDir(), called from

• revokeAclGrants() (provider dispose / cordis effect teardown), and
• the partial-grant-failure cleanup inside materializeAclGrant().

Once such a removal happens while the provider instance (and therefore its tempCapabilities map)
survives, the session is stuck. We could not pin down from the artifacts which of those two paths
fires first — that is the one open question; the "cache is never re-validated" half is proven by the
identical stale path being reused for 25 minutes.

3. Evidence

3.1 The backend works on this host (same process, minutes apart)

Current session, confined pwsh command:

$env:TEMP  ->  C:\Users\Admin\AppData\Local\Temp\dsh-OCWs63

> icacls C:\Users\Admin\AppData\Local\Temp\dsh-OCWs63
C:\Users\Admin\AppData\Local\Temp\dsh-OCWs63 S-1-4-679122723-976859111-1:(OI)(CI)(W,D,DC)   <- tempWriteSid()
                                             DESKTOP-SCIEJPJ\Admin:(I)(OI)(CI)(F)
                                             ...

S-1-4-x-y-1 is exactly tempWriteSid(privateTempDir) from
dsh-sandbox-windows-acl (tempWriteSid = S-1-4-<a>-<b>-1). Enforcement is live too:

Set-Content C:\Users\Admin\dsh-sandbox-probe.txt     -> Access to the path ... is denied.   (correct)
Set-Content C:\Users\Admin\.dsh\.sandbox-probe.txt   -> ok                                   (correct)

Roughly 40 confined commands in that session succeeded with zero runner failures.

3.2 Two affected sessions, months apart (so not a 0.1.5 regression)

Logs live at $DSH_HOME/sessions/<cwd-slug>/<session>/session.v3.jsonl.zstd. Note: they are
multi-frame zstd — zlib.zstdDecompressSync() (and the streaming API) decode only the first
frame, so a naive search finds nothing. Decoding all frames:

session	when (local, +08:00)	workspace	failures	distinct --temp in failures
session-ed1b02bb-c416-4967-97ef-a903b1c371c2	2026-09-13 09:46:49 → 10:12:01	D:\renpy-projects	6	1 — …\Temp\dsh-am0JWF
session-031541e1-92d1-411b-989c-97ca0f3a9ea2	2026-08-19 19:56:48 → 20:18:05	D:\GL2	4	1 — …\Temp\dsh-Xk3Q7D

In session-ed1b02bb, the last healthy confined command is at 09:42:05; from 09:46:49 on, no
confined workspace-write command ever succeeds again, and all 6 failures carry the same path.

3.3 The "it works again afterwards" is escalation, not recovery

The successful commands interleaved with the failures are unconfined — the model escalated, with the
user approving each time:

{"type":"approval/asked","seq":1249,"toolName":"pwsh",
 "reason":"escalate sandbox to danger-full-access: The workspace-write sandbox runner is unusable
           (its temp directory no longer exists), so this Ren'Py lint check cannot run any other way; …"}

(approval/asked with that reason appears repeatedly: seq 1249, 1405, 1441, 1501, 1508, 1515.)
So an affected session silently degrades to danger-full-access — the opposite of the intended
fail-closed outcome, and it makes agents report "the sandbox is broken" to the user.

3.4 Ruled out

• OS/cleanup-tool deletion of %TEMP%: Storage Sense is disabled
  (HKCU\…\StorageSense\Parameters\StoragePolicy\01 = 0, no policy keys), and unrelated temp files from
  08:45 are still present while the sandbox dirs vanished.
• Non-deterministic mkdtemp: fs.mkdtempSync() returns distinct random suffixes here
  (4/4 distinct); crypto.randomBytes is fine. So a constant stale path cannot be re-creation.
• ACL module deleting directories: no rmSync/rmdir anywhere in dsh-sandbox-windows-acl;
  dsh-acl-locks holds lock files only.

4. Suggested fix

Re-validate the cached capability before returning it (this is the local hotfix we are running, marked
[dsh-hotfix sandbox-local]):

const existing = this.tempCapabilities.get(key);
if (existing !== void 0) {
    if (existsSync(existing.dir)) return existing;
    try { existing.grant.dispose(); } catch {}
    this.tempCapabilities.delete(key);
}
const tempDir = mkdtempSync(join(tmpdir(), "dsh-"));

(existsSync is already imported in that module.) A missing directory is then simply re-materialized
with a fresh path/SID instead of poisoning the session.

Two secondary suggestions that would have shortened this diagnosis a lot:

1. Distinguish the two failure classes in the message. A runner-side pre-flight failure is not
   "no sandbox backend is usable on this host"; the current text tells the model to switch to
   danger-full-access, and models comply. Something like
   SANDBOX_RUNNER_FAILED (state: the backend exists but this invocation's confinement could not be
   established; retry/rebuild, do not escalate) would prevent both the misleading escalation and the
   "sandbox is broken" reports.
2. Say why existsSync failed. requireDirectory collapses ENOENT and EACCES/EPERM into one
   message (Node's existsSync returns false for any stat error). Reporting the actual statSync
   error code would separate "deleted" from "present but unreadable" in the field.

5. Environment / repro notes

• Reproduced twice on this host, in long-lived sessions that crossed several turn boundaries; the first
  failing command in a turn is the one that surfaces it.
• We could not construct a minimal deterministic reproducer: forcing it needs the private temp dir to
  disappear between materializeAclGrant() and the runner's existsSync (or the cached entry to
  outlive the directory). Deleting the session's private temp dir out-of-band and then issuing a
  confined command reproduces the identical error text, which is how the hotfix above was validated.

[PerryLink]

I verified your report against master (c291e79, 2026-09-10). It holds, line
for line, and it is still unfixed upstream.

Verified facts:

1. Cache never re-validated. packages/sandbox/sandbox-local/src/index.ts:412-414:
   const existing = this.tempCapabilities.get(key); if (existing !== undefined) return existing — no existsSync/statSync before
   returning the cached { dir, writeSid, grant }, so a deleted dir is re-served
   forever (this is the lib ~400-403 you quoted).
2. Runner fails on the first pre-flight check. packages/sandbox/sandbox-windows-acl/
   src/runner.ts:109-120: requireDirectory → existsSync/statSync →
   fail("<label> is not an existing directory: <path>"), with the --temp
   check at :120. Exactly the error text you captured.
3. Both deletion paths exist as you described: removeTempDir
   (sandbox-local/src/index.ts:479-483) is called from revokeAclGrants on
   provider dispose (:454-472) and from the partial-grant-failure cleanup (:431).
4. The error class is real: SandboxUnavailableError / SANDBOX_UNAVAILABLE
   (packages/sandbox/sandbox/src/index.ts:124-142); sandbox-local throws it when
   the runner chain is unusable (sandbox-local/src/index.ts:494). So the message
   "no sandbox backend is usable on this host" is precisely what a
   runner-side pre-flight failure gets flattened into — misleading, as you said.

Status and workaround:

• Not fixed on master. Your re-validate-before-return hotfix is the right shape
  for an upstream patch; this discussion is the best place for it.
• Until then: restart the DSH process — a fresh provider rematerializes a new
  temp dir/SID and the session recovers. Within an already-poisoned session,
  confined workspace-write cannot recover, so stop approving the
  danger-full-access escalations there (the "it works again" runs you saw were
  unconfined, as you noted).
• Your two secondary suggestions (separate SANDBOX_RUNNER_FAILED from
  backend-missing in the message; report the real statSync errno instead of
  collapsing ENOENT/EACCES in requireDirectory) are both sound — worth restating
  in a fix-proposal comment for the maintainers.