A consulting team has spent the morning with Claude Code building a careful diagnosis of a client's situation — 60 turns of conversation, 12 tool calls, detailed analysis of market position, financial structure, and competitive landscape. They now want to explore two recommendation paths in parallel: an aggressive "expand into a new vertical" approach and a defensive "consolidate and improve margins" approach. They want to compare both fully without one's reasoning bleeding into the other.
What's the right pattern?
Why did you pick that answer? Two or three sentences. The act of articulating it is what builds the judgment — not the click that follows.
fork_session is designed for exactly this case — divergent exploration from a shared baseline. Both branches inherit the full analysis context (every reasoning chain, every tool result, every conclusion you've reached together) and then proceed independently. You compare them without either having seen the other's reasoning. This is dramatically better than re-establishing context manually or letting two paths interleave in one session.
Once approach A's reasoning is in context, approach B can't be explored cleanly — the agent will keep referencing A, defending A, or contrasting against A rather than evaluating B on its own merits. Comparison requires that each path be developed independently, which is exactly what session forks provide.
Reproducing 60 turns of analysis manually is impractical, and what you'd actually be reproducing is a summary of the analysis — losing the reasoning architecture the original session built up. The new sessions start from imperfect summaries, not from the analysis itself.
A file summary preserves facts but loses the reasoning architecture — the new session has to re-derive what the original session already understood. It also requires you to know what to write down before you know which reasoning will turn out to matter.