Edit tool enters retry loop on stale file reads, causing hundreds of consecutive failures

[anandgupta42]

Problem

The edit tool fails with the following error when a file has been modified between the last read and the edit attempt:

File <path> has been modified since it was last read.
Last modification: 2026-03-24T20:13:31.584Z
Last read: 2026-03-24T20:13:10.163Z
Please read the file again before modifying it.

This is expected behavior for a single occurrence — the safety check is correct. The bug is that the agent does not recover gracefully: it retries the edit repeatedly without re-reading the file, resulting in long bursts of the same failure.

Scale

• 984 occurrences in the last 7 days across multiple versions
• Failures happen in bursts — up to 295 consecutive failures in a 5-minute window
• Average burst length: 89.5 failures
• 11 distinct burst episodes observed

Breakdown by version and tool

Tool	CLI Version	Occurrences
edit	0.5.7	590
edit	0.5.3	156
edit	0.5.2	123
edit	0.5.4	74
write	0.5.3	41

Root cause hypothesis

When a file changes on disk (e.g., by a formatter, linter, or file watcher) between the read and edit calls, the edit is correctly rejected. However:

1. The agent retries the edit with the same stale content instead of re-reading the file first
2. There is no backoff or retry limit — it keeps attempting the same failing edit
3. This burns through tokens and tool calls unnecessarily

Suggested fix

1. When the edit tool returns a "modified since last read" error, the agent should automatically re-read the file before retrying
2. Add a retry limit (e.g., 3 attempts) for stale file errors before giving up or asking the user
3. Consider adding a short delay before retry to allow file watchers/formatters to finish