Resuming forked sessions loads 0 messages (regression in 2.1.20+)
Description
When resuming a session that was forked from a checkpoint (using --fork-session --resume <parent-id>), the resumed session loads 0 messages instead of the full conversation history. This worked correctly in 2.1.19 but is broken in 2.1.20+.
Likely cause
The changelog for 2.1.20 mentions:
Fixed session compaction issues that could cause resume to load full history instead of the compact summary
This fix appears to have overcorrected - forked sessions now fail to load their inherited messages from the parent session.
Steps to reproduce
- Create a session and checkpoint it (note the session ID, e.g.,
c6b73157-...) - Fork from checkpoint:
claude --fork-session --resume c6b73157-... - Work in the forked session, building up conversation history (note forked session ID, e.g.,
072faf75-...) - Exit and try to resume the forked session:
claude --resume 072faf75-...
Expected: Full conversation loads (~90k tokens in my case)
Actual: Session opens with 0 messages/tokens
Debug log evidence
When resuming the forked session, debug logs show:
FileHistory: Copied backup ... from session 072faf75-... to e1555449-...
This indicates it's creating a new session instead of continuing the existing one. The file history gets copied but conversation messages do not load.
In contrast, resuming the original (non-forked) checkpoint session works correctly.
Session file analysis
The forked session JSONL file contains messages with two different sessionId values:
- 25 messages with parent sessionId (
c6b73157-...) - the inherited checkpoint content - 483 messages with forked sessionId (
072faf75-...) - new work in the fork
The resume logic appears to be filtering to only messages matching the target sessionId, which excludes all the inherited messages from the parent.
Environment
- Claude Code version: 2.1.29 (also reproduced on 2.1.19, 2.1.25)
- OS: macOS (Darwin 24.5.0)
- Working in 2.1.19 (last known good version for this workflow)
Workaround attempts (failed)
- Deleting
sessions-index.jsonto force regeneration - Removing summary entries from the JSONL
- Rewriting all
sessionIdvalues to match the forked session ID
None of these workarounds restored the session.
Impact
This breaks the checkpoint/restore workflow for long-running collaborations that use forking to preserve context while grinding through work.
This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗