›_ Claude Code Issues
Claude Code Issues / #12891

[BUG] Edit Tool Fails with 'File unexpectedly modified' on Windows (Access Time Update Issue)

Resolved 💬 9 comments Opened Dec 2, 2025 by krohan81 Closed Feb 9, 2026

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

  1. Create any text file
  2. Use the Read tool to read the file
  3. Immediately use the Edit tool to modify the file
  4. 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:

  1. Only checking mtime (modify time), not atime (access time)
  2. Using content hash comparison instead of/in addition to timestamps
  3. 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

  1. Create any text file
  2. Use the Read tool to read the file
  3. Immediately use the Edit tool to modify the file
  4. 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:

  1. Only checking mtime (modify time), not atime (access time)
  2. Using content hash comparison instead of/in addition to timestamps
  3. 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

  1. Create any text file
  2. Use the Read tool to read the file
  3. Immediately use the Edit tool to modify the file
  4. 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:

  1. Only checking mtime (modify time), not atime (access time)
  2. Using content hash comparison instead of/in addition to timestamps
  3. 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_

View original on GitHub ↗

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