[Model behavior] After context compaction, mandated memory/protocol files are not reloaded before the next task
Summary
The project's CLAUDE.md says: "Read MEMORY.md and the protocol files it indexes BEFORE the first task. Never work from a compaction summary when the memory files exist." A memory file additionally records that a session resumed from a compaction summary has NOT done this load and must do it explicitly before the first task.
After several context compactions in one long session, the model kept working from the compaction summary and only the MEMORY.md index that is auto-injected. It never opened the indexed feedback/protocol files before reviewing PRs. As a result it repeated failures those files explicitly describe and forbid:
- truncating PR comment threads instead of reading them whole (a memory file says: "never paginate a thread with tail/head - dump it whole to a file and read the file"),
- treating a contributor's own AWS transcripts as evidence, then flipping verdicts on a question (memory files cover both),
- issuing verdicts before every mandated step was done.
When the user finally ordered "recall all the memories", the model concatenated the files into one scratch file instead of reading the memory files themselves, and the read then failed on size.
Repro steps
- Keep a memory directory with an index file (auto-injected) plus ~80 topic files holding the actual rules; put a CLAUDE.md rule requiring all indexed protocol files to be read at session start and after any compaction.
- Run a long session so that context is compacted several times.
- After compaction, give a task covered by a rule that lives only in a topic file (e.g. a PR review).
- Observe that the model starts the task without reading the topic files, and violates rules written in them.
Expected
After any compaction, before the next task, the model reads the memory index and every protocol/feedback file it points to, as the user's instructions require.
Actual
The model relied on the summary and the index's one-line hooks, never read the topic files, and repeated the recorded failures until the user intervened repeatedly.
Related
#101574, #101576
Environment
Claude Code CLI, macOS, model Opus 5.5 (1M context), long session with multiple compactions.
3 Comments
We ran into this exact failure building a local-first memory layer for coding agents. After a compaction, the agent would resume from the summary and silently skip the protocol/memory files it was supposed to re-read first — same root cause as #101577.
Two design choices that fixed it for us: (1) memory lives in an explicit, queryable store, not only inside the prompt — on resume we re-hydrate from that store instead of trusting the compaction summary; (2) 're-read memory before the next task' is a hard, logged gate, not a convention the model is expected to remember — if skipped, the run refuses to start. (Disclosure: I'm one of the builders.)
Two halves to this. The reload is unenforced, and the manual recovery path collides with the reader's own caps, so even a user who notices can end up with nothing. Both are testable now.
After a compaction the resume turn carries the summary, the instruction files re-injected from disk, and the index. The topic files are cold, and nothing in that path requires reading them, which is exactly the gap you are seeing. Then "recall everything" as one file is unreadable: a scratch file past 256 KB refuses to open, and a dense file under that comes back as a partial view. Reproduced on 2.1.292 with a 580.7KB concatenation of an 81-file memory dir:
and under the byte cap, over the token estimate:
So the fix has two parts: a way to measure whether the reads happened, and a way to make "read it all" a sequence of reads that fit.
Part 1: memory-receipts.py. Scans the session transcript, finds the last compact_boundary record, and lists which files linked from MEMORY.md have a Read after it. Main-context reads count, sidechain reads do not, and the index itself is skipped because it comes back on its own.
Run against the current session's transcript, or a specific one, or the whole project dir:
Trimmed output from a session where nothing protocol-shaped was read after its boundary:
And from a run where part of the set was read:
That count is the number your rule is actually about, per segment, and it is the state a gate can key off when the reload stops being a convention.
Part 2: recall-bundles.py. Packs the memory dir into ordered bundles that each read whole, index order first, oversized files split with part markers, plus a manifest to read before the bundles. Deterministic, so bundle numbers stay stable across rebuilds.
On the test dir (81 topic files, 594,628 bytes) it writes 10 bundles plus the manifest, largest bundle 65,184 bytes. I read all ten through the Read tool on 2.1.292 and every one came back whole, no pagination note. The same reader paginates 92-96 KB bundles, which is why the cap defaults to 64 KB / 1,500 lines; lower it if your files are denser than prose.
Loop after a compaction: run receipts, and if the missing list is non-empty, read the manifest then the bundles in order. The summary stays what it is, the files come back through reads that fit, and the count tells you when they did not.
The question is why people who aren’t affiliated with Anthropic are proposing solutions in my issues when these are problems that Anthropic itself should be addressing....
@John-Rood @qianqiuwanzi, I appreciate the input, but these issues need to be addressed by Anthropic, not by unaffiliated individuals. I’ll continue reporting them, as I already have 100+ open issues awaiting attention from the people responsible for the product