[BUG] Silent Edit-tool truncation on multi-region edits (Cowork mode / Windows)
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?
I asked Claude to explain what is happening, I have attached its reply to this issue in teh EDIT_TRUNCATION_BUG_REPORT.md file
EDIT_TRUNCATION_evidence_users.truncated.py
EDIT_TRUNCATION_evidence_common.truncated.py
attachments/files/27739912/EDIT_TRUNCATION_BUG_REPORT.md)
What Should Happen?
Claude should be able to read and update code it only has touched without having to rebuild the files each time
Error Messages/Logs
Found it. The file is truncated — my last edit to _render_html_body clipped everything after it, including the _group_by_environment definition. The bash view sees a syntax-broken file (320 lines, ends mid-statement). The earlier smoke test was running stale .pyc (which is why it kept showing the pre-grouping format — that bytecode predates all my recent edits).
Let me check the actual file state from both views and rewrite the file cleanly using a heredoc per the workflow note.Ran a commandRan a commandThe Edit-truncation issue from my memory has bitten me — Edit operations clipped the file at line 320, mid-statement. The smoke tests were running stale .pyc cached from before the truncation, which is why they kept showing the pre-grouping format despite Edit reporting success. Time to switch to the heredoc workflow my memory note prescribes for exactly this case, and clear the cache.
Steps to Reproduce
I am getting it to develop a python app. It is reporting the truncation issues as it works
From Claude:
Is the truncation issue reproducable?
Claude responded: Honestly: not in any deterministic, "do these three things and watch it break" sense — at least not yet.
Honestly: not in any deterministic, "do these three things and watch it break" sense — at least not yet. Here's what we actually have:
Evidence the bug exists. Multiple occurrences across two sessions (2026-05-11/12 and today 2026-05-14), three different files, both Windows path-with-spaces and Windows path-without-spaces, file sizes roughly in the 5–25 KB range.
Evidence we lack. A recipe that fails the same way every time on demand. Today the failure was Edit #1 of three on email_gen.py (~3.5 KB new_string). The earlier sessions failed on different files at different sizes. I haven't tested whether that exact Edit call re-fails if rerun on a fresh file, or whether the size threshold is consistent.
If having a deterministic repro would help the Claude developers (which it probably would), I can run some controlled experiments right now: take a clean throwaway file, make a series of Edit calls of escalating new_string size, verify the on-disk state with bash after each one, and try to bracket the size at which truncation kicks in. Variables worth varying — new_string size, anchor position (top vs. middle vs. bottom of file), whether the file already has cached .pyc siblings, several Edits in sequence vs. one big Edit.
It'll generate a lot of tool calls and the outcome is uncertain (might still not repro every time), but it's exactly the kind of data the bug report needs. Want me to do that? If yes, where should I put the throwaway file — somewhere under the project, or in the outputs/scratch folder?
Claude Model
Opus
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
2.1.138
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Windows Terminal
Additional Information
Claude reports:
The CLI in the sandbox reports 2.1.138 (Claude Code). That's the Claude Code CLI installed in the bash sandbox — but worth flagging that's not actually what you're talking to. You're in Cowork mode in the Claude desktop app, with me (Claude) as the assistant. The underlying model is Claude Opus 4.7. The Claude Code CLI just happens to be available in the sandbox for running shell commands.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗