[Bug] Edit tool fails on Windows with CRLF line endings: Read output mismatches file content

Resolved 💬 4 comments Opened Apr 30, 2026 by Alex-Ylx Closed May 31, 2026

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?

On Windows, the Edit tool fails to match old_string when editing files with CRLF
line endings. The Read tool returns content normalized to LF (\n), but the Edit
tool tries to match against the original file content with CRLF (\r\n), causing a
mismatch even when the visible text is identical.

What Should Happen?

  1. Consistent line ending handling: Read and Edit should use the same line ending format

(preserve CRLF on Windows, or normalize both).

  1. Block-level replacement: Support replacing entire code blocks/methods without fragile

multi-line string matching (similar to Trae's show_diff).

Error Messages/Logs

tool_use_error: String to replace not found in file.
  String: query.setOrderBy(null);
  try (Jedis jedis = jedisManager.getJedis(RedisConstants.CACHE_DB_INDEX)) {
  ...
  (Note: Read returned LF line endings, but file has CRLF)

Steps to Reproduce

  1. Open a file with CRLF line endings on Windows.
  2. Use Read tool to get a multi-line code block.
  3. Use the returned content as old_string in the Edit tool.
  4. Error: String to replace not found in file.

Claude Model

Other

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.119

Platform

Other

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗