Disk-modification staleness checks for file reads and writes are now properly async
The checks that detect whether a file changed on disk since it was last read are now async and use an actual disk mtime lookup instead of firing without waiting.
You'll noticeTier: how much it should matter to you
2Useful: my rating, 1 to 5
1Signal: worth watching, 1 to 5
ElsewhereArea: what it touches
ImprovementsKind: in v2.1.280,
ImprovementsSection of the release
What
The Read tool's guard that decides whether a previously-read file has since changed on disk was synchronous and compared in-memory timestamps; it's now async and calls a new disk mtime lookup (via an ioPath).
The Edit/Write external-modification guard is now only invoked when both the file handle and its read content are non-null, is properly awaited instead of being fired without waiting, and also passes a new ioPath field; the returned state now includes a remedy: { kind: "staged_for_review", path: ... } field.
Why
Without awaiting these checks, a write or edit could proceed before Claude Code actually knew whether the file had changed on disk, risking silently overwriting external changes.
