[BUG] Cowork (Windows): sandbox mount serves a truncated/stale copy of a file after the user saves it (non-OneDrive local folder)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

On Windows, when a connected folder is a plain local C:\Users\<user>\Documents\... folder (no OneDrive, no cloud sync, no Files-On-Demand), the Cowork sandbox mount (/sessions/<id>/mnt/...) keeps serving a truncated/stale copy of a file after the user edits and saves it (e.g., in Excel). The stale copy is served to all sandbox access paths — bash, Read, and Grep alike — with no error until the file is parsed.

For .xlsx this surfaces as zipfile.BadZipFile: File is not a zip file: the bytes end mid central-directory with no End-Of-Central-Directory (EOCD) record, i.e. the tail of the file is missing.

A second, unedited file in the same folder reads fine at the same moment, so the staleness is per-file (per-inode), not a whole-mount outage. The file read correctly at the start of the session; after the user saved it, every subsequent read returned the stale truncated bytes. A partial close of the desktop app did not clear it — only a full quit-and-relaunch (fresh mount) did, and the next save reproduced it.

⚠️ Data-loss risk: if the agent writes/Edits the file while the mount serves the truncated copy, it overwrites the user's good file with the truncated version. (Same loss pattern as #62140, but here with no cloud sync involved.)

What Should Happen?

Reads from the connected folder should reflect the current on-disk content. After the host process (e.g. Excel) saves a file, the sandbox mount should serve the complete, up-to-date bytes — not a cached truncated snapshot — and should never silently return a partial file.

Error Messages/Logs

zipfile.BadZipFile: File is not a zip file   # opening the saved .xlsx via openpyxl in the sandbox

Byte analysis of the served (truncated) copy: header PK\x03\x04 present; local + central-directory headers present but PK\x05\x06 (EOCD) ABSENT; file ends mid central-directory. Definitively truncated, not byte-corrupted.

stat on the served file showed a non-zero Blocks consistent with the (smaller) Size — i.e. NOT the OneDrive "Blocks: 0" placeholder signature from #62140; this is a genuine stale/partial snapshot served by the mount.

Steps to Reproduce

1. On Windows, connect a plain local Documents folder (no OneDrive / no cloud sync) to a Cowork session.
2. Have the agent read an .xlsx from it successfully (full content parses).
3. In Windows, open that file in Excel, make a change, Save, and close Excel.
4. Have the agent read the same file again (via bash, Read, or Grep).
5. Result: the mount returns a stale, truncated copy (size capped, tail missing). openpyxl/zipfile fail with BadZipFile; all access paths see the same stale bytes. In-sandbox cache-busting (cp, re-listing the directory, find, echo 3 > /proc/sys/vm/drop_caches) does not help. A full quit-and-relaunch of the desktop app clears it — until the next save reproduces it.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude desktop app — Cowork (research preview). Not the CLI, so claude --version is N/A. Reproduced June 2026 on Windows.

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Same class of bug as several existing reports — filing a clean non-OneDrive, plain-local-folder repro because most existing reports assume OneDrive Files-On-Demand, which is NOT the trigger here.

Related (please consolidate):

• #38993 — virtiofs FUSE mount serves truncated/stale files
• #40264 — Windows: files truncated on subsequent reads (stale FUSE metadata cache)
• #41710 — sandbox silently reads truncated/stale file content from mounted folder
• #45433 — mount serves stale content and metadata
• #40191 — VM connector serves stale/truncated file snapshots
• #62140 — same data-loss pattern, but OneDrive Files-On-Demand specific

Suggested fixes:

1. Invalidate the FUSE attribute/content cache on host file change (inotify/USN journal), or use a short attr/entry timeout for connected folders.
2. Validate length/checksum at the mount bridge before serving; surface a "stale, re-syncing" state instead of silently serving a partial snapshot.
3. Guard writes: refuse to overwrite a file whose on-mount size is dramatically smaller than last seen without explicit confirmation (prevents the data-loss path).
4. Expose a resync/drop-cache mechanism the Read tool can call before critical reads.