anthropics
String to replace not found in file - CRLF/LF issue
Getting this issue often when it tries to edit files. Using WSL in Windows, wondering if it relates to my CRLF/LF issue. I did configure my git line endings via git config --global core.autocrlf, still getting this issue.
If you're hitting this a lot, would you mind reporting an issue through /bug and posting the feedback id here?
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.
It managed to waste $1.31 in just 3 minutes
Feedback id: 2088a5a9-2e48-4c7c-8243-7678a181019e
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 did NOT work for me :/ Env: Arch Linux, Bash, Konsole
c44ad734-d20e-4f7b-b0eb-4eb9ddb769dd
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?
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...
