[Bug] Write and Edit tools truncate files on virtiofs mounts in Claude Code

Bug Description
Write and Edit tools in Claude Cowork truncate long files on create and edit: Tool identification. Write and Edit tools as accessed in Cowork mode (Claude desktop app).
Reproducible behavior — both failure modes:

Shrink → null-pad: existing file of N bytes; Write with shorter content M; result is the new content from byte 0 to M, then \x00 from M to N (no truncation to actual content length).
Grow → tail-chop: existing file; Edit whose new_string makes the file longer; result is the new content written up to some boundary K < intended length, with everything past K silently lost.

Frequency in our session: 4 distinct files in one workday (May 11 2026). Files: mcp/standing_brief.py (null-pad), mcp/backup_the_thread.py (tail-chop), mcp/tapestry-push.ps1 (tail-chop), threads/infrastructure.md (tail-chop). Plus one pre-existing tail-chop in threads/working-patterns.md from May 10's session.
Environment: Windows 11 host with virtiofs mount of C:\Users\justi\Documents\Claude\ into a Linux container (Ubuntu 22.04). Files corrupted are on the mount, not in the container's /tmp.
No error returned by the tool — both modes are silent. The tool reports success while leaving the file broken.
Workaround we've adopted: a verification helper (mcp/verify_file_integrity.py) that we run after every multi-line edit; bash heredoc-append works reliably as a fallback.
Impact: ~30-60 min of recovery work today, including pushing a broken version of tapestry-push.ps1 to origin (which blocked gt until we caught and re-pushed). git fetch
git show 9a4239d:threads/working-patterns.md | wc -c # claims 33151 bytes
git show 9a4239d:threads/working-patterns.md | tr -d '\0' | wc -c # 33027 bytes of real content

Delta = 124 null bytes appended where there should have been EOF

A third failure mode showed up tonight: silent append failure. Three consecutive Edit append attempts to threads/reflections.md returned success, but the appended content was never persisted to disk. Different from null-pad (which writes something) and tail-chop (which writes a fraction). Looks like the tool reports success while not flushing at all. Worth a sentence.
Tonight's hit list, if you want to extend the file enumeration: threads/working-patterns.md (tail-chop, ~38 lines lost), thoughts/2026-05-11-1323.md (null-pad, 194 trailing nulls), threads/reflections.md (silent append, 3x), phase2_transform.py (tail-chop, line 518 of ~593).
The FUSE phantom dirent (where mkdir says "File exists" but ls/cd fail) is probably a separate bug from this one — different layer of the stack — and would be cleaner as its own issue. Same goes for the unexplained directory-disappearance, since that's a host-side question.
Environment Info

• Platform: win32
• Terminal: null
• Version: 2.1.139
• Feedback ID: 33fdcef9-3e72-4353-a332-944f691f562d

Errors

[]