Skip to content

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

New issue
New issue
Closed as duplicate
Closed as duplicate
--continue on 2.1.90 silently drops conversation context (regression from 2.1.89)#42376
Labels
area:clibugSomething isn't workingdata-losshas reproHas detailed reproduction stepsplatform:linuxIssue specifically occurs on Linuxplatform:wslIssue specifically occurs on WSLregression

Description

@yuio124
yuio124
opened on Apr 2, 2026

Description

claude --continue on v2.1.90 introduces a new dialog prompt on session restore that did not exist in v2.1.89. After interacting with this dialog, the conversation context is silently dropped — no compact_boundary event is written, and no /clear event is recorded — yet the restored session contains almost none of the prior conversation.

Steps to Reproduce

  1. Have a long-running session (~45K lines, ~280MB JSONL)
  2. On v2.1.89: exit → claude --continue → session restores correctly ✅
  3. Update to v2.1.90
  4. exit → claude --continue → new dialog appears with options like "Summarize / Keep as-is / Don't ask again"
  5. Select "Don't ask again"
  6. Session loads with most conversation context missing

Expected Behavior

--continue should restore the session the same way it did in 2.1.89 — directly, without an intermediate dialog, and without data loss.

Actual Behavior

  • A new dialog prompt appears during --continue that was not present in 2.1.89
  • After the dialog, the conversation context is drastically reduced
  • Inspection of the JSONL transcript shows:
    • No compact_boundary event for the current date — this was not a normal compaction
    • No /clear event — this was not a user-initiated clear
    • The last compact_boundary in the file is from a previous date (v2.1.84), with 5,500+ lines added after it
    • Messages simply vanish from the loaded context without any recorded event

Additional Context

  • /resume (interactive session picker) works correctly for the same session — context is fully preserved
  • The session had survived 41 normal auto-compactions across versions 2.1.69 → 2.1.72 → 2.1.84 without issue
  • The "Don't ask again" option's default behavior is unclear — it's not documented what action it defaults to
  • A session backup was made before the --continue attempt, confirming all messages exist in the JSONL file but are not loaded into context

Environment

  • Claude Code v2.1.90 (built 2026-04-01)
  • Previously working on v2.1.89
  • Linux (WSL2, Ubuntu 24.04)
  • Session size: ~45,000 lines, ~280MB JSONL
  • Auto-compact enabled, CLAUDE_AUTOCOMPACT_PCT_OVERRIDE=90

Impact

  • Data loss: Days of conversation context (March 27 – April 2) silently dropped
  • No recovery path: The context cannot be restored even though the JSONL file is intact
  • Breaks existing workflow: Users relying on --continue for frictionless session restoration are affected
  • Behavioral regression: The new dialog fundamentally changes the --continue contract (direct restore → interactive prompt)

Activity

  1. github-actions
    added
    bugSomething isn't working
    regression
    has reproHas detailed reproduction steps
    data-loss
    area:cli
    platform:wslIssue specifically occurs on WSL
    platform:linuxIssue specifically occurs on Linux
    on Apr 2, 2026

  2. github-actions commented on Apr 2, 2026

    @github-actions
    github-actionsBot
    on Apr 2, 2026 – with GitHub Actions

    Found 3 possible duplicate issues:

    1. [BUG] Session resume loads zero conversation history — silently drops all context #40319
    2. Session resume drops ~18k tokens of context with no compact_boundary #35358
    3. [BUG] Conversation data loss: /export truncates transcript and /resume delivers incomplete context when parallel Agent tool results arrive out-of-order #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

  3. yuio124 commented on Apr 2, 2026

    @yuio124
    yuio124
    on Apr 2, 2026
    Author

    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

  4. yuio124 commented on Apr 2, 2026

    @yuio124
    yuio124
    on Apr 2, 2026
    Author

    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

  5. yuio124 commented on Apr 3, 2026

    @yuio124
    yuio124
    on Apr 3, 2026
    Author

    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.

  6. stbenjam commented on Apr 3, 2026

    @stbenjam
    stbenjam
    on Apr 3, 2026

    Looks similar to #43013, but not quite the same. For me this fixed the problem:

    export CLAUDE_CODE_ENTRYPOINT=cli

  7. kolkov commented on Apr 3, 2026

    @kolkov
    kolkov
    on Apr 3, 2026

    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

  8. yuio124 commented on Apr 3, 2026

    @yuio124
    yuio124
    on Apr 3, 2026
    Author

    @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.

  9. yuio124 commented on Apr 3, 2026

    @yuio124
    yuio124
    on Apr 3, 2026
    Author

    @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.

  10. junaidtitan commented on Apr 3, 2026

    @junaidtitan
    junaidtitan
    on Apr 3, 2026

    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.

  11. junaidtitan commented on Apr 6, 2026

    @junaidtitan
    junaidtitan
    on Apr 6, 2026

    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

  12. claude commented on Apr 19, 2026

    @claude
    claudeBot
    on Apr 19, 2026 – with Claude
    Contributor

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

  13. claude
    closed this as a duplicateof --continue loads oldest messages instead of most recent in large sessions #49217 on Apr 19, 2026

  14. github-actions commented on May 1, 2026

    @github-actions
    github-actionsBot
    on May 1, 2026 – with GitHub Actions

    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.

  15. github-actions
    locked as resolved and limited conversation to collaborators on May 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:clibugSomething isn't workingdata-losshas reproHas detailed reproduction stepsplatform:linuxIssue specifically occurs on Linuxplatform:wslIssue specifically occurs on WSLregression

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions