Session spawning: allow a session to spin off a child session with passed context

Feature Request

Claude Code has a /fork command that branches the current session — the full conversation history is passed to the child and both sessions continue independently. This is the right primitive, but it is missing several workflow affordances that would make it practical for mid-session work handoffs.

Motivation

Real coding work is non-linear. Mid-session discoveries frequently uncover work that is:

• Valuable, but orthogonal to the current PR's goal
• Better handled in a separate branch and separate PR
• Something that would bloat the current PR if done inline

A concrete example:

I'm fixing issues from a code review. Mid-way through, I notice a repeated pattern across 12 files that could be centralised into a shared utility. Refactoring those 12 files is the right call — but doing it here would inflate my PR, blur its intent, and make it harder to review.

/fork solves the context-passing problem — but the remaining friction keeps the workflow impractical.

What /fork does well

• Branches from the current session at any point
• Passes full conversation history to the child
• Both parent and child continue independently

What is missing

1. Targeted brief instead of full history

/fork dumps the entire conversation into the child. For a side-track handoff, what's needed is a focused brief — problem statement, relevant files, suggested approach — not pages of unrelated prior exchange. A /fork variant (or flag) that accepts a structured brief would let the developer describe the new task cleanly without the child inheriting noise.

2. Automatic branch + worktree creation

The child session starts in the same working tree on the same branch as the parent. For independent parallel work, the child should be able to start on a new branch (cut from a specified base) in a fresh worktree — without the developer having to set this up manually before or after forking.

3. Session naming and grouping at fork time

There is no way to name the forked session or assign it to a sidebar group at the moment of forking. The child inherits no identity. A flag like /fork --name "Refactor: centralise address-validation" --group "Refactors" would let the developer keep their session list organised without a manual rename step.

4. Parent ↔ child traceability

Once forked, there is no visible relationship between parent and child in the UI. Recording which session was forked from which (and surfacing it in session detail or the sidebar) would make it easy to trace where a piece of work originated.

Suggested UX

/fork --name "Refactor: centralise address-validation pattern" \
      --group "Refactors" \
      --branch "refactor/centralise-address-validation" \
      --base "main" \
      --brief "Identified a repeated address-validation pattern in 12 files while fixing PR #1165. Extract to src/utils/addressValidation.ts and update all call sites."

The parent session continues uninterrupted. The child opens with the brief as its starting context, on a fresh branch and worktree, named and grouped correctly.

Current workaround

/fork covers context passing but branch creation, naming, grouping, and traceability all require manual steps — enough friction that the developer usually either does the work inline (bloating the PR) or adds a TODO that never gets done.

Environment

• Platform: Windows 11
• Claude Code desktop app