--continue loads oldest messages instead of most recent in large sessions

Status Fixed / completed

Maintainer reply ✓ Yes — ashwin-ant

Activity 4 comments · opened Apr 16, 2026 · closed Apr 19, 2026

💡 Likely answer: A maintainer (ashwin-ant, collaborator) responded on this thread — see the highlighted reply below.

Bug Description

When using claude --continue on a large session (8.6 MB, ~2,377 messages, 0 compaction summaries), the resumed conversation context shows messages from weeks ago (the beginning of the session) instead of the most recent messages.

Steps to Reproduce

Have a long-running session with many messages (~1,000+ user messages, ~1,350+ assistant messages)
The session file has no compaction/summary entries ("type":"summary" count = 0)
Run claude --continue from the project directory
The conversation context shown is from the earliest messages in the session, not the most recent ones

Expected Behavior

--continue should prioritize loading the most recent messages into the context window. When a session is too large to fit entirely, it should truncate from the beginning (oldest messages), not from the end (newest messages).

Actual Behavior

The context window is filled with the oldest messages from the session file. Recent work (in this case, API key creation and testing done the same day) is completely absent from the resumed context. The model responds based on topics from weeks ago.

Session Details

Session file size: 8.6 MB
Entry counts: assistant: 1351, user: 1026, system: 395, progress: 364, file-history-snapshot: 302, queue-operation: 244, attachment: 210, last-prompt: 32, permission-mode: 27
Compaction/summary entries: 0
--resume <session-id> exhibits the same behavior

Environment

Claude Code CLI (latest)
Linux (Ubuntu)

Workaround

None for the affected session. Starting a new session is the only option. Extracting conversation content directly from the .jsonl file can recover the lost context.

Suggestion

When loading a session that exceeds the context window:

Prioritize recent messages over old ones
Or auto-compact the session on resume, summarizing old messages and keeping recent ones intact

View original on GitHub ↗

4 Comments

github-actions[bot] · 6 months ago

Found 3 possible duplicate issues:

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

junaidtitan · 6 months ago

An 8.6MB session with 2,377 messages and zero compaction summaries is a recipe for exactly this — --continue fills the context window from the start and your recent work is nowhere to be found.

cozempic can help in two ways:

Preventive — the guard daemon keeps sessions from ever growing to 8.6MB by continuously pruning stale tool outputs, old file reads, and accumulated images. Sessions stay manageable so --continue loads what you expect.

Retroactive — you can prune an existing bloated session before resuming:

pip install cozempic
cozempic treat <session-id> -rx aggressive --execute   # prune the 8.6MB session
claude --continue                                       # now loads recent context

The aggressive prescription applies all 13 strategies and typically gets 60-80% reduction on sessions this size. After pruning, the session file is small enough that --continue can actually fit your recent messages into the context window.

Won't fix the underlying issue of CC loading oldest-first instead of newest-first, but it removes the conditions that cause the problem.

https://github.com/Ruya-AI/cozempic

ashwin-ant collaborator · 5 months ago

This was fixed in v2.1.101 — Fixed --resume/--continue losing conversation context on large (>5MB) sessions — the loader could anchor on a dead-end branch (Esc-interrupted response or prior-resume stub) instead of the live conversation, causing old or missing context to be loaded. If you're still seeing this in the latest version, please comment with your version and repro and we'll reopen.

github-actions[bot] · 5 months ago

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.