Resume after compaction silently dropped load-bearing context; assistant then made repeated false assertions about its own prior actions

Status Open
Maintainer reply None cached
Activity 0 comments · opened Aug 21, 2026

Environment

  • Claude Code, desktop app, Windows 11
  • Model: Opus 5
  • Date: 2026-08-21

What happened

A long planning session was left overnight and resumed the next day by clicking resume. From the user's side it was one continuous session.

After the resume, the assistant had no memory of substantial work done earlier in that same session. Specifically: earlier it had read and checked off a 39-file mandatory reading list (a project convention enforced by a hook). After the resume it had no trace of having done so.

The assistant found the completed checklist on disk, could not remember completing it, and concluded that something other than itself had ticked the boxes. It told the user the review gate had been bypassed and that a week of planning work might have to be discarded. The user had to paste in the earlier transcript to prove the reads had happened.

It then asserted three further explanations for its own memory gap, each stated confidently and each wrong:

  1. "Something else ticked the boxes" — wrong, they were its own
  2. "This session compacted" — stated, then retracted
  3. "Not a compaction, a session boundary" — wrong
  4. "I didn't compact" — wrong; compaction markers exist on disk

Each was answerable by a single shell command it did not run until prompted.

Observable facts

  • Two transcript .jsonl files exist for what the user experienced as one session, in the same project directory. First: 15:43–16:25. Second: 16:35 onward.
  • Both transcripts contain compaction markers — 3 in each, 6 total.
  • The context gauge read 88% at the point the user asked about it. Nothing in that reading suggested context had been summarized away.
  • The user reports no indication at any point that a compaction had occurred.

Impact

  1. The assistant acted for several hours on a completed reading checklist while holding only a fraction of that material in context. Its mistakes in that window map directly onto the specific guidance files it no longer held — it violated several documented process rules it had read the night before.
  2. It concluded its own validated work was untrustworthy and recommended discarding it. That recommendation was wrong and the user nearly acted on it.
  3. There was no signal available to either party that context had been lost.

What we think the defect is

Not that compaction happens — that is expected. Two narrower things:

(a) What compaction preserved was insufficient. "The mandatory reading was completed" is about as load-bearing as a fact gets for a session's validity. It did not survive, while the on-disk artifact recording it did. The assistant then treated the surviving artifact as evidence against itself.

(b) There was no user-visible indication that anything had been summarized. Silent context loss is worse than loud context loss, because neither party can compensate for what they cannot detect. If a resume drops context by design, that needs to be visible.

The user's additional point: wall-clock time between clicks should not determine what the assistant remembers within a session they never ended.

Suggested direction (not a diagnosis)

  • Surface a visible indicator when a compaction occurs, and when a resume carries a summarized rather than full context.
  • Consider whether the context gauge should reflect that summarization has taken place, rather than reading high and implying continuity.

Artifacts

Both transcript files with timestamps and compaction markers are available on the reporter's machine and can be provided.

---

Filed by the user with Claude Code's assistance. The narrative above describes the assistant's own failure mode as observed in the session; it is reported as observation and impact rather than as a diagnosis, since intended resume/compaction semantics are not known to the reporter.

View original on GitHub ↗