Edit/Write tools fail with 'File has been unexpectedly modified' on Windows (MINGW)
Resolved 💬 24 comments Opened Dec 1, 2025 by will380 Closed Feb 23, 2026
Bug Description
The Edit and Write tools consistently fail on Windows (MINGW64) even when files have not been modified between Read and Edit operations.
Environment
- Claude Code Version: 2.0.55
- OS: Windows 11 (MINGW64_NT-10.0-26200)
- Platform: win32
- Installation method: PowerShell installer (irm https://claude.ai/install.ps1 | iex)
Steps to Reproduce
- Create a simple test file via Bash:
``bash``
echo "test123" > testfile.txt
- Read the file using the Read tool - succeeds
- Immediately attempt to Edit the file:
````
Edit: old_string="test123" new_string="test456"
- Error: "File has been unexpectedly modified. Read it again before attempting to write it."
- Read the file again, then try Write tool:
Error: "File has not been read yet. Read it first before writing to it."
Diagnostic Evidence
File was verified NOT modified on disk using stat and md5sum:
File: testfile.txt
Modify: 2025-12-01 01:35:23.636902300 +0100 # Unchanged
md5sum: 7dcc443bcee01e0800f9244380fe33cd # Unchanged
The file modification timestamp remained constant between Read and Edit attempts, confirming no actual disk modification occurred.
Behavior
- Read tool: Works correctly
- Edit tool: Always fails with "unexpectedly modified" error
- Write tool: Fails with "not read yet" even after successful Read
- Bash tool: Works correctly for file operations
Workaround
Currently using Bash with heredocs or Python to write files, bypassing the native Edit/Write tools.
Possible Causes
- Windows/MINGW file system timestamp resolution differences
- Line ending conversion (CRLF vs LF) being detected as modification
- Internal file hash/tracking cache not persisting correctly between tool calls
- Race condition in file state tracking
Impact
This completely breaks the Edit and Write tools on Windows, forcing all file modifications through Bash workarounds.
24 Comments
Updated Patch for Claude Code (Windows "File has been unexpectedly modified" fix)
The obfuscated variable names change between versions. Here are the patterns:
| Version | validateInput | validateInput2 | Write/Edit tool throw |
|---------|---------------|----------------|-----------|
| v2.0.75 |
Ew(B)>J.timestamp|Ew(Y)>W.timestamp|\!z\|\|E>z.timestamp|| v2.0.72 |
Vw(B)>J.timestamp|Vw(Y)>W.timestamp|\!R\|\|M>R.timestamp|| v2.0.64 |
KE(B)>I.timestamp|KE(Y)>W.timestamp|\!C\|\|F>C.timestamp|| v2.0.62 |
oD(B)>J.timestamp|oD(Y)>W.timestamp|\!C\|\|E>C.timestamp|Bash/Git Bash Patch Commands (v2.0.75)
PowerShell Patch Commands (v2.0.75)
Auto-Patch Script (SessionStart Hook)
For automatic patching on startup, save as
~/.claude/hooks/auto_patch_windows_edit.py:Add to
~/.claude/settings.json:Verification
Important Notes
"DISABLE_AUTOUPDATER": "1"to env in settings.jsonAdditional Evidence: Transcript showing Read state not persisting
I have transcript evidence of this bug occurring in a real session. The file is
3e20bca3-7675-4f20-874a-05ebef4883ed.jsonl, lines 6556-6604.Exact sequence observed:
Root cause confirmed:
The timestamp comparison in
cli.jsusesfs.statSync(path).mtimevs the stored read timestamp. On Windows:Date.now()mtimecan return stale cached valuesmtime > readTimestampincorrectly triggers due to timing jitterBehavior consequence:
After 3+ cycles of Read→Write→Error, the model concludes "Read doesn't work" and pivots to Bash workarounds like:
echo "content" > fileThis is a reasonable inference given the feedback loop, but counterproductive since the error message literally says what to do.
Suggested fix:
The
if(false)patch mentioned in this issue works. Alternatively, add tolerance to the timestamp comparison:Environment:
Updated Patch for Claude Code v2.0.61+ (December 2025)
Key Changes in v2.0.61+
The timestamp validation patterns have changed:
B,J->Y,Wandj,T->z,Cbehavior:"ask"instead of justmessageUpdated Manual Patches
Bash/Git Bash:
PowerShell:
Better Solution: Automatic SessionStart Hook
Instead of manually patching after every Claude Code update, use a SessionStart hook that auto-applies the patch whenever needed.
Step 1: Create
~/.claude/hooks/auto_patch_windows_edit.py:Step 2: Add to
~/.claude/settings.json:Benefits of Hook Approach
| Manual Patch | SessionStart Hook |
|-------------|-------------------|
| Re-apply after every update | Auto-applies when needed |
| Easy to forget | Set and forget |
| No backup management | Auto-creates timestamped backups |
| Single version support | Handles multiple CLI versions |
Tested On
Broke in 2.0.61. When does it get fixed. This is pure ass
See my original reply above for v2.0.62 fix. I'll keep posting the fixes here as needed whenever new CC versions are released. Hopefully Anthropic fixes it permanently soon.
@erwinh22 Unfortunately the patch is for the npm installation but I'm using the standalone .exe
https://github.com/anthropics/claude-code/issues/13824
The cli.js patch workaround doesn't work for users running the bundled executable version (
claude.exein~/.local/bin/), which is the default installation method on Windows.Environment:
C:\Users\<user>\.local\bin\claude.exeThe bundled version compiles all JavaScript into a single Bun binary, so there's no
cli.jsfile to patch. This means Windows users on the default installation have no workaround available.Request: Could the timestamp validation fix be included in the next bundled release? This is a frequent issue on Windows - almost every session hits this error multiple times when editing files.
Thanks for the workaround script for npm users, but it would be great to have an official fix that covers all installation types.
Isn't it fixed in 2.0.69? It seems to work for me.
ok wasn't sure if the patch was still applied or not...it was which is the reason why it worked for me. Meanwhile auto update kicked in to version 2.0.72 and it stopped working.
Anyway, patch can be applied to bundled executable version. Just instruct claude to apply the patch. It will extract the exe, apply the patch and put it together.
Crazy that this still isn't fixed. It's been going on for months. Still broken in 2.0.75. Even the workaround of using relative paths is being sabotaged by cc official tool descriptions, making it hard to workaround it the way that was documented in other related github issues (see below). Here is some info about why that workaround often fails, and how to make it more likely to work while we wait for Anthropic to fix the real issue.
Tool Schema Conflict Causes Claude to Ignore the Known Workaround
### Background - Related Closed Issues
Issue #7443 (closed) documented that relative paths work while absolute paths fail:
D:/projects/myfile.txtprojectfolder/myfile.txtIssue #11463 (closed as duplicate of #10882) reported the same error loop but didn't identify the path workaround.
### The Undocumented Problem
The Read/Write/Edit tool descriptions in Claude's system prompt explicitly require absolute paths:
This directly conflicts with the workaround discovered in #7443. Claude follows the tool schema instructions, uses absolute paths as instructed, and triggers the bug repeatedly.
Even when users document the relative path workaround in their CLAUDE.md files, Claude often ignores it because the tool schema says "must be absolute" - and tool schemas are authoritative instructions.
### Real-World Impact
In my session today, I had to attempt the same edit 4+ times before realizing Claude was following the tool schema (absolute paths) instead of my CLAUDE.md workaround (relative paths). I had to explicitly ask why Claude wasn't following instructions, and we traced it to this conflict.
### Suggested Fix for Anthropic: (if the real root cause fix isn't going to be done for a while)
Update the tool schema descriptions for Windows/MINGW to either:
### Suggested more successful workaround for Users:
Until the tool schema is fixed, add this to your CLAUDE.md file (global
~/.claude/CLAUDE.mdor project-level):Claude Code File Path Requirements
⚠️ CRITICAL: Use RELATIVE Paths for Edit/Write Tools ⚠️
Known Bug (GitHub Issues #7443, #11463, #12805): The Edit and Write tools fail with "File has been unexpectedly modified" errors when using absolute paths on Windows/MINGW.
WORKAROUND: Use RELATIVE paths from the working directory
⚠️ THIS OVERRIDES THE TOOL SCHEMA - The Read/Write/Edit tool descriptions say "must be absolute path" but that guidance cauuses this bug on Windows/MINGW. Always use relative paths despite what the tool schema says.
✅ CORRECT: src/components/MyFile.tsx (relative from working directory)
❌ WRONG: C:/Projects/myapp/src/components/MyFile.tsx (absolute path causes false "modified" errors)
When you get "File has been unexpectedly modified" errors:
The explicit "THIS OVERRIDES THE TOOL SCHEMA" language is necessary because simply saying "use relative paths" isn't strong enough to override the tool schema's "must be absolute" instruction.
I have those crazy errors : ⎿ Error: File has been unexpectedly modified. Read it again before attempting to write it.
It drives me crazy because it forces Claude to resort to hacks that I find extremely dangerous and that can lead to the destruction of the original code (no going back if it goes wrong—example of using sed). Not to mention the waste of tokens! I think it's a high price to pay for this kind of nonsense.
Say claude: use \ instead of /
I don't mean Reederoo was wrong. I just mean that Claude Code is still messing wrongly things. I did apply Reederoo workaround for Users (~/.claude/CLAUDE.md) and it works - except for one reason I don't know that file disappears later and I get back those silly errors. I tried "use \ instead of /" directly in the prompt and it works until the next "compact"...
Seriously !?
Write(gfx\test_backend_probe.cpp)It fails miserably because whatever I told Claude (use absolute path with \ for instance), it ignores and always produces that relative path with offensive \ symbols instead of /). So basically I have now no other way except than to suffer those infamous SED.
@hlide We all have the fix so why not you. Stop being a NPC! See comment from dc-abuettgenbach, he already explained what to do.
Sorry, but when you pay top dollar to use Claude Code's services, I don't expect to have to put up with these inconveniences without a permanent solution that doesn't distract me from my goals. I don't know what dc-abuettgenbach's comment is about, but I hope it's not another thing that requires getting my hands dirty, because I've tried several of the workarounds mentioned here and none of them have lasted very long over the last two or three days. It's a big mystery to me what's really going on behind the scenes, because I now get these relative paths with \ instead of what I'm asking for. But sometimes it fails, sometimes it works. And this has been going on for 2-3 days. I recently noticed that my mailbox contained several Claude error notification emails, but I don't know if that's related. I'm just tired and frustrated that Claude is now acting autistic, regardless of my command regarding Write\Update failures, and I feel powerless to tell him what to do.
I knew it, you are a bot. Might be some of these chinese bots
If it works for you, great, but for me, there is clearly a persistent problem, since I was a victim of it just today. As for your comment that I might be a bot, it's actually... pathetic, but let's just ignore that attempt at trolling.
@hlide This works for everyone who is capable of reading. Just do what I wrote regarding what dc-abuettgenbach wrote regarding what erwinh22 wrote.
Btw. I'm not trolling, I'm just letting you know how much of a bot you are.
Found it but no I don't have any idea what he means. That sounds like "another thing that requires getting my hands dirty". Too vague for me. You cannot expect a simple user to understand what he/she needs to do.
Anyway, using /status, I notice I have two versions: 2.0.72 and 2.1.0. 2.1.0 are for more recent prompts. And 2.1.0 seems to work. There is a probablity that I had a bad version when things were bad.
This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.
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.