Expose a continued/forked session's predecessor id to hooks and mods (and document the continued-in record)

Status Open
Reported on v2.1.290
Maintainer reply None cached
Activity 0 comments · opened Oct 6, 2026

Feature request

When a session starts as a continuation of another session, expose the predecessor's session id to hooks and mods, and document the continued-in transcript record.

Motivation

Pressing ← in a foreground session moves the conversation to the background under a new session id (reported in #87984). The background process runs as --session-id <new> --fork-session --resume <old>.jsonl --reply-on-resume. The original process stays alive as the agent-view host until the person exits it.

Tooling that keys work on the session id loses track at that move. In our case, a mod runs a watcher that reports the ends of long-running jobs launched from the session. The jobs record the launching session's CLAUDE_CODE_SESSION_ID. After ←, the jobs still name the old id. The old process's watcher keeps reporting into a conversation nobody reads anymore. The new conversation's watcher follows nothing. Nothing fails loudly: the job's end is silently lost.

The successor knows it is a continuation: SessionStart (and a mod's classic.SessionStart) fires with source: "fork". But no documented surface names the predecessor:

  • SessionStart input carries no parent id.
  • $.session.* and session.start carry no lineage.
  • claude agents --json and the job's state.json carry no forkParentSessionId for a ← move (they do for some /fork paths, per #89471).
  • session.end on the original names no successor (and does not fire, since the process stays alive).

The only record is the last line of the predecessor's transcript, which is undocumented:

{"type":"continued-in","timestamp":"…","continuedInSessionId":"<new id>"}

Requested

Either or both:

  1. A predecessor id on the start event. For example, parent_session_id on SessionStart when source is fork (and on a mod's session.start input), naming the session whose transcript the new one continues. This is what tooling needs to move its own state to the new id deterministically.
  2. Document continued-in as a stable transcript record, so tooling can follow the chain from the old id to the live one.

Item 1 is preferred: it needs no transcript scanning, and it covers every fork source, not only ←.

Environment

Claude Code 2.1.290–2.1.291, macOS, foreground interactive session in a terminal, agent view enabled.

Related: #87984, #89471, #94808.

View original on GitHub ↗