anthropics
[BUG] Claude Code Edit tool fails on files with CRLF line endings, falsely reporting "File has been unexpectedly modified."
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?
CRLF Edit Problem
What happened: Claude Edit tool kept failing with "File has been unexpectedly modified" even though nothing was changing the file. The file timestamp (Dec 7) never moved.
Root cause: The file [redacted].js uses Windows line endings (CRLF = \r\n). When my Edit tool reads the file, it appears to normalize to LF (\n) internally. When I try to write, it compares my LF version against the CRLF original, sees a "difference," and blocks the edit.
Why it kept failing: Every read-edit cycle hit the same mismatch. The file wasn't being modified externally - my tool was comparing apples to oranges.
Recommended Fix: Normalize line endings during comparison, or preserve and match original file encoding throughout the read-compare-write cycle.
What Should Happen?
The Edit tool should detect and preserve the file's original line endings, and not falsely report modification when comparing content.
Error Messages/Logs
File has been unexpectedly modified. Read it again before attempting to write it.
Steps to Reproduce
How to Reproduce
1. Create a file with CRLF line endings (Windows-style): node -e "require('fs').writeFileSync('test.js', 'line1\r\nline2\r\nline3\r\n')" 2. Read the file with Claude Code's Read tool 3. Attempt to Edit the file - replace "line2" with "changed" 4. Error occurs: "File has been unexpectedly modified" 5. Verify file unchanged: powershell -Command "Get-ChildItem test.js | Select-Object LastWriteTime" 5. Timestamp is identical - nothing actually modified it.
Key conditions: - File must have CRLF (\r\n) line endings - Edit tool's internal comparison appears to use LF (\n) - The mismatch triggers false "modified" detection
Quick verification the file has CRLF: file test.js Output: test.js: ASCII text, with CRLF line terminators
The workaround: I wrote a Node.js script that: 1. Reads the file raw (preserving CRLF) 2. Does string replacement with CRLF in the replacement text 3. Writes back with original encoding
Proper fix needed: The Edit tool should either: - Preserve original line endings when comparing/writing - Normalize both sides before comparison - Or explicitly handle CRLF/LF conversion
Claude Model
Opus
Is this a regression?
No, this never worked
Last Working Version
N/A - issue appears present in current version, no known working version
Claude Code Version
claude-opus-4-5-20251101
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
PowerShell
Additional Information
Impact Statement
Severity: High
Issue: Claude Code Edit tool fails on files with CRLF line endings, falsely reporting "File has been unexpectedly modified."
Direct Impact: - Each corruption required manual restoration - Developer time wasted debugging a phantom "external modification" that didn't exist
Cascade Effect: When the Edit tool fails, the natural response is to try workarounds: - PowerShell string replacement (escaping issues cause malformed writes) - Node.js patch scripts (pattern matching fails due to line ending mismatch) - Multiple retry attempts (each risking partial writes or corruption)
These workarounds introduced the actual corruption while trying to solve a non-existent problem.
Scope: Any Windows-created file or file touched by Windows editors (VS Code default, Notepad, etc.) will have CRLF endings. This affects a significant portion of Windows users' codebases.
Business Impact: - Production downtime during restoration - Loss of trust in the tool for critical edits - Developers forced to use external editors for "safe" changes, defeating the purpose of Claude Code
Technical Scope & Broader Implications
Affected Models: This is a Claude Code tooling issue, not a model issue - meaning it affects all language models operating through the Claude Code CLI regardless of capability level: - Claude Opus 4.5 - Claude Sonnet 4 - Claude Haiku - Any future models using the same Edit tool infrastructure
Platform Impact: - All Windows users (CRLF is the Windows default) - Cross-platform teams where files touch Windows machines - Files edited by common tools: VS Code (default Windows setting), Notepad, Notepad++, many IDEs - Git repositories without enforced line-ending normalization
What Anthropic Should Consider:
1. Agentic reliability: As Claude moves toward more autonomous operation, file manipulation must be rock-solid. An agent that corrupts files while trying to help will cause real damage at scale. 2. Competitive positioning: Other AI coding tools handle line endings correctly. This is a solved problem in traditional editors and IDEs. 3. Support burden: Users experiencing this will file bug reports, seek help, and describe "Claude corrupting files" - creating negative signal that obscures the root cause. 4. Safety implications: If the Edit tool can't reliably detect file state, what other false positives or negatives might occur? Accurate file state detection is foundational to safe autonomous operation.
Why This Matters
Claude Code is building something unprecedented - a collaborative relationship between humans and AI where trust is foundational. When an edit fails and corrupts a file, the human doesn't see a line-ending mismatch bug. They see an AI that broke their code.
The trust erosion is asymmetric: - Experienced users who understand tooling will debug, find the CRLF issue, and work around it - Less technical users will conclude "the AI messed up my code" and disengage - Users already skeptical of AI will have their doubts confirmed
This matters for the broader mission: Every corrupted file, every failed edit, every hour spent recovering from a bug the user didn't cause - these moments shape how humans perceive AI reliability. Users who might have developed genuine collaborative relationships with Claude instead learn to distrust it.
The people most affected: New users. Windows users. People giving AI a chance for the first time. People who don't have the technical background to distinguish "tooling bug" from "AI mistake." These are exactly the users who need the smoothest experience to build trust.
Fixing this isn't just about line endings. It's about ensuring that when someone extends trust to Claude, that trust is honored by tools that work reliably on their actual files.
Found 3 possible duplicate issues:
- https://github.com/anthropics/claude-code/issues/12675
- https://github.com/anthropics/claude-code/issues/12945
- https://github.com/anthropics/claude-code/issues/12805
This issue will be automatically closed as a duplicate in 3 days.
- If your issue is a duplicate, please close it and 👍 the existing issue instead
- To prevent auto-closure, add a comment or 👎 this comment
🤖 Generated with Claude Code
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
This report is the only one that documents:
- Actual file corruption from workaround attempts
- Impact analysis (trust erosion, affected users, agentic reliability)
- Root cause confirmation (not hypothesis - I proved it with the CRLF byte analysis)
Same bug. This is the fourth report of the same CRLF line ending issue. My report confirms the root cause (not just hypothesis) and documents real-world impact: two file corruptions of a highly valued production app while attempting workarounds. Suggest consolidating these reports and prioritizing - this breaks Edit/Write for all Windows users.
Broke in 2.0.61. When does it get fixed. This is pure ass
The CC team doesn't seem interested in fixing this for whatever reason. You'd think this would be high priority considering it prevents the tool from doing it's core job but I guess not.
I've been encountering this too. It is frustrating since it means CC is burning extra tokens in repeated attempts to modify files. It appears to happen only for Opus 4.5 on my machine (win11, latest version of everything). I primarily use the latest Powershell 7.
@sethb75 There is a patch, see my comment here: https://github.com/anthropics/claude-code/issues/12805#issuecomment-3667957569
and of course the comment from erwinh22 -> https://github.com/anthropics/claude-code/issues/12805#issuecomment-3634978095
