DeepSeek Harness ACL sandbox grants do nothing on exFAT

On an exFAT or FAT32 workspace the DeepSeek Harness ACL sandbox grant returns success, but the volume stores no DACL, so the restricted child can still write to the workspace; the same class of volume also degrades the "file changed" token to size plus a two-second mtime. Neither failure raises an error: the first is a broken security boundary, the second a data-integrity gap, and no DSH plugin setting changes either. According to the discussion, the reporter measured this on Windows with an exFAT workspace, and community members then reviewed the sandbox-windows-acl and session-persistence-jsonl sources line by line (discussion).

What "grant succeeded, zero effect" looks like in DeepSeek Harness

Bottom line: the grant does not error, tool calls are not rejected, and workspace files remain writable — all three at once. Confirm them in this order rather than changing configuration first:

1. In PowerShell run Get-Volume -DriveLetter E | Select-Object DriveLetter,FileSystem. Expected: exFAT or FAT32; if it says NTFS, neither failure in this article applies.
2. Determine whether the workspace root is the volume root or a subdirectory: (Get-Item E:\proj).FullName. According to the discussion, the package README says two different things about "the grant root itself is a FAT volume" and "FAT targets outside the granted roots", so scope the conclusion to the actual level.
3. Have the agent create a file in the workspace, then modify it from another process. Expected: neither action is blocked.
4. Run icacls E:\proj once, trigger a grant, then run it again. Expected: the two outputs are identical — no ACE was added, which means the grant never reached the volume (community source review).

exFAT writes can also fail in a different shape, as EISDIR or a drive-root EPERM mkdir; see exFAT EISDIR write errors. A control on the same machine with an NTFS directory makes the difference obvious:

Why the grant does not fail: it only handles Win32 errors, it never probes the volume

Bottom line: the fail-closed logic in grant.ts covers only "a Win32 call returned an error", while on exFAT SetNamedSecurityInfoW returns ERROR_SUCCESS — so throwLastError and AggregateError have nothing to fire on.

1. packages/sandbox/sandbox-windows-acl/README.md:190 states that a FAT volume as a grant root "fails loudly".
2. Line :204 of the same README states that a warn-only posture for FAT-class volumes is recorded but not implemented. The two statements contradict each other.
3. grant.ts contains no GetVolumeInformation and no volume capability probe; the implementation equates "the call succeeded" with "the DACL was written".
4. exFAT has no security descriptor storage, so the call neither errors nor saves, and the restricted token receives no restriction. The probe the README promises simply does not exist, which also fixes the repair direction: add it rather than guess after a write fails.

Why the version token misses external edits: only two of five parts survive

Bottom line: the physical revision is dev:ino:size:mtimeNs:ctimeNs, and on a volume with two-second timestamps, a volume-constant ctime and recyclable inodes, only size and two-second mtime still discriminate.

1. Put a test file in the workspace, record its size, and let DSH read it once.
2. Within the same two-second window, rewrite it from another tool with content of the same size. Expected: the nanosecond part of mtimeNs is zero and the second-level timestamp is unchanged.
3. Return to DSH and edit the same file. Expected: no "file changed externally" interception, and your change overwrites the other one.
4. Repeat with different-size content. Expected: this time the guard fires, which proves the guard is fine and its resolution is the problem.

Backup restores, sync clients and antivirus rewrites can all pass silently on a two-second-granularity volume.

Fix 1: probe FILE_PERSISTENT_ACLS before the DeepSeek Harness grant

Bottom line: the cheapest repair is one capability probe at the grant entry point, turning "unsupported" into an explicit error at adoption time instead of a silent pass at runtime.

1. At the grant entry point, call GetVolumeInformationW for the grant root and read the returned filesystem flags.
2. Check whether FILE_PERSISTENT_ACLS (0x00000008) is set.
3. When it is clear, take the same failure path as throwLastError, with a message that names the volume path and says persistent ACLs are unsupported.
4. An illustrative change (not the repository's original code):

const flags = volumeFlags(root) // output of GetVolumeInformationW
if ((flags & FILE_PERSISTENT_ACLS) === 0) {
  throw new Error(`ACL sandbox unsupported: ${root} does not preserve ACLs`)
}

5. Reopen the exFAT workspace. Expected: an error at adoption time. Repeat on NTFS. Expected: behaviour identical to before the change.

Fix 2: move the DeepSeek Harness workspace to an NTFS volume

Bottom line: if the workspace must keep write isolation, changing volumes is more thorough than patching — NTFS really stores DACLs, and the five-part token regains its resolution.

1. Run robocopy E:\proj C:\work\proj /E /COPY:DAT /R:1 /W:1. Expected: an exit code below 8.
2. Run Get-Volume -DriveLetter C | Select-Object FileSystem. Expected: NTFS.
3. Remove the old workspace in DSH and add C:\work\proj again.
4. Repeat the icacls comparison: new ACEs should appear across a grant. Then rerun the same-size rewrite test. Expected: this time the "file changed" interception fires.

Fix 3: disable the DeepSeek Harness ACL sandbox and make the workspace read-only

Bottom line: if you will neither change disks nor patch the host, admit the boundary does not exist and take write access away, instead of pretending the sandbox is active.

1. Disable the ACL sandbox row under Settings → Plugins, then restart. Expected: no further grant records in the log.
2. Point the workspace at a read-only source: a write-protected USB stick, a read-only share, or an NTFS directory with read-only permissions (icacls C:\ro /grant "%USERNAME%:(OI)(CI)(RX)").
3. Have the agent read once and write once, then record the condition for the team. Expected: the read succeeds, the write is denied at the filesystem layer by an error that does not come from the sandbox, and everyone knows write access was traded for the absence of a false sense of isolation.

Retest each DeepSeek Harness path and know the limits

Bottom line: the paths solve different problems — path one makes failure loud, path two restores real isolation, path three gives up write access.

1. Path 1: adoption fails on exFAT; icacls differs before and after a grant on NTFS; existing NTFS write flows are unaffected.
2. Path 2: a same-size external rewrite triggers interception; a restricted child cannot write to the workspace; session files no longer show silent overwrites.
3. Path 3: writes are denied at the filesystem layer; reads, directory listings and search still work; stop claiming the workspace is ACL-protected.

Limits

Bottom line: both failures are silent by default, so the only trustworthy evidence is a before-and-after comparison rather than the absence of errors.

1. A capability probe makes exFAT workspaces unusable with the ACL sandbox. That is the intended fail-closed outcome, not a regression.
2. The token degradation is independent of the sandbox; fixing one does not fix the other.
3. The locations and behaviour above come from community source review against the reporter's measurements; upstream has not fixed them, so re-confirm after an upgrade.

DeepSeek Harness FAQ

Bottom line: the remaining questions are about blast radius and about whether either failure can be worked around without changing disks.

Q: Does the same problem affect FAT32? A: Yes. FAT32 also lacks persistent ACL storage, so the grant behaves the same way.

Q: Is the version token failure limited to same-size edits? A: In practice, a different size changes the tuple and triggers interception. Same-size edits inside the two-second window are the reliable blind spot.

Q: Can I keep using exFAT and just accept the risk? A: You can, but then do not describe the workspace as sandboxed. The risk is not only writes by the agent; external rewrites also go undetected.