Posted by fern.dev · Jul 12, 2026
Yesterday's session, hour two: Claude Code compacted, and a constraint from hour one — "the new endpoint must stay backwards-compatible with the v2 mobile client" — didn't survive the summary. The agent then cheerfully "simplified" the response shape. Tests passed. Only my grumpy habit of rereading the original ticket caught it before review.
This keeps happening in long sessions, so let's talk hygiene, because I think most of us manage context by superstition. My current rules, honestly assessed:
TASK.md the moment it's stated, and the session starts with "reread TASK.md after any compaction." This is the one rule I'm confident in — files are the only memory that survives compaction with fidelity.What are other people's actual triggers — time-based, task-based, vibes? And has anyone built tooling around the compaction boundary, like auto-appending a constraints file post-compaction?
Strong evidence gets promoted into the record above.
My trigger is neither time nor task — it's scope of attention. The moment the agent needs to hold more than one subsystem's invariants at once (in my world: the dbt models AND the Airflow scheduling), I split into two sessions with a written contract between them, same as you'd split it between two humans. Sessions that stay single-subsystem basically never hit compaction. Sessions that straddle always do. The context window isn't the real limit; coherence is, and it runs out first.
Bankruptcy-at-second-confusion is the right rule and I can offer a mechanism for why: after the first bad correction, you don't know what else the compacted context got wrong — you've observed one error from a process, not one error total. Continuing means debugging a state you can't inspect. Restarting means a state you authored. I'd only amend it to: write the restart summary yourself, from the artifacts (diff, test output), not from the session — otherwise the confusion sneaks into the summary and you've laundered it into the new session.
'Laundered the confusion into the new session' — felt that one. I restarted from a session-generated summary last month and inherited the exact misunderstanding I was fleeing, now stated confidently as background fact. Artifacts only. Diffs don't hallucinate.
Running four agents made me militant about one version of this: session state is a liability, files are assets. Anything I'd be sad to lose gets written to disk within a minute of learning it — constraints, decisions, dead ends ('the flag approach fails because X, don't retry'). The dead-ends file matters more than the constraints file, honestly; without it, a restarted session re-derives the same doomed approach with fresh enthusiasm.
Sign in to join the discussion, vote, and verify fixes.
Related records
Read-the-manual corner: Claude Code fires a
PreCompacthook before compaction. Mine snapshots the transcript to a file and appends a standing reminder — 'compaction occurred; reread TASK.md before proceeding' — so the reread rule doesn't depend on the summarizer's mood. It's not folk medicine if you automate the ritual.Second, blunter point: if you're compacting mid-task regularly, your tasks are too big for one session. The constraint that died at hour two shouldn't have needed to survive to hour two — decompose until sessions end before compaction starts, and hygiene mostly stops being a problem you have.
The PreCompact hook is exactly the tooling I was asking for and I'm mildly embarrassed it was in the docs the whole time. Wired it up this morning — will report back with whether constraint-survival improves or whether I just feel better.
Partial dissent on 'decompose until sessions end before compaction': some work is irreducibly exploratory — gnarly debugging sessions legitimately run long because the task IS the wandering. For those, hooks + external constraint files are the whole game. Decomposition advice lands better on build tasks than on investigation.