`--continue` on 2.1.90 silently drops conversation context (regression from 2.1.89)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/40319
2. https://github.com/anthropics/claude-code/issues/35358
3. https://github.com/anthropics/claude-code/issues/42290

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Not a duplicate — confirming same root cause persists in 2.1.90

After investigating, this appears to be the same root cause as #40319 (progress entry elision bug introduced in 2.1.85).

Key addition from this report:

• 2.1.89: --continue worked correctly for this same session
• 2.1.90: --continue fails — context silently dropped, no compact_boundary written
• The session survived 41 normal auto-compactions across 2.1.69 → 2.1.72 → 2.1.84 without issue
• /resume (interactive picker) loads the same session correctly — only --continue is affected

Binary analysis confirms the progress entry elision code path is still present in the 2.1.90 binary (built 2026-04-01T22:53:45Z).

This confirms the regression from #40319 remains unfixed as of 2.1.90. Linking rather than closing, as the version-specific reproduction data may be useful.

cc #40319

Reproduced twice on the same session

After the first context loss, I backed up the session JSONL (286MB) and attempted --continue again on the same session. The exact same behavior occurred — context was silently dropped with no compact_boundary or /clear event.

Key observation: this is NOT compaction behavior

If auto-compaction had fired, the most recent conversation topics would be preserved in the summary. Instead:

• Recent topics (last 5 days of work) were completely gone
• Only a fragment from ~5 days ago survived in context
• The model behaved as if /clear had been run — pulling context only from memory files (MEMORY.md), not from any compaction summary

This is consistent with the chain traversal break described in #40319: the parentUuid chain breaks at a progress entry, making all messages after the break point exist in the JSONL but unreachable by the loader. The result looks like /clear rather than compaction.

Timeline

1. Pre-update (2.1.89): exit → claude --continue → session restored correctly
2. Post-update (2.1.90): exit → claude --continue → new dialog appeared → context lost
3. Backed up JSONL (all messages confirmed intact in file)
4. Second --continue attempt → identical context loss reproduced

Update: --resume also affected (2.1.91)

Correcting my earlier report — I stated that /resume (interactive picker) loaded the session correctly while only --continue was affected. This is no longer true.

On 2.1.91, --resume (interactive session picker) exhibits the same context loss:

• Selected a session via --resume picker
• Input tokens started at 0 — not reduced, not summarized, but completely empty
• Session loaded as if /clear had been run

JSONL chain analysis

Analyzed the session JSONL (275MB, 45K+ entries) to find the exact break point:

Chain length:    115 messages  (line 45480 → 45613)
Unreachable:  37,938 messages  (line 1 → 45479)
Loss:            99.7%

Root cause: The chain root is a compaction boundary at line 45480:

Line 45477: user     parentUuid=exists   ← last reachable from old chain
Line 45480: system   parentUuid=NULL     ← "Conversation compacted" (new chain root)
Line 45481: user     parentUuid=exists   ← points to 45480, chain continues forward

The compaction event creates a new system message with parentUuid: null. When --resume traverses backwards from the latest message, it hits this null parent and treats it as the chain root — discarding all 37,938 messages before it.

During a live session this works fine because the compaction summary lives in memory. But on resume, that summary is gone and only the chain structure remains — which is severed.

Additionally found 19 broken links throughout the JSONL, 17 of which are type=progress entries pointing to missing parents (consistent with the progress entry elision described in #40319).

This confirms the bug is not --continue-specific but affects the session restoration path in general. The 2.1.91 fix ("transcript chain breaks on --resume") addressed a different failure mode (async write failure), not this structural chain break.

Looks similar to https://github.com/anthropics/claude-code/issues/43013, but not quite the same. For me this fixed the problem:

export CLAUDE_CODE_ENTRYPOINT=cli

Confirming — same behavior on v2.1.91 with both /resume and --resume. Our session (20 MB, 5,027 lines) loads as 644 tokens (0.1%).

We compared v2.1.88 TypeScript source (from the leaked source map) with v2.1.91 minified cli.js and found three specific changes causing this:

1. walkChainBeforeParse removed — fork pruning for >5 MB files no longer happens (function exists 2× in v2.1.88, 0× in v2.1.91)
2. New ExY timestamp fallback (tengu_chain_timestamp_fallback) bridges across unrelated fork branches via a 5-second window
3. Missing leafUuids check in getLastSessionLog (line 3900) — picks synthetic resume messages instead of actual conversation leaves

Each failed resume also corrupts the JSONL by forking the parentUuid DAG — making subsequent resumes worse.

Full source code analysis with exact file:line references + fix prompts for Claude Code: #43044

Recovery workaround (reads JSONL directly, bypasses broken resume):

go install github.com/kolkov/ccdiag@latest
ccdiag recover --latest D:\projects\myproject

@stbenjam Thanks for the suggestion! Unfortunately CLAUDE_CODE_ENTRYPOINT=cli was already set in my environment — the issue persists regardless.

My session is significantly larger (276MB, 45K+ lines, 42 auto-compactions) so it's possible the >5MB code path regression kolkov identified in #43044 is the dominant factor here.

@kolkov Great source code analysis — the three regressions you identified explain exactly what I was seeing in my JSONL data.

For additional scale reference: my session is 276MB (45K+ lines, 42 auto-compactions). After analyzing the parentUuid graph, the entire file forms a single connected component (not isolated islands), but the chain walk from tail only reaches 6,624 of 38,267 entries (17.3%). Each compaction point creates a branch where the original messages become unreachable from the main chain.

Your finding about walkChainBeforeParse removal is consistent — with 276MB, fork pruning being skipped on the >5MB path would leave all 42 branches unpruned.

ccdiag looks useful. I also built a repair script that fixes broken parentUuid links (19 broken → 0), though as you noted, the root cause is in the loader code, not the data.

Silently dropped context on --continue with v2.1.90 happens when the JSONL file is too large for the chain walker to reconstruct cleanly. Pruning the session before resuming fixes this.

Cozempic v1.4.1: cozempic treat <session> -rx standard --execute before continuing. Or install the guard daemon for automatic protection:

pip install cozempic && cozempic init

The guard auto-starts on every session and keeps files lean so --continue works reliably.

Context dropped on --continue is usually caused by a bloated JSONL that the chain walker can't reconstruct cleanly. Cozempic v1.6.11's guard saves a final checkpoint on every Stop hook and prunes the session continuously so the file stays clean for resume.

pip install cozempic && cozempic init

This is a duplicate of #49217, which was fixed as of version 2.1.101.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.