{"version":"2.1.283","anchor":"readfilestate-re-sync-after-hook-edits-now-also-covers-top-o","canonical_anchor":"readfilestate-re-sync-after-hook-edits-now-also-covers-top-o","heading":"Fewer false \"file changed\" edit failures after formatters and memory writes","tier":"notice","area":"File Editing","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.283\/e\/readfilestate-re-sync-after-hook-edits-now-also-covers-top-o","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.283","markdown":"### Fewer false \"file changed\" edit failures after formatters and memory writes\n\nAfter a hook or the background memory pass rewrites a file, Claude Code updates its record of that file, so a later edit no longer fails as stale\n\n**Unclear.** It is not clear how often the background memory pass runs or what switches it on.\n\n**What**\n\nClaude Code keeps a record of which files it has read and what they contained. It uses that record to refuse an edit when the file seems to have changed since it was last read. That is a \"stale\" failure.\n\nA hook is a command you configure to run automatically at a set point. A `PostToolUse` hook runs after a tool call succeeds, and a tool call is one action Claude takes, such as editing a file. When a `PostToolUse` hook such as a formatter rewrites a file, Claude Code updates its record to match. This update now covers two more cases:\n\n- Files Claude had read only partly, when that partial read started at line 1 and had no line limit. Before, any partial read skipped the update.\n\n- Files written by the background memory pass, the step where Claude Code saves notes to its memory files. Before, these were not updated at all.\n\n**Why**\n\nIn both cases, Claude's next edit to the file could fail because the file looked changed, even though the only change came from a formatter or from Claude Code's own memory writing. You should see fewer of these failed edits.\n\n- Area: File Editing\n- Tier: You'll notice\n- Useful: 3\/5\n- Signal: 1\/5"}