Edit Tool Fails with 'File Unexpectedly Modified' on Windows/Git Bash
Edit Tool Fails with "File Unexpectedly Modified" Error on Windows/Git Bash
Description
The Edit tool consistently fails with the error "File has been unexpectedly modified. Read it again before attempting to write it." even when:
- The file content has not changed
- No other process is modifying the file
- Edit is called immediately after Read with no intermediate operations
This makes the Edit tool essentially unusable on Windows with Git Bash, forcing users to use bash commands (cat, sed, etc.) instead.
Environment
- OS: Windows 11
- Shell: Git Bash (MSYS2)
- Claude Code Version: Latest (as of 2025-11-15)
- Terminal: PowerShell / Windows Terminal
Steps to Reproduce
# 1. Create a test file
cat > ~/test.txt << 'EOF'
Line 1
Line 2
EOF
# 2. Read the file
Read: ~/test.txt
# 3. Immediately attempt to edit (no other operations)
Edit: ~/test.txt
old_string: "Line 2"
new_string: "Line 2 Modified"
# Result: ❌ "File has been unexpectedly modified" error
Expected Behavior
The Edit tool should successfully modify the file since:
- No actual modifications occurred between Read and Edit
- File content is unchanged
- Only Claude Code has accessed the file
Actual Behavior
Edit tool fails with timestamp mismatch error.
Root Cause Analysis
After investigation, we found:
- Claude Code executes each Bash command as a login shell (
bash -l) - This causes
.bash_profileto be sourced on every Bash tool invocation - File system access during profile loading updates file timestamps
- Edit tool's timestamp check detects this change and rejects the edit
Evidence:
# Each Bash command shows this (from .bash_profile):
✓ UTF-8 encoding functions loaded: win, pwsh
# Shell flags confirm login shell:
$-: hmtBc (contains 'l' characteristics)
Impact
- High: Edit tool is completely broken for Windows/Git Bash users
- Affects all files, not just shell configuration files
- Forces workarounds using bash commands instead of built-in tools
- Reduces productivity and developer experience
Suggested Solutions
Option 1: Relax Timestamp Checking (Recommended)
Add a grace period (1-2 seconds) or check content hash instead of just timestamps.
Option 2: Use Content-Based Verification
Compare file content hash instead of relying solely on timestamps.
Option 3: Document Behavior
If this is intentional, document that Edit tool requires no intermediate operations between Read and Edit.
Option 4: Optimize Bash Invocation
Avoid using login shell (bash -l) for Bash tool commands, or provide an option to configure shell invocation.
Current Workaround
Users must use bash commands instead of Edit tool:
# Instead of Edit tool, use:
sed -i 's/old_string/new_string/' file.txt
# or
cat > file.txt << 'EOF'
new content
EOF
Additional Context
- Windows has
DisableLastAccess = 1(last access time updates disabled) - Issue occurs even with minimal
.bash_profile - Problem persists across different file types (source code, config files, etc.)
Test Case
A reproducible test case is available in the bug report file created during investigation.
Related Issues
This may be related to how Claude Code handles file system operations on Windows, particularly with MSYS2/Git Bash environments.
---
Priority: High
Component: Edit Tool
Platform: Windows + Git Bash
This issue has 7 comments on GitHub. Read the full discussion on GitHub ↗