[BUG] Silent data loss: Cowork Edit/Write tools truncate long non-ASCII content; Read tool serves stale cache that hides it
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?
TITLE: Cowork Edit/Write tools silently truncate long / non-ASCII content; Read tool returns stale cached content past the truncation point
SEVERITY: High — causes silent data loss with no in-band error signal. Affects file
edits in user-mounted workspace folders and the auto-memory directory.
SUMMARY
The Write and Edit tools on Cowork (macOS / Windows, Claude Sonnet 4.6 model)
silently truncate file content above a threshold (~2900 bytes on the auto-memory
mount; varies on user workspace mounts) when the payload contains non-ASCII
characters (em-dashes, section signs, box-drawing, check marks, etc.). The tools
report "updated successfully" with no error. The Read tool then returns the
intended (pre-write) content from cache, masking the corruption until the user
verifies via bash wc -l / tail / xxd.
This is two compounding bugs:
- Write/Edit IPC layer drops bytes past a buffer threshold.
- Read tool serves stale cache, defeating verification by reading back.
WHAT WORKS (proves the underlying FS is fine)
• Python open(path, 'w', encoding='utf-8') invoked via the bash tool
writes the same payload correctly to the same paths.
• cp /tmp/staged.txt <mount_path> via bash writes correctly.
→ The bug is in the tool-side IPC, not the user's filesystem or mount.
ENVIRONMENT
• Claude Cowork (research preview), Windows 11 host
• Mounted folder: C:\Users\Jeff\Documents\Claude\Projects\Hack Tools\
• Auto-memory mount: standard session memory dir
• Sandbox bash path: /sessions/great-nifty-cerf/mnt/...
• Date: 2026-05-11
WORKAROUND IN USE
Built safe_write.py / safe_edit.py helpers that write via Python with
SHA256 round-trip verification, bypassing the broken IPC. Effective but
brittle (requires Claude to remember to use them). Real fix needs to land
in the Cowork tool runtime.
REQUEST
- Fix the Write/Edit truncation in the tool IPC layer.
- Fix the Read tool cache to invalidate after any write to the same path.
- (Bonus) Make Write return an error when on-disk SHA differs from
intended content, so the failure is loud instead of silent.
What Should Happen?
Files should be written in their entirety and not truncated.
Error Messages/Logs
EVIDENCE FROM THIS SESSION
• Auto-memory file (.../feedback_truncation_workarounds.md) written via
Write tool with intended size 4697 bytes. On-disk: 2914 bytes total,
of which the last 911 are NUL pad. Real content ended at byte 2003
mid-sentence ("PowerShell scripts mus").
• Same file rewritten shorter (intended 2913 bytes): on-disk 2914 bytes,
last 911 NUL, real content 2003 bytes — same boundary regardless of
intended size, suggesting fixed-size IPC buffer.
• User's Hack Tools/CLAUDE.md was found on disk truncated at 140 lines
(intended 269), ending mid-word at "kept-alive volumes for non".
The Read tool returned the full 269-line content from cache; only
bash wc -l revealed the actual on-disk state.
Steps to Reproduce
REPRO (~ 2 minutes)
- Open Cowork with a workspace folder mounted from a Windows or macOS
Documents subdirectory.
- Ask Claude to use the Write tool to create a file ~4 KB in size that
contains em-dashes ("—"), section signs ("§"), or box-drawing
characters in the body.
- After Write reports success, ask Claude to run bash:
wc -c <path>
tail -c 200 <path> | xxd
- Observe: byte count is ~2914 (or some mount-dependent threshold).
The last ~900+ bytes of the file are NUL (0x00). Real content ended
mid-word well before the NUL padding began.
- If you ask Claude to Read the file again, Read returns the *original
intended* content, not what's actually on disk.
Claude Model
Opus
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
2.1.128
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
PowerShell
Additional Information
_No response_
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗