{"version":"2.1.280","anchor":"read-tools-staleness-check-is-now-async-and-reads-the-file","canonical_anchor":"read-tools-staleness-check-is-now-async-and-reads-the-file","heading":"Disk-modification staleness checks for file reads and writes are now properly async","tier":"notice","area":"Elsewhere","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.280\/e\/read-tools-staleness-check-is-now-async-and-reads-the-file","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.280","markdown":"### Disk-modification staleness checks for file reads and writes are now properly async\n\nThe 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.\n\n**What**\n\n- 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`).\n\n- The Edit\/Write external-modification guard is now only invoked when both the file handle and its read content are non-null, is properly `await`ed 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.\n\n**Why**\n\nWithout 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.\n\n- Area: Elsewhere\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 1\/5"}