[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')"

1. Read the file with Claude Code's Read tool
2. Attempt to Edit the file - replace "line2" with "changed"
3. Error occurs: "File has been unexpectedly modified"
4. Verify file unchanged:

  powershell -Command "Get-ChildItem test.js | Select-Object LastWriteTime"

1. 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.

1. Competitive positioning: Other AI coding tools handle line endings

  correctly. This is a solved problem in traditional editors and IDEs.

1. Support burden: Users experiencing this will file bug reports, seek help,

  and describe "Claude corrupting files" - creating negative signal that
  obscures the root cause.

1. 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.