[BUG] Cowork Windows: Files previously written by Cowork are truncated on subsequent reads (stale FUSE metadata cache)

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?

When Cowork writes/modifies a file in a mounted folder, then the user subsequently modifies the same file outside the VM (e.g., in Excel), future Cowork sessions read a truncated version of the file. The VM returns fewer bytes than the actual file size on Windows.

Tested with 3 xlsx files in the same mounted folder:

| File | Windows actual size | VM reads | % received |
|------|-------------------|----------|------------|
| file_A.xlsx | 88 KB (89,997 bytes) | 60,778 bytes | 67% |
| file_B.xlsx | 75 KB | 61,911 bytes | 81% |
| file_C.xlsx | 34 KB | 18,538 bytes | 53% |

Key observations:

• Only affects files previously written by Cowork then modified externally — files never touched by Cowork (including a 924 KB xlsx in the same mount) read perfectly
• Non-xlsx files in the same folder are NOT affected — a 514 KB HTML file reads at 100%
• Copying the file (new inode) in Windows Explorer → reads correctly at full size
• Cache is keyed by filename: deleting the truncated file, then renaming a working copy to the original filename → truncated again at the same stale size
• os.path.getsize() returns the truncated size, not the real size
• Renaming the parent folder does not help
• No applications have the files open (verified via Task Manager)
• Files are on local NTFS (not OneDrive)
• fusermount -u and echo 3 > /proc/sys/vm/drop_caches both return "Operation not permitted" inside the VM — no way to invalidate cache within a session

Probable cause: The Cowork file bridge (VirtioFS/WinFsp FUSE layer) caches file metadata (including file size) after a write. When the file is subsequently modified on the Windows host, the cached metadata is not invalidated. Future sessions inherit the stale cache entry. The cache is keyed by filename (path), not by inode.

What Should Happen?

Cowork should read the current, complete file contents regardless of whether the file was previously modified by a prior Cowork session.

Error Messages/Logs

No error messages — the file reads silently succeed but return truncated data. The only way to detect the issue is comparing `os.path.getsize()` in the VM vs actual file size on Windows, or checking for missing ZIP end-of-central-directory records in xlsx files.

Steps to Reproduce

1. Start a Cowork session, mount a folder containing an .xlsx file (e.g., 50 KB)
2. Have Cowork modify the xlsx file (e.g., via zipfile + XML manipulation, or openpyxl)
3. End the session
4. Open the same file in Excel on Windows, add data, save — file grows (e.g., to 88 KB)
5. Start a new Cowork session, mount the same folder
6. Run in the VM:

import os
path = "/sessions/.../mnt/your-folder/your-file.xlsx"
print(os.path.getsize(path))  # Shows old size (50 KB), not current size (88 KB)
with open(path, "rb") as f:
    data = f.read()
print(len(data))  # Also old size — file is truncated

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

N/A — this is a Cowork (Claude Desktop) issue, not Claude Code CLI

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Current workaround:

1. Copy the file with a new filename in Windows Explorer (Ctrl+C, Ctrl+V), then read the copy. Note: renaming the copy back to the original filename re-triggers the stale cache.
2. Run a PowerShell script before starting Cowork that refreshes all xlsx files (copy → delete original → rename copy).
3. Start a new Cowork session (fresh VM = fresh cache — not yet verified if this fully resolves it).