String to replace not found in file - CRLF/LF issue

If you're hitting this a lot, would you mind reporting an issue through /bug and posting the feedback id here?

07e72b6b-c112-4b02-905e-d8eec9baf2ff

having the same issue, 74171893-4d01-47ba-aaa0-f20f7792d81f

Me too a9f54b59-e5af-4298-9fe5-03c7bbf81903

Same here: c4cb55e4-9f92-455e-8fe4-ac1a55f63205

Same here: cdf32a47-aad0-48f7-8cbc-d1b178324b4f

I am also seeing these all the time on ubuntu. It manages to edit the code anyway but it typically has to follow up each failed Update with a slower Read and some other operations to get the editing done.

Had the same issue, on a Linux system. Using SHELL=/bin/bash claude, to clarify.

!Image
It managed to waste $1.31 in just 3 minutes

Feedback id: 2088a5a9-2e48-4c7c-8243-7678a181019e

Same issue, very frustrating: 76f2ea25-5913-4013-ac44-594dbe97e50f

This is also the case on ubuntu, not just windows

same issue as reported above, windows WSL ubuntu, claude started from project directory

thanks!

The issue is that Claude is trying to replace a segment of code in a file. When it has this task, it tries to locate the code by a matching string, but it is required to match perfectly to tiniest degree including the surrounding whitespace etc. ( I grilled Claude hard to get that info). I suggested a simple workaround... "Instead of doing an "in-file" replacement, just write a new copy of the file from scratch, keeping the full content except for the segment you need to replace, and write that in accordingly." Works perfect every time. I also asked Claude why it would get endlessly stuck on such a simple hurdle, it replied, "Tunnel Vision, and trying to over engineer solutions instead of the simple and obvious."

This little work around is a staple in my sessions with Claude Code now. Have Claude dig in and explain its failures. I'm finding most to be trivial for human reasoning.

Check your file if you are using CRLF. Changing to LF fixed the issue for me reliably. You can easily check and change the line encoding in VS Code (bottom right).

Check your file if you are using CRLF. Changing to LF fixed the issue for me reliably. You can easily check and change the line encoding in VS Code (bottom right).

Can confirm. This solved the issue for me on Fedora.

Check your file if you are using CRLF. Changing to LF fixed the issue for me reliably. You can easily check and change the line encoding in VS Code (bottom right).

This helped me too, though the issue persists to a much lesser degree.

Check your file if you are using CRLF. Changing to LF fixed the issue for me reliably. You can easily check and change the line encoding in VS Code (bottom right).

Helped me as well once I moved everything in my repo to LF, thank you!

switching to LF fixed the issue for me

Switching to LF did NOT work for me :/
Env: Arch Linux, Bash, Konsole

c44ad734-d20e-4f7b-b0eb-4eb9ddb769dd

This is fixed in 0.2.38. Restart to update!

Still getting this, latest bug report e46e005f-e0fd-4597-9c4a-72c9f2f185d8

Still see this a lot too on Mac. Files are set to LF.

Seeing this in VSCode on Windows 11 in WSL a lot with LF file endings.

Feedback ID: babf96e8-9a7b-4e8e-931e-b0f04ddd7beb

Possible solution is to ensure spaces and not tabs in files:

Seeing this in VSCode on Windows 11 in WSL a lot with LF file endings in a NodeJS project. Uses a lot of tokens retrying and failing. Feedback ID: babf96e8-9a7b-4e8e-931e-b0f04ddd7beb EDIT: Might be because of tabs? https://github.com/anthropics/claude-code/issues/781 EDIT 2: I stopped having this problem after converting all tabs to spaces in my codebase

_Originally posted by @Dekadinious in #968_

I also have this problem EXTREMELY often. I don't really want to convert all my tabs to spaces ☹

Same issue here on windows 11 wsl2 arch linux using zsh shell if that matters.

You guys have to fix this, we can't always control line endings in third party code and sometimes are editing files that require windows line endings.

You guys have to fix this, we can't always control line endings in third party code and sometimes are editing files that require windows line endings.

Yeah, I'm not usually one for the dramatics, but this one really is a deal breaker. It wastes tons of tokens and really is frustrating and makes Claude code for the most part unusable for me.

I am seeing this error a lot (latest Mac OS, fresh/latest Claude Code and VSCode). I just started using Claude Code and find that my context window is getting maxed out pretty fast whenever seeing these errors. It feels like there should be some kind of "credits" refunded to customers who are encountering this and rapidly approaching their API limits when this would not be the case if this bug were resolved. If the LF change doesn't work, I assume there's nothing that can be done on user end, right?

12855be1-b017-43a0-8ff8-5a75266114ed

I was pulling my hair out over this. What helped was a user memory I added:

# If you see "String to replace not found in file", try using sed instead.

If you see "String to replace not found in file", try using sed instead.

this seems to work for me, bot sometimes it produces some weird output and then claude fixes it, consuming more token. This whole situation is consuming a lot of token, sigh...

This has almost completely stopped for me after installing ripgrep and the bot seems to favor it.

78ec07c8-ebf5-4ac0-8dff-13cdab203bb8

Feedback ID: 747f249e-bcfa-457c-96c4-463f36e4cd53

Feedback ID: e312e2ee-2ce3-479c-9084-1111e82efbb7

Claude code can read it but when tried to replace with upload task error raised

We fixed a bunch of string-replace-related bugs back around the end of June and early July, and it looks like we're not seeing more instances of this issue since then. We're going to go ahead and close this as fixed (it's likely related to several different root causes, but we're fairly sure most of them are fixed at this point). If you see new string replace issues (on versions 1.0.87 or later), please open a separate issue so we can address those problems more specifically.

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.