[BUG] Cowork: virtiofs mount cache not invalidated on Windows host file saves — BadZipFile on Excel save (ref #42520)

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?

A file saved by any Windows application should be readable from the Cowork sandbox. At minimum a re-open of the file handle should bypass stale cache. Ideal fix: change virtiofs mount to cache=none or disable FUSE_CAP_WRITEBACK_CACHE so reads go direct to host. Alternatively expose a user or agent-accessible cache-drop mechanism scoped to a single file.

What Should Happen?

zipfile.BadZipFile: File is not a zip file

Raised by openpyxl when attempting load_workbook() on the mount path after Excel saves.
No error from stat or ls — the file appears present with correct size/mtime. Silent failure.

Error Messages/Logs

1. Open Cowork with any local Windows folder as workspace (e.g. `C:\dev\career_system\`)
2. Confirm an xlsx file is readable from the sandbox:
   
   python3 -c "import zipfile; print(zipfile.ZipFile('/sessions/.../mnt/career_system/file.xlsx').namelist())"
   
   This succeeds.
3. Open `file.xlsx` in Microsoft Excel on Windows. Make any change. Save. Close Excel.
4. Run the same command from step 2.
   **Observed:** `BadZipFile: File is not a zip file`
   **Expected:** file readable, returns list of ZIP entries
5. Upload the same file via Cowork's upload interface and read from `/uploads/` path — succeeds.

Confirmed: the issue is the virtiofs/FUSE cache. The file is valid on Windows disk; only the VM cache is wrong.

Steps to Reproduce

Related/duplicate of: #42520 (locked), #38993, #45433.

The practical impact: any Cowork workflow involving files edited in Excel, Word, VS Code, or any other Windows application silently operates on stale data. For xlsx files the stale cache breaks the ZIP structure entirely, making the file completely unreadable until the user manually re-uploads via the Cowork interface.

Platform: Windows 11. Folder mounted via virtiofs at /sessions/.../mnt/. Tested with Microsoft Excel 365.

Claude Model

Sonnet (default)

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

Latest (Cowork mode - not claude CLI)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Workaround currently in use: re-upload the file via the Cowork interface after each Windows-side save. This forces a new inode into the mount and the sandbox reads clean data.

posix_fadvise(POSIX_FADV_DONTNEED) was tested as a non-root cache eviction method - returns success but has no effect on virtiofs (the stale cache is below the Linux page-cache layer).

This affects any file type edited by any Windows application, not just xlsx. xlsx surfaces it most clearly because openpyxl validates ZIP structure on open.