[BUG] Edit Tool Fails with 'File unexpectedly modified' on Windows (Access Time Update Issue)
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
The Edit tool consistently fails with "File has been unexpectedly modified. Read it again before attempting to write
it." immediately after a successful Read operation on Windows 11.
## Environment
- Claude Code Version: 2.0.56
- OS: Windows 11
- Platform: win32
- Feature Flag:
tengu_use_file_checkpoints: true(from cachedStatsigGates)
## Steps to Reproduce
- Create any text file
- Use the Read tool to read the file
- Immediately use the Edit tool to modify the file
- Edit fails with "File has been unexpectedly modified"
## Minimal Reproduction
Step 1: Create file
echo "test content" > test.txt
Step 2: Read (succeeds)
Read tool: test.txt → returns "test content"
Step 3: Edit (fails)
Edit tool: old_string="test content", new_string="modified"
→ ERROR: "File has been unexpectedly modified. Read it again before attempting to write it."
## Test Results
| Test | Result |
|------|--------|
| Issue occurs in git repo | Yes |
| Issue occurs outside git repo | Yes |
| Issue occurs with autocrlf=false | Yes |
| Issue occurs with parallel Read+Edit | Yes |
| sed/bash workarounds work | Yes |
## Root Cause Analysis
Windows has Last Access Time Updates ENABLED by default (DisableLastAccess = 2). This means:
```bash
$ fsutil behavior query disablelastaccess
DisableLastAccess = 2 (System Managed, Last Access Time Updates ENABLED)
When a file is read, Windows updates its access timestamp:
- Before read: Access: 2025-12-02 09:10:01
- After read: Access: 2025-12-02 09:10:03
If the tengu_use_file_checkpoints feature uses file metadata (including access time) for modification detection, this
would cause false positives on Windows.
Expected Behavior
The Edit tool should successfully modify a file immediately after reading it, since only the access time changed (not
the content or modify time).
Actual Behavior
Every Edit attempt fails, even when the file content has not changed.
Workaround
Use sed via the Bash tool instead of the Edit tool:
sed -i 's/old_string/new_string/' filename.txt
Suggested Fix
If using file metadata for checkpoint validation, consider:
- Only checking mtime (modify time), not atime (access time)
- Using content hash comparison instead of/in addition to timestamps
- Adding Windows-specific handling for access time updates
Additional Context
- This appears to be a regression or new behavior
- The tengu_use_file_checkpoints: true flag in settings suggests this is related to a file checkpoint feature
- The issue affects ALL files, not just specific file types or locations
What Should Happen?
The Edit tool consistently fails with "File has been unexpectedly modified. Read it again before attempting to write
it." immediately after a successful Read operation on Windows 11.
## Environment
- Claude Code Version: 2.0.56
- OS: Windows 11
- Platform: win32
- Feature Flag:
tengu_use_file_checkpoints: true(from cachedStatsigGates)
## Steps to Reproduce
- Create any text file
- Use the Read tool to read the file
- Immediately use the Edit tool to modify the file
- Edit fails with "File has been unexpectedly modified"
## Minimal Reproduction
Step 1: Create file
echo "test content" > test.txt
Step 2: Read (succeeds)
Read tool: test.txt → returns "test content"
Step 3: Edit (fails)
Edit tool: old_string="test content", new_string="modified"
→ ERROR: "File has been unexpectedly modified. Read it again before attempting to write it."
## Test Results
| Test | Result |
|------|--------|
| Issue occurs in git repo | Yes |
| Issue occurs outside git repo | Yes |
| Issue occurs with autocrlf=false | Yes |
| Issue occurs with parallel Read+Edit | Yes |
| sed/bash workarounds work | Yes |
## Root Cause Analysis
Windows has Last Access Time Updates ENABLED by default (DisableLastAccess = 2). This means:
```bash
$ fsutil behavior query disablelastaccess
DisableLastAccess = 2 (System Managed, Last Access Time Updates ENABLED)
When a file is read, Windows updates its access timestamp:
- Before read: Access: 2025-12-02 09:10:01
- After read: Access: 2025-12-02 09:10:03
If the tengu_use_file_checkpoints feature uses file metadata (including access time) for modification detection, this
would cause false positives on Windows.
Expected Behavior
The Edit tool should successfully modify a file immediately after reading it, since only the access time changed (not
the content or modify time).
Actual Behavior
Every Edit attempt fails, even when the file content has not changed.
Workaround
Use sed via the Bash tool instead of the Edit tool:
sed -i 's/old_string/new_string/' filename.txt
Suggested Fix
If using file metadata for checkpoint validation, consider:
- Only checking mtime (modify time), not atime (access time)
- Using content hash comparison instead of/in addition to timestamps
- Adding Windows-specific handling for access time updates
Additional Context
- This appears to be a regression or new behavior
- The tengu_use_file_checkpoints: true flag in settings suggests this is related to a file checkpoint feature
- The issue affects ALL files, not just specific file types or locations
Error Messages/Logs
Steps to Reproduce
The Edit tool consistently fails with "File has been unexpectedly modified. Read it again before attempting to write
it." immediately after a successful Read operation on Windows 11.
## Environment
- Claude Code Version: 2.0.56
- OS: Windows 11
- Platform: win32
- Feature Flag:
tengu_use_file_checkpoints: true(from cachedStatsigGates)
## Steps to Reproduce
- Create any text file
- Use the Read tool to read the file
- Immediately use the Edit tool to modify the file
- Edit fails with "File has been unexpectedly modified"
## Minimal Reproduction
Step 1: Create file
echo "test content" > test.txt
Step 2: Read (succeeds)
Read tool: test.txt → returns "test content"
Step 3: Edit (fails)
Edit tool: old_string="test content", new_string="modified"
→ ERROR: "File has been unexpectedly modified. Read it again before attempting to write it."
## Test Results
| Test | Result |
|------|--------|
| Issue occurs in git repo | Yes |
| Issue occurs outside git repo | Yes |
| Issue occurs with autocrlf=false | Yes |
| Issue occurs with parallel Read+Edit | Yes |
| sed/bash workarounds work | Yes |
## Root Cause Analysis
Windows has Last Access Time Updates ENABLED by default (DisableLastAccess = 2). This means:
```bash
$ fsutil behavior query disablelastaccess
DisableLastAccess = 2 (System Managed, Last Access Time Updates ENABLED)
When a file is read, Windows updates its access timestamp:
- Before read: Access: 2025-12-02 09:10:01
- After read: Access: 2025-12-02 09:10:03
If the tengu_use_file_checkpoints feature uses file metadata (including access time) for modification detection, this
would cause false positives on Windows.
Expected Behavior
The Edit tool should successfully modify a file immediately after reading it, since only the access time changed (not
the content or modify time).
Actual Behavior
Every Edit attempt fails, even when the file content has not changed.
Workaround
Use sed via the Bash tool instead of the Edit tool:
sed -i 's/old_string/new_string/' filename.txt
Suggested Fix
If using file metadata for checkpoint validation, consider:
- Only checking mtime (modify time), not atime (access time)
- Using content hash comparison instead of/in addition to timestamps
- Adding Windows-specific handling for access time updates
Additional Context
- This appears to be a regression or new behavior
- The tengu_use_file_checkpoints: true flag in settings suggests this is related to a file checkpoint feature
- The issue affects ALL files, not just specific file types or locations
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
2.0.55
Claude Code Version
2.0.56
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Terminal.app (macOS)
Additional Information
_No response_
9 Comments
I've alreadt said this in another thread, but for using the update/edit tool on windows, tell the model to use backslashes for paths instead of forward slashes. It may appear that it already has backslashes, but it doesn't seem to actually have them since telling the model to use backslashes just works.
While backslashes sometimes work they can also cause big problems. Really claude needs to switch to using the universal path format of:
c:/program files/my_app/whatever.txtthis works both with msys bash tools and with windows it has no escaping problems as there are no backslashes.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.
still an issue
Still a problem with 2.1.2 on Windows.
This issue has been automatically closed due to 60 days of inactivity. If you're still experiencing this issue, please open a new issue with updated information.
seems @github-actions failed on this one.
This issue was closed incorrectly despite recent human comments. This behavior of the bot is reported at https://github.com/anthropics/claude-code/issues/16497. Please upvote that issue, so maybe it gets noticed.
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.