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

View original on GitHub ↗

17 Comments

JCaldwell-SP · 1 year ago

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.

ssampathinfraredx · 1 year ago

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__"

JCaldwell-SP · 1 year ago

I see platofrm:macos was added to this item but this is happening to me on Windows using the Docker image and WSL.

inigohidalgo · 1 year ago

I've seen the same, and have some additional info @sithamet @JCaldwell-SP #525 do your files contain similar content? (<Name>)?

hakusaro · 1 year ago

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?

pirate · 1 year ago

Same, this is happening on almost every other edit claude tries to make for me. All our files use LF endings 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?

anthonybailey · 1 year ago

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.

eAi · 1 year ago

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.

hakusaro · 1 year ago

I ended up giving up. I couldn’t get a reasonable workflow. Converting all files’ line endings is not a reasonable workflow for me.

bcherny collaborator · 1 year ago

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.

modelD-svg · 1 year ago

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.

mruderman · 1 year ago

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.

djaddis · 1 year ago

Also getting this issue constantly on 107 in Macos

GigaDroid · 1 year ago

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

de6eling · 1 year ago

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.

anthonybailey · 1 year ago

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:

de6eling left a comment (anthropics/claude-code#372) <https://github.com/anthropics/claude-code/issues/372#issuecomment-2968726817> 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. — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/372#issuecomment-2968726817>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAXXDM62G42FV6UWSSC65D3DIUA5AVCNFSM6AAAAABYPQ6DMKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSNRYG4ZDMOBRG4> . You are receiving this because you commented.Message ID: @.***>
github-actions[bot] · 11 months ago

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.