Resuming forked sessions loads 0 messages (regression in 2.1.20+)

Resolved 💬 4 comments Opened Feb 11, 2026 by allspiritseve Closed Apr 15, 2026

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

  1. Create a session and checkpoint it (note the session ID, e.g., c6b73157-...)
  2. Fork from checkpoint: claude --fork-session --resume c6b73157-...
  3. Work in the forked session, building up conversation history (note forked session ID, e.g., 072faf75-...)
  4. 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.json to force regeneration
  • Removing summary entries from the JSONL
  • Rewriting all sessionId values 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.

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗