[FEATURE] Threads: navigable in-session sub-conversations that inherit full context (fork + agent-teams UI + merge-back)

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

When Claude presents multiple approaches to a problem (or a task has several independent sub-questions), I want to explore each one in parallel with the full conversation context, and easily navigate between those explorations — without leaving my session.

Today's options each fail one requirement:

• Subagents — run in-session, but don't inherit conversation history and can't be interacted with directly (one-way delegation, summarized results).
• Agent teams (experimental) — navigable and directly messageable, but teammates don't inherit conversation history either, and it's heavyweight.
• /fork — inherits full context, but lands in a separate background session: navigation is out-of-band (claude agents, attach/detach), and conclusions never flow back into the originating conversation.

Concretely: Claude gives me three candidate approaches. I fork three times, and now I'm juggling three detached sessions, manually attaching to each, and copy-pasting their conclusions back into the main chat to compare them.

Proposed Solution

Threads: context-inheriting, navigable sub-conversations inside one session. Essentially /fork's context model + agent teams' navigation UI + a merge-back story that neither has today.

Spawning

/thread <prompt>                  # one thread, inherits history up to now
/thread -n approach-1 <prompt>    # named
/thread --each "approach 1..." "approach 2..." "approach 3..."   # fan-out, same fork point

Threads run in the background; control returns to the main thread immediately.

Navigation

• Ctrl+T — thread panel: name, status (running | idle | awaiting-input | concluded), last activity, token spend.
• ↑/↓ + Enter — attach to a thread; it's a normal conversation (steer it, ask follow-ups). Esc — detach.
• Status line shows current location, e.g. thread:approach-2 (3 running).
• A thread that finishes or blocks on a question raises a notification chip in the main thread.

Merge-back

• /conclude inside a thread posts a structured conclusion card into the parent transcript (verdict, key findings, links to worktree/artifacts) — real context the main conversation can reason over.
• /threads compare in main: synthesizes across all concluded threads.
• Concluded threads stay attachable read-only.

Context model (what makes it economically viable)

• Copy-on-write history: a thread references the parent transcript up to a fork-point index and appends its own messages — no transcript copy.
• All threads forked from the same point share an identical prompt prefix → prompt-cache hits for every thread after the first. Marginal cost per thread ≈ its own new tokens, not N full context re-sends.
• Post-fork isolation by default (threads don't see parent/sibling messages after the fork point); explicit /pull-main injects a summary of main-thread activity since forking.

Execution & files

• One CLI process multiplexes threads (like agent teams' in-process mode), with a concurrency cap.
• Worktree per thread by default when a thread edits files (reuse existing .claude/worktrees/ machinery); read-only threads skip it. Winner merges via existing worktree flow.
• Threads inherit the session's permission grants (same process — no re-approval, unlike --fork-session).

Persistence

• Session becomes a tree on disk: {parent_session_id, fork_point_index, own_messages} per thread. claude --resume restores the tree and repopulates the panel.

Guardrails: depth limit 1 in v1 (no threads-of-threads); per-thread token budgets (a thread hitting budget pauses rather than dies); threads.maxConcurrent config.

Alternative Solutions

• Multiple /forks (current workaround): works, but produces N detached sessions with no unified navigation and no merge-back; each fork re-sends the full context.
• Agent teams with the approaches as spawn prompts: navigable, but teammates lack conversation history, so I have to re-explain everything the chat already established.
• Subagents: cheap, but no history and no interactivity — fine for lookups, wrong for deep-dives that need the accumulated context.

Priority

Medium - Would be very helpful

Feature Category

Interactive mode (TUI)

Use Case Example

1. In a long session with lots of accumulated context, Claude proposes three implementation approaches for a migration.
2. I run /thread --each "prototype approach A" "prototype approach B" "prototype approach C" — three threads, each with the full history, each in its own worktree.
3. Ctrl+T to watch progress; I attach to approach B to answer a question it hit, detach.
4. Each thread /concludes; three conclusion cards land in my main transcript.
5. /threads compare — main session recommends approach B; I merge its worktree and discard the others.

Additional Context

The hardest design point is compaction interaction (a thread's pinned shared prefix vs. the parent's context compaction) — threads would need to pin pre-compaction transcript segments, which are immutable on disk. Everything else composes from existing machinery: /fork's snapshot semantics, agent teams' multiplexed TUI, worktree isolation, and prompt caching for the economics.

Related: #59818 (requested /fork, now shipped) — this proposes the in-session navigable layer on top of it.