Edit Tool Fails with 'File Unexpectedly Modified' on Windows/Git Bash

Resolved 💬 7 comments Opened Nov 15, 2025 by vimholic Closed Jan 20, 2026

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:

  1. Claude Code executes each Bash command as a login shell (bash -l)
  2. This causes .bash_profile to be sourced on every Bash tool invocation
  3. File system access during profile loading updates file timestamps
  4. 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

View original on GitHub ↗

This issue has 7 comments on GitHub. Read the full discussion on GitHub ↗