[Bug] File Edit Fails on Windows with Unexpected Modification Error

#7935

It can temporarily be fixed by entering this:
"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", ...)

````

In my testing the bug appeared on 1.0.111 and 1.0.110 . The following changelog sounds like whatever this shell fix was is the cause of the windows File editing issues. The posted workaround does not even work for me and shouldn't be necessary.

## 1.0.111

- /model now validates provided model names
- Fixed Bash tool crashes caused by malformed shell syntax parsing

https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md?plain=1#L89-L92

@JosiahSiegel are we sure that is actually the cause of this? Sometimes backslashes work. I am wondering if it might have to do with some other process touching the files, like shell snapshots or something.

I have also experienced Read() failing too.

I am on V2.0.22. it seems very random, some sessions have no issues, while others become completely useless. Restarting Claude doesn't always work. Sometimes I have to restart my whole machine.

It is mostly an issue when using Git Bash as shell (default), then it tries to use a mix of Windows and Linux semantics in all kinds of commands first. When they fail, it tries again with bash format and all is fine again.
Ofte have commands with 2>nul, which creates an empty nul file which Windows has trouble deleting and cause all kinds of issues.
So think it is an issue with this mixed Windows env and Bash which causes strange outcomes.

@ant-kurt @wolffiex

I've been testing Windows path issues (see #7935) and wondering if this is the same bug or separate.

#7935 (Cache Bug):

• Root cause: C:/path vs C:\path treated as different cache keys
• Trigger: Reading with forward slashes poisons cache
• Workaround: Always use backslash paths for Read

#7918 (This Issue):

• Same symptom: "File has been unexpectedly modified"
• Same workaround: Use backslash paths

In case anyone is looking for a workaround (there have been posts for this before, but they haven't worked reliably for me): I also gave examples about correct / incorrect usage in my CLAUDE.md, but I used the tool_use message content format, in the hopes that this would more reliably be followed (under the assumption that it is closer to the actual tool call produced by the model). So far it has worked well for me:

````markdown

⚠️ CRITICAL Bug Workaround

CRITICAL: Follow these guidelines when using tools operating on file paths EXCEPT Bash in any skill or agent. Otherwise, they will not work correctly.

• When referencing file paths in tool calls, ALWAYS use the Windows-style paths with backslashes (\), as we're running on Windows.
• When referencing paths to the home directory, ALWAYS EXPAND the tilde symbol (~) representing the home directory to the full path, e.g., C:\Users\some.user.

Applies To

• Edit
• Glob
• Grep
• Read

Examples (CRITICAL Bug Workaround)

✅ Correct (File Paths)

{
    "type": "tool_use",
    "id": "...",
    "name": "Read",
    "input": {
        "file_path": "C:\\path\\to\\some\\file.txt"
    }
}

{
    "type": "tool_use",
    "id": "...",
    "name": "Edit",
    "input": {
        "file_path": "C:\\path\\to\\some\\file.txt",
        "old_string": "...",
        "new_string": "..."
    }
}

❌ Incorrect (File Paths)

{
    "type": "tool_use",
    "id": "...",
    "name": "Read",
    "input": {
        "file_path": "/c/path/to/some/file.txt"
    }
}

... (rest omitted)

````

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.

The issue is definitely still happening.

I confirm too, still happening, last version of CC.

It's happening to me as well (oddly, it just started happening to me fairly recently, within the last week or two).

I just tried the workaround and it seems to be successful for me, at least for now.

Issue is still happening. Typical example of second class Windows support.

i get Error: File has been unexpectedly modified. Read it again before attempting to write it. on each new file. Even of it has accept to write it cant do it IN ONE SESSION.
my ass is going to explode. it can update some file and then some how on my new message it cant write anymore. WTF ????

i get Error: File has been unexpectedly modified. Read it again before attempting to write it. on each new file. Even of it has accept to write it cant do it IN ONE SESSION. my ass is going to explode. it can update some file and then some how on my new message it cant write anymore. WTF ????

Just press Esc and type: Use full windows paths for all tool calls.

> i get Error: File has been unexpectedly modified. Read it again before attempting to write it. on each new file. Even of it has accept to write it cant do it IN ONE SESSION. > my ass is going to explode. it can update some file and then some how on my new message it cant write anymore. WTF ???? Just press Esc and type: Use full windows paths for all tool calls.

<img width="877" height="293" alt="Image" src="https://github.com/user-attachments/assets/691e61f2-74b6-4484-aef6-c9ffe7fb4506" />

this is full paths, no ?

As described above the fix (PATCH) for now is to add that prompt when that happen:

use absolute path to modify files

This patch the issue.

> > i get Error: File has been unexpectedly modified. Read it again before attempting to write it. on each new file. Even of it has accept to write it cant do it IN ONE SESSION. > > my ass is going to explode. it can update some file and then some how on my new message it cant write anymore. WTF ???? > > > Just press Esc and type: Use full windows paths for all tool calls. <img alt="Image" width="877" height="293" src="https://private-user-images.githubusercontent.com/65418952/529801773-691e61f2-74b6-4484-aef6-c9ffe7fb4506.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NjY1NDY0MjgsIm5iZiI6MTc2NjU0NjEyOCwicGF0aCI6Ii82NTQxODk1Mi81Mjk4MDE3NzMtNjkxZTYxZjItNzRiNi00NDg0LWFlZjYtYzlmZmU3ZmI0NTA2LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTEyMjQlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUxMjI0VDAzMTUyOFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWQ2NDM2MzUyZTIwZDcwODI1Nzc2YjRiNjRiMTY0Y2ZiNzJiMTU3MjI2MzUzYmQyNDlmYmY5MDI2OWRkMjY4NmEmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.HI4NUQhsoLhamA8kpTjAu9b7sZT8H72yK5yCz3eHODU"> this is full paths, no ?

Full _Windows_ paths. It's using unix-style forward slashes instead of Windows backslashes. It's probably translating them to the correct Windows style when it actually makes the edit, but whatever mechanism is being used to detect changes probably isn't, which is breaking it.

STILL happening - fresh install (new user here) - instantly hit this issue on Windoze 11. This comment unblocked the following SHOWSTOPPER priority error:

_Error: File has been unexpectedly modified. Read it again before attempting to write it._

Comment (in this thread) handed to Opus 4.5 as instructions:

https://github.com/anthropics/claude-code/issues/7918#issuecomment-3315275618

It can temporarily be fixed by entering this: (Hand this sentence to Claude / Opus 4.5):

"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 is still occurring in Claude 2.1.4

Simpler fix than forcing backslashes - just use relative paths

I found a much simpler workaround than the absolute paths + backslashes approach. Add this to your CLAUDE.md and it works reliably:

## File editing on Windows (CRITICAL FIX)

**ALWAYS use RELATIVE paths** for Read and Edit tools:

✅ CORRECT:
- Read("src/components/Button.tsx")
- Edit("src/components/Button.tsx", ...)
- Read("config/settings.json")
- Edit("config/settings.json", ...)

❌ INCORRECT:
- Read("C:/Users/.../src/components/Button.tsx")
- Edit("C:/Users/.../src/components/Button.tsx", ...)

**Rules:**
1. Use paths relative to your working directory
2. Use the SAME exact path in Read and Edit
3. Avoid absolute paths with forward slashes

**If error persists:** Re-read with the SAME relative path.

Why this is simpler

The current workaround (forcing C:\path\with\backslashes) works, but requires:

• Remembering to escape backslashes
• Full absolute paths every time
• Different approach than Bash commands

Relative paths work regardless of separator and are how most devs naturally reference files.

# ✅ What I use now - simple and works
Read("src/file.tsx")
Edit("src/file.tsx", ...)

# ✅ Old workaround - works but complicated
Read("C:\\Users\\name\\project\\src\\file.tsx")
Edit("C:\\Users\\name\\project\\src\\file.tsx", ...)

# ❌ What fails
Read("C:/Users/name/project/src/file.tsx")
Edit("C:/Users/name/project/src/file.tsx", ...)

Full technical analysis in #10437 if anyone's curious, but the prompt above is all you need.

Hope this saves others the headaches I had with backslash escaping!

terrible. it is halting all of my progress

@benjaminmbrown Did you try the workaround I posted above? I was in the same situation - once I switched to relative paths, never had the issue again!