Way for one session to start multiple sessions

[bojantv]

I have 10 issues and I want a session per issue, I don't want to explain, I want one session to create 10 new ones in Clay.

[Karamorf]

I do this with tmux/iterm and hopefully these tidbits can help figure it out for Clay. Let me know if you want me to grab a zip of the relevant files.

While in a Claude code session, I "fork" the session into a new pane. The pane creation has a hook to run custom scripts and that script start up a new session. It does that by grabbing the session's jsonl from the original pane in ~/.claude/(session?). It takes that jsonl, copies it, then changes the session id. Then using that session id, it's a normal '--resume (forked-session-id)'. I also put the lineage into the status area of the code window to get '1>1', '1>2>1', '1>2>2'. Which just tells me where the current session forked from.

Couple of use cases:

• load up a whole plan.md into a "parent" session then fork from that for each task. I don't have to reload any context and the context stays light as I go from task to task.
• while working on a task, realize that the code architecture is missing a random one of feature. Fork from the task session, implement a small change that is easy to review in a new fork, and get that merged without bloating the change for the original task.

How the fork works under the hood:

Claude Code stores each session as a JSONL file at ~/.claude/projects//.jsonl. Forking is just:

Copy the parent's JSONL to a new file with a fresh UUID as the filename
Rewrite the "sessionId" field inside the file to match the new UUID
Run claude --resume
NEW_ID=$(uuidgen | tr '[:upper:]' '[:lower:]')
sed "s|"sessionId":"$PARENT_ID"|"sessionId":"$NEW_ID"|g"
"$PROJECT_DIR/$PARENT_ID.jsonl" > "$PROJECT_DIR/$NEW_ID.jsonl"
claude --resume "$NEW_ID"

The child starts with the full parent context and diverges independently from there. Parent session is untouched.

Why not --fork-session? That flag assigns the new ID lazily on the first user message, which creates a timing problem — hooks fire before the real session ID exists. The JSONL copy approach gives you a stable ID before the session starts, so you can wire it into status lines, log lineage, pass it to other scripts, etc.

hopefully these details help!