[BUG] Edit Tool False Positive "File has been unexpectedly modified" on Windows

It takes multiple attempts to edit any file and eats all my money very quickly.

This has been ongoing for over 2 months now for me the work around i found is i have to tell claude "There's a file modification bug in Claude Code. The workaround is: always use complete absolute Windows paths
with drive letters and backslashes for ALL file operations. Apply this rule going forward, not just for this
file." this resolves the issue i need to reiterate this in each new session or after each compaction I add it to claude.md but it still sometimes forgets on an fresh session

Can you help provide more details around your configurations and repro steps?

• Running Claude Code with PowerShell, CMD, git bash, cygwin?
• What is your SHELL env var?
• When running claude --debug, any cygpath errors appear in the log file?

This bug is made claude code unusable for our team. We're using native windows which has always been poorly supported, but this one has caused us no end of issues. That workaround doesn't work.

It's broken on windows, but there is workaround to configure special
command on session startup so it works fine.
Just Google Claude bug reading files on windows.

On Fri, Dec 5, 2025, 4:09 PM ant-kurt @.***> wrote:

ant-kurt left a comment (anthropics/claude-code#12695) <https://github.com/anthropics/claude-code/issues/12695#issuecomment-3619007302> Can you help provide more details around your configurations and repro steps? - Running Claude Code with PowerShell, CMD, git bash, cygwin? - What is your SHELL env var? - When running claude --debug, any cygpath errors appear in the log file? — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/12695#issuecomment-3619007302>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADJDXJ2T5GHUDEB7W6JAPE34AINCPAVCNFSM6AAAAACNRUZUDGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMMJZGAYDOMZQGI> . You are receiving this because you authored the thread.Message ID: @.***>

Here's the workaround that Claude devised:

ME: i want to resolve "File has been unexpectedly modified". create junk.py in the project root. try and edit it like before

Write
source/junk.py
"""Test file for debugging file modification issues."""

def hello():
return "world"

Read source/junk.py
Edit source/junk.py
File has been unexpectedly modified. Read it again before attempting to write it.
There it is. Something is modifying the file between my Read and Edit. Let me check the timing:
Bash
stat "source/junk.py" && sleep 1 && stat "source/junk.py"
Modify: 2025-12-26 15:50:03.086423600 +0100
Change: 2025-12-26 15:50:03.088424700 +0100
Birth: 2025-12-26 15:50:03.086423600 +0100
... +13 lines
The Access time changed between the two stat calls (from 15:50:15 to 15:50:21) but Modify didn't. The issue isn't file content changing - it's likely that Claude Code's file watcher is using access time (atime) rather than modification time (mtime) to detect changes.
When I Read a file, it updates the access time. Then when I try to Edit, the system sees the atime changed and thinks the file was "modified".
This is likely a Windows NTFS behavior or a bug in how Claude Code tracks file changes. The workaround is to read and edit in quick succession or use Bash/Python to write files directly.

ME: devise an elegant fix

Let me look at how Claude Code might be detecting file changes:
Bash
cd "source" && python -c " import os...
... +8 lines
Confirmed: only atime changes on read, not mtime or content hash.
The elegant fix would be a small utility that wraps file operations and uses content hashing instead of timestamps.

ME: write this up, compactly, to add to claude.md
I need to write up the Windows file modification detection bug fix compactly for CLAUDE.md. Let me add this to the CLAUDE.md file:
Edit source\CLAUDE.md
<tool_use_error>File has not been read yet. Read it first before writing to it.</tool_use_error>

The irony! Let me read the file first: ME: HILARIOUS, ROFL

ME: Write source\editw.py

"""Windows-safe file edit via Bash. Replaces Claude's Edit tool."""
Done. Created: editw.py - Windows-safe edit script that:
Takes file path, old_string, new_string as arguments
Validates old_string exists and is unique
Performs replacement and writes back
No timestamp-based change detection
Updated CLAUDE.md with usage instructions:

Known Issue: Windows "File Unexpectedly Modified"

Problem: On Windows/NTFS, reading a file updates its atime. Claude Code detects this as "modification", causing false Edit failures after Read.

Workaround: Use editw.py instead of the Edit tool:

python editw.py "path/to/file.py" "old_string" "new_string"

ME: now modify junk.py to test it

Edit Source\junk.py
"""Test file for debugging file modification issues."""
def hello():
return "world"
return "moon"
Done. Changed return "world" to return "moon" in junk.py.

""" editw.py : Windows-safe file edit via Bash. Replaces Claude's Edit tool.

Usage: python editw.py <file_path>
Then paste old_string, separator, new_string on stdin.
Separator line: ===EDITW_SEP===
"""
import sys
from pathlib import Path

SEPARATOR = "===EDITW_SEP==="


def edit_file(file_path: str, old_string: str, new_string: str) -> None:
    """Replace old_string with new_string in file."""
    p = Path(file_path)
    if not p.exists():
        print(f"ERROR: file not found: {file_path}")
        sys.exit(1)
    if not old_string:
        print("ERROR: old_string is empty")
        sys.exit(1)
    try:
        content = p.read_text(encoding='utf-8')
    except UnicodeDecodeError:
        print(f"ERROR: file is not UTF-8: {file_path}")
        sys.exit(1)
    if old_string not in content:
        print(f"ERROR: old_string not found in {file_path}")
        sys.exit(1)
    count = content.count(old_string)
    if count > 1:
        print(f"ERROR: old_string not unique ({count} occurrences)")
        sys.exit(1)
    new_content = content.replace(old_string, new_string, 1)
    # Atomic write: write to temp, then rename
    tmp = p.with_suffix(p.suffix + '.tmp')
    tmp.write_text(new_content, encoding='utf-8')
    tmp.replace(p)
    print(f"OK: {file_path}")


if __name__ == "__main__":
    if len(sys.argv) != 2:
        print(f"Usage: python editw.py <file_path>")
        print(f"Then paste: old_string, '{SEPARATOR}' line, new_string")
        sys.exit(1)
    file_path = sys.argv[1]
    # Read all stdin
    stdin_text = sys.stdin.read()
    if SEPARATOR not in stdin_text:
        print(f"ERROR: stdin must contain separator line: {SEPARATOR}")
        sys.exit(1)
    parts = stdin_text.split(SEPARATOR, 1)
    old_string = parts[0]
    new_string = parts[1]
    # Strip exactly one leading newline from new_string (artifact of separator line)
    if new_string.startswith('\n'):
        new_string = new_string[1:]
    # Strip exactly one trailing newline from old_string
    if old_string.endswith('\n'):
        old_string = old_string[:-1]
    edit_file(file_path, old_string, new_string)

ME: let's hope someone on github gives you stars for fixing your own SNAFU

Recognized ironic self-fix situation, prepared humorous acknowledgment.Maurice is making a humorous/ironic point that:

Claude (the AI/Anthropic) has a bug in its Edit tool on Windows
Claude (me, the AI assistant) helped devise a workaround (editw.py)
Now he's sarcastically hoping people on GitHub will "give stars" to Claude for fixing Claude's own bug

It's a SNAFU (Situation Normal: All Fucked Up) - Claude's own tool is broken and Claude had to fix it.
I should acknowledge the irony with appropriate British humour, not take it too seriously, and definitely not make excuses for Anthropic's bug.Fair point. The irony isn't lost on me—Claude Code's Edit tool breaks itself by reading files, then Claude (me) has to write a workaround script to bypass Claude Code's buggy change detection.
Classic SNAFU.
At least the workaround is simple and your GitHub issue documents it well for others hitting the same Windows/NTFS false positive. Hopefully Anthropic fixes the atime vs mtime confusion in the actual tool rather than relying on users to write their own wrappers.
Until then, editw.py works and you've got Filesystem MCP as backup.

I encountered this issue this morning and Claude Code (Opus 4.5) thought the following might be useful:

Key finding: Write tool "resets" the broken state for individual files

After experiencing consistent Edit failures across multiple files, I used the Write tool to completely overwrite one file's contents. After that, subsequent Edit operations on that specific file started working again, while other files that hadn't been overwritten via Write continued to fail.

This suggests the bug is in how Edit tracks/caches file state internally, and that Write properly resets this tracking while Edit compares against stale or corrupted cached metadata.

Session characteristics:

• Platform: Windows (win32)
• Multiple files across different directories failed simultaneously
• Failure was immediate after Read (not gradual/delayed)
• 100% reproducible once it started - every Edit failed until Write workaround was used
• No editors, VCS software, or file watchers running
• Windows Defender exclusion was in place for the project directory

Answering @anthropics/claude-code-team's diagnostic questions:

• Shell: Bash (via Claude Code CLI)
• The issue occurred with absolute paths using forward slashes (e.g., D:/LR-Projects/...)

Suggested diagnostic approach: Compare how Write vs Edit update their internal file tracking state after an operation. Write likely replaces the tracked checksum/timestamp entirely, while Edit may be comparing against cached state that has become invalid. The fact that Write "fixes" a file strongly points to a state management issue rather than an actual filesystem race condition.

Happen usually, since 1.0.xxx version. Edit failed then it trying to use tool like "sed" to edit file (but still failed)

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.