[BUG] Cowork (Windows): host Edit tool never updates file size on mounted folders - growing edits truncated at old EOF, shrinking edits leave NUL-padded tail (deterministic 4-case repro)

Summary

In Cowork mode on Windows, the host-side Edit tool never updates the file's byte length when writing to a user-mounted folder. New content is written over the old bytes, but the size/truncate metadata update is missing. This makes corruption deterministic, not random:

| Operation | Result |
|---|---|
| Write (create new file) | ✅ intact (ASCII and CJK both verified byte-exact) |
| Edit, replacement same byte length | ✅ intact (by coincidence) |
| Edit, replacement longer | ❌ file truncated at (approximately) the old byte length — tail silently lost, can cut mid-UTF-8 sequence |
| Edit, replacement shorter | ❌ file keeps the old length — tail padded with 0x00 NUL bytes |
| Writes from the Linux sandbox (bash) to the same mount | ✅ intact |

The Edit tool reports success in all cases, and subsequent Read calls serve the intended (cached) content, so the model does not notice the corruption (consistent with the stale-cache observation in #58023).

Environment

• Claude Desktop, Cowork mode (research preview), model claude-fable-5
• Windows 11 23H2 (build 10.0.22631), mounted folder on local NTFS drive D:\
• Repro date: 2026-07-11

Deterministic repro (byte-exact evidence)

1. Write a new file b.py in the mounted folder: 20 lines bNN = 1 # 中文注释中文注释 + print("END_B") → on-disk 735 bytes, byte-exact ✅
2. Single Edit replacing one line with an equal-length line → still 735 B, byte-exact ✅
3. Three Edit calls in one message, each replacing an 8-char CJK comment with a 9-char one (+3 bytes each, expected 744 B) → file stays 735 B; content is the new text but the tail print("END_B")\n loses its last 9 bytes ❌
4. Single Edit on a pure-ASCII 175 B file inserting ~10 lines (~500 B expected) → file ends up 177 B, cut mid-insertion (mid-UTF-8, leaving a partial lead byte) ❌ — so this is not CJK-specific, contrary to what #64597's title suggests
5. Single Edit replacing a line with a shorter one → file stays 735 B; correct new content followed by 19 × 0x00 ❌

Cases 3–5 reproduce 100% of the time on this machine. In a real session, 7 project files were corrupted this way in one working day (Python sources of a live trading dashboard; one file ended up with NUL bytes inside a running app directory).

Root cause (inferred from behavior)

The host file-sync layer that applies Edit results to the mounted folder writes the new bytes but never performs the size update / SetEndOfFile-equivalent truncate-or-extend. Hence: grow → tail cut at old EOF; shrink → old tail region left as NULs; equal length → accidental success. Write (new file) takes a different code path and is unaffected.

Related issues (all closed as stale/duplicate without a fix)

#64597, #58913, #58023, #52883 — same symptom family. This report narrows it to the missing length update and provides a 4-case deterministic matrix distinguishing grow/shrink/equal-length edits.

Impact

Silent data loss in user source files. Because Edit reports success and Read serves cached content, the corruption is typically discovered much later (e.g., at commit or runtime).

Workarounds we currently use

• Never use host Edit on mounted folders; rewrite files via the Linux sandbox (read → replace → write), which is reliable
• Host Write only for brand-new files
• A git pre-commit hook rejecting staged files containing NUL bytes / failing ast.parse / missing trailing newline

(Report prepared with Claude's assistance in the affected Cowork session, filed by the account owner.)