[BUG] Silent data loss: Cowork Edit/Write tools truncate long non-ASCII content; Read tool serves stale cache that hides it

Resolved 💬 2 comments Opened May 11, 2026 by tjscientist Closed Jun 10, 2026

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:

  1. Write/Edit IPC layer drops bytes past a buffer threshold.
  2. 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

  1. Fix the Write/Edit truncation in the tool IPC layer.
  2. Fix the Read tool cache to invalidate after any write to the same path.
  3. (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)

  1. Open Cowork with a workspace folder mounted from a Windows or macOS

Documents subdirectory.

  1. 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.

  1. After Write reports success, ask Claude to run bash:

wc -c <path>
tail -c 200 <path> | xxd

  1. 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.

  1. 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_

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗