[BUG] Cowork: virtiofs mount silently truncates large files on non-OneDrive Windows local folders

Description

Files larger than ~60KB on a Windows local folder (non-OneDrive, non-cloud-synced) are silently truncated when accessed through the Cowork mount (/sessions/.../mnt/...). The truncated content does not correspond to any previous version of the file. Reading the truncated content and writing it back via Cowork's Edit tool corrupts the Windows-side source file.

Environment

• OS: Windows 11 (23H2)
• Machine: Lenovo Legion 7 16IRX9
• Claude Desktop version: Latest as of 2026-04-03
• Folder location: C:\Users\<user>\Desktop\my-physis\ — local SSD, not OneDrive-synced, no cloud sync active (OneDrive process not running)

Steps to Reproduce

1. Open Cowork and mount a local Windows folder containing a JavaScript file (~70KB, 1384 lines)
2. Edit the file via PowerShell MCP (Windows-side) to increase its size
3. Read the file via Cowork's Read tool (/sessions/.../mnt/.../src/worker.js)
4. Observe the file is truncated (1342 lines, 64,628 bytes instead of 1384 lines, 70,056 bytes)
5. The truncation occurs mid-line with no trailing newline — a clean byte-level cut

Observed Behavior

| Metric | Windows (correct) | Cowork mount (truncated) |
|--------|-------------------|--------------------------|
| File size | 70,056 bytes | 64,628 bytes |
| Line count | 1,384 | 1,342 (last line incomplete) |
| Content | Complete | Truncated mid-expression: user.booking_js (should be user.booking_json) |

Key observations:

• Not a CRLF-LF issue: Other files in the same folder (admin.html 148KB, index.html 201KB) show CRLF-LF byte differences but have complete content (verified by checking </html> tag present)
• Not a cached old version: The truncated byte count (64,628) does not match any previous git commit of the file (checked 5 commits: 61,717 / 67,872 / 69,328 / 70,056 bytes)
• Reproducible: Occurred 3 times in a single Cowork session, always to the same file (worker.js)
• Small files unaffected: wrangler.toml (3,583 bytes) shows identical size on both sides

Data Corruption Risk

The most dangerous consequence: if a user reads the truncated file via Cowork's Read tool and then edits/writes it back, the Windows-side file gets permanently corrupted with the truncated content. Recovery requires git checkout from a clean commit. During the session where this was observed, this corruption-and-recovery cycle occurred 3 times before the pattern was identified.

Expected Behavior

Files on the Cowork mount should reflect the complete content of the Windows-side source file, regardless of file size.

Related Issues

• #41702 (OneDrive-backed workspaces silently truncate files on write) — same symptom but different root cause. Our case has no OneDrive involvement.
• #40231 (Copy to skills silently truncates existing files when file size increases) — similar truncation behavior

Workaround

Read and write large files via PowerShell MCP (mcp__windows-mcp__PowerShell) instead of Cowork's filesystem tools. Before using Cowork's Read/Edit on any file, compare wc -l (mount) with (Get-Content).Count (PowerShell). If they differ, do not use Cowork's tools for that file.