Edit tool fails with "File has been unexpectedly modified" even after (Quite critical bug as it cannot code)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/3513
2. https://github.com/anthropics/claude-code/issues/5981
3. https://github.com/anthropics/claude-code/issues/3182

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

This is NOT duplicate.
I am getting same issue after recent patch.
THIS IS CRITICAL IN MY WORKFLOW

We really need this fixed is using BAsh SED , to edit. Terrible

Found a workaround for those with this issue , you need to open another claude instance. And instruct other claude what to do where he s left. At least is something....

I am having the same issue with CC and after testing it provided a breakdown:
"
Environment

• Claude Code Version: v1.0.111
• Platform: Windows 10, Git Bash/MINGW64
• Project: Next.js TypeScript application

Issue

Edit and MultiEdit tools consistently fail with "File has been unexpectedly modified" error when attempting to modify
files that existed before the current Claude Code session started.

Reproduction Steps

1. Start a new Claude Code session
2. Read any pre-existing file using Read tool
3. Attempt to Edit the file with exact string from Read output
4. Error: "File has been unexpectedly modified"

Test Results

✅ WORKS: Files created with Write tool in current session
❌ FAILS: Any file that existed before session started
✅ WORKS: Multiple edits on newly created files
❌ FAILS: Both Edit and MultiEdit tools affected

Evidence

• File checksums unchanged (MD5: 6a8903f730a6dbde831965e1729dbd1a)
• File timestamps show no modifications
• Issue persists with dev server stopped
• Same file content can be edited if file is recreated in current session
• Session-based state issue: Files become "un-editable" after Claude Code restarts
• Not file-specific: Same file, same content, different session = different behavior
• Consistent pattern: All pre-existing files fail with "unexpectedly modified" error

Root Cause Hypothesis

Claude Code's internal file state tracking appears to be session-based. Files created during the session have proper state
initialization, while pre-existing files lack this state, causing all edit operations to fail.

Impact

• Cannot edit any existing project files
• Forced to use workarounds (bash/sed, manual editing)
• Significantly impacts development workflow"

1. We successfully downgraded to v1.0.100 - the npm commands showed it worked
2. After restart, editing worked perfectly - multiple successful edits on testme.txt
3. Something reverted us back to v1.0.111 without our knowledge
4. The bug returned once we were back on v1.0.111

Ok I noticed I could edit files fine in another project, so I tested more. Does this correct the problem for anyone else experiencing it? I'm back to editing...
"
Root Cause Discovery:

• Issue: Path format used by Claude Code

Solution:

1. Use relative paths: projectfolder/... instead of E:/Projects/projectfolder/...
2. Use forward slashes: / not \
3. Start from workspace root: cd /e/projectfolder then use relative paths

Test Results:

• ❌ Absolute path: E:/projectfolder/test.txt - FAILS
• ✅ Relative path: projectfolder/test.txt - WORKS"

This is the conclusion from the tests I made it do, but It has been whacked out today, so take it with a grain of salt.

CRITICAL DISCOVERY: Sequencing Bug Identified

CORRECTED TEST RESULTS:

| Test Sequence | Path Type | Path Given | Read Result | Edit Result | Error Message |
|---------------|-----------|-------------------------------|-------------|-------------|---------------------------------------|
| FIRST | absolute | D:/clients/oakley/test1.txt | ✅ Success | ❌ FAIL | "File has been unexpectedly modified" |
| AFTER REL | absolute | D:/clients/oakley/test1.txt | ✅ Success | ✅ SUCCESS | None |
| FIRST | absolute | D:/clients/salem/test2.txt | ✅ Success | ❌ FAIL | "File has been unexpectedly modified" |
| AFTER REL | absolute | D:/clients/salem/test2.txt | ✅ Success | ✅ SUCCESS | None |
| FIRST | absolute | D:/clients/willdev/test3.txt | ✅ Success | ❌ FAIL | "File has been unexpectedly modified" |
| AFTER REL | absolute | D:/clients/willdev/test3.txt | ✅ Success | ✅ SUCCESS | None |
| FIRST | absolute | D:/clients/stateman/test4.txt | ✅ Success | ❌ FAIL | "File has been unexpectedly modified" |
| AFTER REL | absolute | D:/clients/stateman/test4.txt | ✅ Success | ✅ SUCCESS | None |

ROOT CAUSE IDENTIFIED:

File Caching/State Bug: The Edit tool has a caching or file state tracking issue where:

1. First absolute path edit on a file fails with "File has been unexpectedly modified"
2. After ANY successful relative path edit on the same file, absolute path edits work perfectly
3. This suggests the Edit tool maintains some kind of file state cache that gets properly initialized by relative path operations

BUG PATTERN:

• ❌ Cold Start Absolute Edit: Always fails
• ✅ Warmed Up Absolute Edit: Always works (after any successful relative edit)
• ✅ Relative Edit: Always works regardless of state

WORKAROUND: Before editing with absolute paths, always perform a successful relative path edit first to "warm up" the file state cache.

oooof first time ever I actually have to downgrade. just cannot edit anything.

Version 1.0.112 seems to have fixed the issue for me. Thanks!

Version 1.0.112 seems to have fixed the issue for me. Thanks!

No. it is not over. it happens randomly.

I believe this happens when claude tries to edit a file with an mtime in the future - for example, if you copied it from a box in a different timezone or a LLM generated a zip file for you with UTC timestamps but you are in a negative timezone. Workaround is to just touch all the files, or if you're crazy like me I made this hack: https://github.com/markatto/node-stability

Yeah, it is still happening, but it is better. I am having some luck with this prompt:

Current Claude Code Bug Workaround
"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."

The prompt provided by @trueshot is working properly.

Thank you @trueshot !!

In my opinion, this shouldn't be closed because this issue wasn't fixed on the CC side.

I agree it should not be closed. It is absolutely broken.

Still happening in 113, need urgent attention! I rolled back to 110.

<img width="852" height="145" alt="Image" src="https://github.com/user-attachments/assets/1af8a1dc-8ecb-4fb1-8756-3a597e00f76c" />

@Gtm-dev-market you mind keeping this open for everybody's benefit please? A prompt is not a fix.

1.0.113 still has this issue.

1.0.113 still has this issue.

1.0.113 still has an issue

Temporary workaround with "use relative path" prompt works, but it is not a fix.

Same, still have the issue.

1.0.115 same

1.0.115 same

same. but the prompt fix still works. interesting. it is probably originated from model, not just from prompts.

Still have issue

+1

Same issue here: Claude Code v1.0.115

1.0.113 still has an issue Temporary workaround with "use relative path" prompt works, but it is not a fix.

This helped me as a temp fix.

What a pain. There are two methods I use. tell it to use relative paths, but doesn't always work. then tell it to use windows path with backslashes. Usually one of the two will work. I have been doing as little as possible in this environment. If you have a WSL option, that seems to work fine, at least it doesn't have file update problems. I can't use it because I have an ec2 Windows 2025, and WSL is not an option. Thus I am stuck with this problem. Mac works with no problems.

What a pain. There are two methods I use. tell it to use relative paths, but doesn't always work. then tell it to use windows path with backslashes. Usually one of the two will work. I have been doing as little as possible in this environment. If you have a WSL option, that seems to work fine, at least it doesn't have file update problems. I can't use it because I have an ec2 Windows 2025, and WSL is not an option. Thus I am stuck with this problem. Mac works with no problems.

WSL2 fix it?

1.0.117 same

WSL2 fix it?

not the point. sure thing there's a couple of workarounds. but it's a clear regression.

btw I hope people keep reporting this via /bug or /feedback

1.0.117 same > WSL2 fix it? not the point. sure thing there's a couple of workarounds. but it's a clear regression. btw I hope people keep reporting this via /bug or /feedback

I do not see any macos user reporting the problem. it must be something wrong with model, I suspect. Codex does not report any filesytem error in windows.

Anyone notice this bug. i found a fix probably. all you have to do is to install windows native binary claude code instead of "npm" something claude code. follow instructions in Anthropic instructions.

Anyone notice this bug. i found a fix probably. all you have to do is to install windows native binary claude code instead of "npm" something claude code. follow instructions in Anthropic instructions.

But I feel like there's no difference.

> Anyone notice this bug. i found a fix probably. all you have to do is to install windows native binary claude code instead of "npm" something claude code. follow instructions in Anthropic instructions. But I feel like there's no difference.

After binary installation, you come across again?

What a pain. There are two methods I use. tell it to use relative paths, but doesn't always work. then tell it to use windows path with backslashes. Usually one of the two will work. I have been doing as little as possible in this environment. If you have a WSL option, that seems to work fine, at least it doesn't have file update problems. I can't use it because I have an ec2 Windows 2025, and WSL is not an option. Thus I am stuck with this problem. Mac works with no problems.

I use WSL in Windows 11 Pro and have the exact same problem.

Calude code is unusable with this bug I hope they fix it soon

Calude code is unusable with this bug I hope they fix it soon

I tried binary installation, problem was solved. after which, i decided to go back npm and check whether binary fix the bug.
and when i switched back to npm installation, the problem never come back.

It is really strange.

Está uma porcaria o claude! Impossível usar com esse problema " Error: File has been unexpectedly modified. Read it again before attempting to write it."

.119 and counting

https://github.com/anthropics/claude-code/issues/7935 https://github.com/anthropics/claude-code/issues/7920 https://github.com/anthropics/claude-code/issues/7918 #7883

Still a big problem.

Why was this closed? It's still not fixed and more and more people are duplicating this bug report. I've started to have to use claude to find a problem and cursor or codex to solve it.

<img width="1630" height="566" alt="Image" src="https://github.com/user-attachments/assets/428605ac-2669-49f3-9288-0845341c1ebd" />

I saw elsewhere that someone said using this prompt will fix it, I haven't gotten a chance to test it yet though. "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."

I place this workaround in CLAUDE.md and it has worked so far:

````md

CRITICAL: File Editing on Windows

⚠️ MANDATORY: Always Use Backslashes on Windows for File Paths

When using Edit or MultiEdit tools on Windows, you MUST use backslashes (\) in file paths, NOT forward slashes (/).

❌ WRONG - Will cause errors:

Edit(file_path: "D:/repos/project/file.tsx", ...)
MultiEdit(file_path: "D:/repos/project/file.tsx", ...)

✅ CORRECT - Always works:

Edit(file_path: "D:\repos\project\file.tsx", ...)
MultiEdit(file_path: "D:\repos\project\file.tsx", ...)

````

My experience is strange. Sometimes it doesn't seem to have problems, sometimes it can't seem to do anything with files. Generally, it seems to be getting better, but sometimes it just doesn't work well at all.

do not use claude code, then you dont have this issue anymore. Yes I am joking, cause this bug annoys me so much

I place this workaround in CLAUDE.md and it has worked so far: ## CRITICAL: File Editing on Windows ### ⚠️ MANDATORY: Always Use Backslashes on Windows for File Paths When using Edit or MultiEdit tools on Windows, you MUST use backslashes (\) in file paths, NOT forward slashes (/). #### ❌ WRONG - Will cause errors: `` Edit(file_path: "D:/repos/project/file.tsx", ...) MultiEdit(file_path: "D:/repos/project/file.tsx", ...) ` #### ✅ CORRECT - Always works: ` Edit(file_path: "D:\repos\project\file.tsx", ...) MultiEdit(file_path: "D:\repos\project\file.tsx", ...) ``

I never experienced this before today, but often it would use update (edit/multi edit) and then insta fail before trying a new approach. Today it really seems to want to keep using update and then getting stuck in a loop. The first edit will succeed. The second edit will fail forever typically. Added this to test and yes the workaround works a treat, but honestly wish it didn't need to be there.

Why we should enter that prompt manually on CLAUDE.md?
I can't understand why this issue was closed.

@anthropics @dicksontsai hey, sure thing there's a lot on your plate. But look at this one non-esoteric thing people struggle with please..

https://github.com/anthropics/claude-code/issues/7935 https://github.com/anthropics/claude-code/issues/7920 https://github.com/anthropics/claude-code/issues/7918 https://github.com/anthropics/claude-code/issues/7883

Did you try updating to claude Code 2 "claude update" I haven't had problems since.

spoke too soon.
Update(c:\buffalo\d\clients\gological\js\components\universalnavbar.js)
⎿  Error: File has been unexpectedly modified. Read it again before attempting to write it.

this thing is still plauging me. It is not acceptable on a 200$ per month.

<img width="1367" height="106" alt="Image" src="https://github.com/user-attachments/assets/f0b72fc5-68e5-4e17-a5df-cc01bf823571" />

why has this been closed when it is still occurring?

I get this constantly on a Max plan.

Getting this issue as well. Don't usually use CC but did today and ya it just fails every edit first time. Windows/Bash

Had the same issue since it upgraded to 2.0.8, editing almost impossible. Downgraded to 2.0.5 and disabled auto update for now.

Windows terminal / git bash

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.