[Bug] "Summarize up to here" silently drops earlier compact summaries located after the anchor - permanent context loss

TL;DR

Partial compaction "Summarize up to here" keeps everything after the anchor except prior compact summaries: any earlier summary (e.g. from a previous "Summarize from here") that sits after the anchor is silently removed from the live context — it is neither summarized (it lies outside the summarized range) nor preserved (it is filtered out of the kept suffix). Everything that existed only inside that summary is lost, with no warning to the user or the model. Workaround: never anchor "up to here" before an existing summary; prefer /compact (absorbs every summary in context) or "Summarize from here".

---

Bug Description

"Summarize up to here" anchored at message X summarizes the range [start … X] and preserves [X … end]. When rebuilding the preserved suffix, the client filters out compact boundaries and prior compact-summary messages (entries with type === "user" and isCompactSummary). A prior summary located after the anchor therefore disappears from the reconstructed context:

• it is not part of the summarized range (it lies after the anchor), and
• it is excluded from the preserved suffix by that filter.

The entries remain in the session's .jsonl transcript file, but the live context loses them permanently. Since a summary is the only in-context representative of hundreds of already-compacted messages, dropping it deletes real information — decisions, task state, pending work — silently.

Read in the code of v2.1.246 and reproduced live through v2.1.259 (details below).

Expected Behavior

Prior compact summaries located after the anchor should be preserved like any other post-anchor content (they are regular context, and usually the most valuable part of it) — or, at minimum, the operation should warn that N earlier summaries will be discarded.

Actual Behavior

The summaries vanish from the context silently. The session continues as if they had never existed.

---

Reproduction Steps

1. In any session, create a partial summary near the end: Esc Esc → select a recent message → "Summarize from here". The context now contains [older messages] + [summary S] + [a few recent messages].
2. Esc Esc → select a message older than S's anchor → "Summarize up to here".
3. Inspect the resulting context (or simply ask the session which summaries it has): the new summary of the old part sits at the start, the recent part is preserved — and S is gone, with no warning.

Evidence (from audited transcripts)

• Case A (v2.1.246, Aug 31): one "up to here" cut dropped four earlier "from here" summaries (created at 04:14, 05:07, 06:52 and 08:10 that same day). The cut's preservedMessages list contained 153 entries — none of them a summary. Notably, the re-attached file references belonging to those summarized ranges survived, while the summaries themselves did not.
• Case B (v2.1.259, Sep 4): a chain of four partials — two "from here", two "up to here" — followed by a plain /compact: the two "up to here" cuts had discarded three of the four summaries, so the final compaction only had one summary left to absorb.
• Case C (v2.1.259, Sep 4 — confirmed from the outside): two partials two minutes apart in the same session. A "from here" preserved the initial summary sitting before its anchor (the summary's UUID appears in the cut's preserved-messages list); the next "up to here", anchored before a "from here" summary, did not — that summary's UUID is missing from the list the client uses to rebuild the context, even though its position fell inside the preserved range. Asked afterwards how many summaries it had in context, the session reported one (the initial one); the other was gone.

Verified across four cuts in three different sessions.

Root Cause Analysis

In the "up to here" path, the preserved-suffix reconstruction excludes entries matching compact boundaries and prior summary messages (predicate equivalent to !isCompactBoundary(entry) && !(entry.type === "user" && entry.isCompactSummary)). Excluding stale boundary markers makes sense; applying the same filter to summary messages deletes irreplaceable content, because a summary has no other in-context representation of the material it replaced.

Workaround

• Only use "Summarize up to here" when no prior summary exists after the intended anchor (e.g. to fold the beginning of a session).
• Prefer /compact (absorbs all summaries in context — verified) or "Summarize from here" (absorbs summaries after its anchor and keeps everything before it intact — verified).

---

Environment

• Claude Code: behavior read in v2.1.246 code; observed live on v2.1.246, v2.1.258 and v2.1.259
• OS: Windows 11 Pro
• Not platform-specific: the filter lives in the client's preserved-suffix reconstruction, which has no platform-dependent branch. Windows is simply where this was observed and audited.

find ~/.claude/projects -name '*.jsonl' -not -path '*/subagents/*' -print0 | xargs -0 ls -t | head -n 5

grep -rl "phrase you remember" ~/.claude/projects --include='*.jsonl'

jq -r 'select(.isCompactSummary == true) | ("\n===== summary @ " + (.timestamp // "unknown") + " =====\n") + (try (.message.content | if type == "string" then . else ([.[]? | select(.type == "text") | .text] | join("\n")) end) catch "[unreadable content shape]")' <transcript>.jsonl > compact-summaries.md