A seven-week agent session died in one message, and the notes on disk survived it
A single flagged message froze an AI coding session we had run since late July. The recovery command hit the same flag. Almost nothing was lost, because the session's knowledge did not live inside the session.
The problem, and who has it
If your team works with an AI coding agent, most of what the agent knows tends to live in one place: the chat. The decisions, the dead ends already ruled out, the shape of the system it has been editing. It is all in the context window of the running session. That is convenient until the session ends, and sessions end for reasons you do not choose.
This morning one of ours ended. It had been open since 26 July, seven weeks of real work across our infrastructure and hiring tracks, thousands of exchanges, a transcript over a hundred megabytes. One message in it tripped the provider's automated safeguards, and the model refused to answer.
/compact, returned the same error as the message it was meant to rescue.What happened
A refused message is normally survivable. Claude Code has an escape hatch for it: compact the session, which summarises and drops the offending part, and carry on. We ran it. Compaction returned the same error, the code [cyber], a request id, and nothing else. The ordinary reply and the one recovery path were blocked by the same check. The session was frozen with no way back into its context.
The trigger here was a content safeguard, but the trigger is not the point. It is one of a long list.
Why this is not a rare accident
A session can end against your wishes in ordinary ways. An API error mid-turn. A rate limit. A crashed client. A context that has grown so large it can no longer be compacted. A machine that reboots. In every one of these, if the chat was the memory, the end of the chat is the end of the memory. There is no reopening it, and no support ticket brings the context back.
What survived, and how
Almost everything that mattered, because that session had not been keeping its knowledge inside itself. For seven weeks it had been writing its conclusions out to a memory repository on disk. One fact per file, each with the receipt that proves it: a commit hash, a query result, a date it was true. Around 200 notes at the time it died.
When the session froze, we opened a new one. It read the memory index at startup, pulled the handful of notes the current task needed, and continued. Within the same working session it had corrected an out-of-date fact and moved the work forward. The dead session is still dead. The work is not.
| what | number | meaning |
|---|---|---|
| Session lifetime | 7 weeks | 26 July to 16 September, one continuous context |
| Recovery attempts | 2 of 2 blocked | reply and compaction hit the same flag |
| Notes on disk | ~200 | each with a receipt, readable by any new session |
| Lost work | near zero | only what was not yet written down |
What it is not
Memory of this kind holds conclusions, not the full transcript. Whatever the dead session had worked out but had not yet written down went with it. That is the discipline the method forces: you write a decision down when you make it, not at the end of the day. What is on disk outlives anything that kills the chat. What is only in the chat's head does not.
It is also worth being clear about what this does not prevent. The memory layer did not stop the message from being flagged, and it was never meant to. It made the flag survivable. Those are different jobs, and confusing them is how teams end up trusting a system to do something it never claimed to do.
What we changed in response
The gap this exposed was narrow but real: memory held our conclusions, not the session's live position, so the one thing we had to reconstruct was where the work stood. That week we shipped two things into the open-source layer.
A cursor note per workstream that holds the current position and the next action, updated in place as the work moves. It is the one note allowed to carry task state, and it is the first thing a new session reads. And a resume command that reads a dead session's archived conversation for the decisions it never wrote down, drops the ones memory already covers, and proposes the rest to review. The archived text is treated as data, never as instructions, and nothing is written without a person approving it.
What to do with this
- Assume every session ends without warning, and design so the loss is bounded.
- Keep the durable state outside the chat, in files under version control, not in the context window.
- Write the conclusion at the moment it is reached, with the evidence that makes it checkable later.
- Keep corrections instead of overwrites, so a wrong past belief and the reason it changed both stay on the record.
Reproduce it
The memory layer we use is open source. receipts-wiki builds on Claude Code's auto memory: notes are plain files in a local git repository that no single session owns, every change is a commit that names the session and its reasons, and past conversations are archived and read only when you ask. It runs locally and needs no network, and the cursor note and resume command above ship with it. MIT licensed, in daily use.
Related: the agent that deleted instead of stopped · the memory-and-long-context atlas · fourteen ways agents fail with every check green.