search_replace tool fails on Windows due to CRLF line ending mismatch (common AI coding bug)

Bug Reports
1

Issue Description

Steps to Reproduce

Issue Description

The search_replace tool consistently fails on Windows with “Missing replacements” error when attempting to edit files, regardless of how simple or exact the match is. This is caused by CRLF (\r\n) vs LF (\n) line ending mismatches between file content and the tool’s internal comparison logic.

Impact: All Windows users are unable to use the search_replace tool reliably, forcing manual workarounds or external editors.

Steps to Reproduce

  1. Create or open any Python file on Windows with CRLF line endings (default Windows format)

  2. Use the search_replace tool to make even a simple one-line change

  3. Example command that fails:

    python

    # File has: WAIT_TIME_FOR_WINDOWS = 750
# Attempt: search_replace(old="WAIT_TIME_FOR_WINDOWS = 750", new="WAIT_TIME_FOR_WINDOWS = 600")

  4. Observe error: “Missing replacements, MUST generate arguments with completed parameters structure…”

Expected Behavior

When search_replace succeeds, the tool should:

  • Detect the file’s line ending format (CRLF on Windows)

  • Preserve original line endings during read-compare-write cycle

  • Successfully find and replace matching text

  • Write changes back with same line ending format

  • Work transparently regardless of OS

Actual Behavior

  • search_replace consistently fails with “Missing replacements” error

  • Even exact text matches fail to be found

  • No indication of what actually failed to match

  • Tool appears to normalize CRLF to LF internally, then compares against original CRLF file

  • Mismatch causes false negative “not found” result

  • Forces users to use PowerShell workarounds or external editors

Workaround Required:

powershell

(Get-Content gma/gui/main_window.py) -replace 'old', 'new' | Set-Content gma/gui/main_window.py

Root Cause Analysis

This is a known, widespread bug affecting multiple AI coding assistants on Windows:

Confirmed Cases:

  1. Claude Code - GitHub Issue #13456 (Dec 2025)

    • Error: “File has been unexpectedly modified”

    • Cause: Edit tool reads CRLF as LF, compares against original CRLF

    • Status: Open, labeled as bug + platform:windows

  2. Cursor IDE - Forum Report (Oct 2025)

    • User: “sometimes when i ask claude to edit files… its corrupting files”

    • Version: 1.7.40 on Windows 10/11

  3. Cline - GitHub Issue #4011 (Jun 2025)

    • Error: “Invalid REPLACE marker detected”

    • Note: “issue arises regardless of content size, indicating potential bug related to line endings”

  4. OpenAI Codex - GitHub Issue #9914 (Jan 2026)

    • Error: “failing to write newlines with apply_patch because of mixed CRLF”

    • Fallback to slow Python method required

Technical Details:

  • Windows default: CRLF (\r\n) line terminators

  • Most editors (VS Code, Notepad++) save with CRLF on Windows

  • Git on Windows often configured with core.autocrlf=true

  • AI tools read file → normalize to LF (\n) internally

  • When comparing/writing back: LF ≠ CRLF → “not found” or “modified”

  • Tool blocks edit thinking file changed externally (when it hasn’t)

Environment

Operating System: Windows 11 (25H2)
Shell: PowerShell 7.x
Qoder Version: [Please check: Menu → About Qoder → Copy]
Python Version: 3.12.x
Project: GMA-Lab-Ten (Windows-native project)

Verification Commands:

bash

# Check if file has CRLF
python -c "f=open('file.py','rb'); print('Has CRLF:', b'\r\n' in f.read())"
# Output: Has CRLF: True

# Or use file command
file gma/gui/main_window.py
# Output: ASCII text, with CRLF line terminators

Suggested Fix

The search_replace tool should:

  1. Detect line endings when reading a file (CRLF vs LF)

  2. Preserve original encoding throughout the read-compare-write cycle

  3. Normalize both sides before comparison (convert file content and search text to same format)

  4. Write back with original line endings (don’t convert CRLF → LF)

  5. Or provide explicit option to enforce specific line ending format

Reference Implementation: Standard text editors (VS Code, Notepad++, Sublime Text) handle this transparently - it’s a solved problem.

Business Impact

Severity: High - Blocks core functionality for all Windows users

Direct Impact:

  • Every file edit requires manual workaround

  • Developer time wasted debugging phantom issue

  • Loss of trust in AI assistant for critical edits

  • Forces developers to abandon AI tools for “safe” manual editing

Cascade Effect:
When search_replace fails, users attempt workarounds:

  • PowerShell string replacement (risk of escaping errors)

  • External editors (defeats purpose of integrated AI)

  • Multiple retry attempts (each risking partial writes)

Scope:

  • All Windows users (CRLF is default)

  • Files edited by VS Code (default on Windows), Notepad, most IDEs

  • Any codebase without enforced LF-only policy

Why This Matters

As AI coding assistants move toward more autonomous operation, file manipulation must be rock-solid. An agent that fails on line endings will:

  • Corrupt files while trying to help

  • Cause production downtime during restoration

  • Erode trust in AI reliability

  • Disproportionately affect new users and Windows users

Fixing this isn’t just about line endings—it’s about ensuring that when someone extends trust to an AI coding assistant, that trust is honored by tools that work reliably on their actual files.

References

  1. Claude Code CRLF Bug: [BUG] Claude Code Edit tool fails on files with CRLF line endings, falsely   reporting "File has been unexpectedly modified." · Issue #13456 · anthropics/claude-code · GitHub

  2. Cursor IDE Corruption Report: Search_replace, write and read corrupting files - Bug Reports - Cursor - Community Forum

  3. Cline Line Ending Issue: replace_in_file tool consistently failing after recent VS Code extension update · Issue #4011 · cline/cline · GitHub

  4. OpenAI Codex apply_patch Bug: failing to write newlines with apply_patch because of mixed CRLF; fallback to (very slow) python · Issue #9914 · openai/codex · GitHub

Operating System

Current Qoder Version (Menu → About Qoder → Copy)

2

Thank you for the feedback—this is an excellent suggestion.What is the current Qoder version?:grinning_face: