File Editing Failure: String Replacement Error After Recent Update
Resolved 💬 17 comments Opened Mar 6, 2025 by sithamet Closed May 7, 2025
💡 Likely answer: A maintainer (bcherny, collaborator)
responded on this thread — see the highlighted reply below.
Bug Description
After recent update or two, Claude started failing to edit files with " String to replace not found in file." error. He gets very confused and tries reading the file using console, and then re-applying, but more often than not, it fails.
Environment Info
- Platform: macos
- Terminal: cursor
- Version: 0.2.32
- Feedback ID: 4df378b3-65cd-4f67-a0b1-0a8649f5b4de
17 Comments
I've noticed this too. When attempting to add test cases to an existing file it fails to find a string to replace and attempts to add a new file instead. I even tried giving it a comment to replace with the new code and while Claude said it saw the comment; it was unable to replace it. This started happening after I updated yesterday evening.
I asked claude for advice and I am going to put this as readme and include with future code editing prompts "Code Modification Best Practices for AI Tools
When Editing Files with AI Assistants
Use Line Numbers When Possible
Specify exact line numbers for insertions/modifications
Example: Insert at line 45: class RateLimitException(Exception):
Provide Sufficient Context
Include 3-5 lines before and after your target section
Example: Find the section after import statements and before class definitions
Handle Line Ending Differences
Windows files use CRLF (\r\n) while Unix uses LF (\n)
Specify if files have specific line endings when providing context
Multiple Approaches
Provide both targeted changes and full file replacements as fallbacks
Example: "Try making this targeted change; if that fails, use this complete file"
Use Pattern Matching
Look for function signatures, class definitions, or comments as anchors
Example: Find the function starting with 'def connect_arena'
Work with Temporary Files
Create new files and validate before replacing originals
Example: "Create temp file first, then replace original after verification"
Regular Expressions
For complex pattern matching, use regex with clear documentation
Example: Find pattern: class\s+ArenaAPIClient.*?def\s+__init__"
I see platofrm:macos was added to this item but this is happening to me on Windows using the Docker image and WSL.
I've seen the same, and have some additional info @sithamet @JCaldwell-SP #525 do your files contain similar content? (
<Name>)?This is happening on virtually every edit I've tried to make with https://github.com/DCsunset/taskwarrior-webui, as an experiment on macOS with 0.2.53 (Claude Code). Perhaps the repo might be able to help shed some light on the issue?
Same, this is happening on almost every other edit claude tries to make for me. All our files use
LFendings but we use tabs for indentation in our python code (not spaces), could it be that claude is trying to search for code with spaces?How can we upvote this / get it attention? I already submitted the bug weeks back and hate having to just +1 comment.
What I'd like to be sure Anthropic grok is that this is burning our credits and our context windows, Claude is very robust/persistent and typically finds some way to apply the change, but the journey from Update to Replace or Write to grep and sed ends up very expensive, and any help from the user swiftly forgotten. The issue boringly pollutes every little change.
(And just sometimes, a bad sed completely breaks code.)
Perhaps it might open up some kind of abuse affordance, but it seems any attempt by the assistant that completely fails should get charged differently. Pretty sure that would incentivise a fix!
I suspect it's something dumb: that on relevant platforms Claude Code is introducing the formatting inconsistencies it later trips over.
This issue is making Claude Code borderline unusable for me. It very quickly seems to get into a state where every edit fails, and becomes an Update > Search > [Grep / Cat / Sed] sequence. This is both slow and expensive.
I ended up giving up. I couldn’t get a reasonable workflow. Converting all files’ line endings is not a reasonable workflow for me.
This should be feeling better in newer version. Restart to get the latest update or run
claude update. Please open a new issue + include the file contents if this is still happening a lot for a specific file.I have not noticed an improvement in 105. Since I am unable to share specific files, I will refrain from opening a new issue.
Claude generally seems to have issues with files above 700 or so lines, quickly leading down the grep, cat, sed, "replace in new file then move", "write weird bash helper script" and lastly xxd (!!!!) slope. Often, these commands have to be manually confirmed, without an option to remember and allow the tools (probably because claude is often chaining multiple with pipes).
This has quickly become the must frustrating thing for me about a tool I love.
I'm getting this in 107 on ubuntu 22.04 based distribution. Poor Claude, it's hard to see them struggle like this :\
This is using bedrock as well.
Also getting this issue constantly on 107 in Macos
Any update on this @bcherny ? This happens way too much and has not been fixed for months now. It does not appear to be related to line endings or operating system. See here, for other issues referencing this problem:
https://github.com/anthropics/claude-code/issues/139
https://github.com/anthropics/claude-code/issues/164
From what I can tell it's probably an issue with whitespaces. Once Claude figured out to check the whitespaces, most of the time it's able to figure out how to apply the edit.
I can't continue using if this is not fixed, it ruins the whole experience of using Claude Code and appears to also make Claude much dumber as it's constantly trying to reapply changes in different ways until it finally suceeds
Just started happening for me today. Borderline unusable. It will only find files in the first few sets of folders, but anything even slightly deeper cannot be found.
That's interesting timing given they just released 1.0.21 and claimed an
improvement. (See CHANGELOG.md)
On Fri, 13 Jun 2025, 02:42 Daniel Ebeling, @.***> wrote:
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.