`--fork-session` forks last-flushed JSONL, not the live in-memory conversation

Resolved 💬 3 comments Opened Apr 7, 2026 by Bkankim Closed Apr 11, 2026

Summary

claude --resume <ID> --fork-session reads the session JSONL from disk, but the JSONL is not flushed in real-time during an active session. This means --fork-session forks the last persisted state, not the current live conversation — which can be an entirely different conversation if /clear was used.

In contrast, /fork (aliased as /branch) operates on the in-memory conversation state and correctly includes the current conversation.

Reproduction

  1. Start a Claude Code session, have a conversation (conversation A)
  2. Run /clear
  3. Have a new conversation (conversation B) — this is now the active context
  4. From a different terminal, run:

``bash
claude --resume <session-id> --fork-session
``

  1. The forked session contains conversation A, not conversation B

Expected behavior

--fork-session should fork the current live conversation (conversation B), matching what /fork//branch does.

Actual behavior

--fork-session forks conversation A (the last-flushed JSONL state). The current conversation B has not been written to the JSONL file yet.

Evidence

Verified by checking the JSONL file during an active session:

# Session has been active for 3+ hours with extensive conversation
$ wc -l ~/.claude/projects/-bkan-hq/<session-id>.jsonl
478  # unchanged since session start

$ grep -c "smartbrief" <session-id>.jsonl
0  # current conversation keyword not found — JSONL not flushed

The JSONL appears to only be written on session close, not in real-time.

Impact

This affects any workflow that programmatically forks a running session from another process/terminal — for example, multi-agent architectures that spawn review agents via --fork-session in tmux panes.

Workaround

Use /fork (or /branch) from within the active session instead of --fork-session from another terminal. However, /fork cannot be triggered programmatically from another process, limiting automation use cases.

Suggestion

Either:

  1. Flush JSONL in real-time (or at regular intervals) so --fork-session sees the current state, or
  2. Document the difference between /fork (in-memory) and --fork-session (disk-based) clearly in the docs, or
  3. Provide a mechanism to trigger a JSONL flush from within a session (e.g., a flag or command) so external processes can fork the current state

Environment

  • Claude Code version: latest (2026-04-07)
  • OS: Linux (WSL2)
  • Session type: interactive CLI

View original on GitHub ↗

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