Edit tool falsely claims 'File has been unexpectedly modified' on Opus 4.5

[eldoclimber]

Environment

• Claude Code with Opus 4.5 (claude-opus-4-5-20251101)
• Platform: win32 (MSYS_NT-10.0-26100)

Steps to Reproduce

1. Check file hash and modify time: md5sum file && stat file
2. Use Read tool to read the file
3. Immediately check hash and modify time again (identical - file unchanged)
4. Use Edit tool with valid old_string that exists in the file
5. Edit fails with 'File has been unexpectedly modified'

Evidence

• File: H:/skydiving-manifest/src/ManifestApp.Client/Pages/Login.razor
• MD5 hash before Read: fe48316a07481bc25545326baa745bac
• MD5 hash after Read: fe48316a07481bc25545326baa745bac (identical)
• Modify time before: 2025-11-30 23:32:47.746767100 -0700
• Modify time after: 2025-11-30 23:32:47.746767100 -0700 (identical)
• Only Access time changed (expected behavior for a read operation)

Observed Behavior

The Edit tool rejects the edit claiming the file was modified, even though:

• The file content hash is identical
• The file modify timestamp is identical
• No external processes modified the file (VS Code closed, File Explorer closed)

Expected Behavior

Edit should succeed since the file contents match what was read.

Additional Context

• User reports this issue started occurring with Opus 4.5
• Issue is reproducible across multiple files in the same session
• The Write tool also fails with 'File has not been read yet' immediately after a successful Read
• Workaround using bash heredoc (cat > file << 'EOF') works, suggesting the issue is in the Edit/Write tool's internal state tracking, not file system permissions

[NullCoward]

Additional Data Point

Experiencing the same issue on Windows (MINGW64_NT-10.0-26100) with Opus 4.5.

Observation: Context Compression Correlation

In my case, this issue appears to be triggered or exacerbated by context compression/summarization. The pattern observed:

1. Long conversation with many file Read/Edit operations
2. Context compression occurs (automatic or due to context limit)
3. All subsequent Edit/Write operations fail with "File has been unexpectedly modified"
4. Even freshly reading the file doesn't fix it - Edit immediately after Read still fails
5. Issue persists for the remainder of the session

Supporting Evidence: Stale Internal State

In the same sessions where this Edit bug occurs, I also see stale background bash reminders - system shows 7 "background bash shells" as "running" with "new output available", but:

• KillShell reports they're already dead
• tasklist | grep python shows no matching processes
• PowerShell child process inspection shows only 1 actual shell

This suggests internal state tracking becomes corrupted/stale after context compression, affecting both:

1. File checksum/hash tracking (causing false "modified" errors)
2. Background process tracking (causing phantom shell reminders)

Workaround Confirmed

Using Python via Bash to directly write files (python -c "open('file','w').write(content)") bypasses the issue completely, confirming this is internal tool state, not OS-level file locking.