There is a point in most long sessions where you want a second pair of hands. The agent is working through something, and a separate question appears that deserves real investigation - not a quick lookup, but reading files, running commands, checking whether something is actually true. Handing that to a fresh subagent sounds right, until you start writing the prompt and realize you would have to re-explain the entire situation first. The task is thirty seconds of work; describing the context around it takes ten minutes.
Claude Code provides several ways to handle this, and the vocabulary can be confusing, because forking a subagent and forking a conversation are related but different ideas. The useful distinction is what context the new agent receives, and whether you continue the work yourself or delegate it.
Behavior below reflects the Claude Code documentation as of October 2026. This area has changed across releases, so check the commands reference if you are reading this much later.
Fresh context or inherited context
Every option comes down to one question: should the second agent start from nothing, or from what you have already done?
A fresh subagent gets its own context window. It receives the task delegated to it and its configured tools and permissions, but it does not inherit the main conversation history. That isolation is the point - it can read files, search the codebase, or investigate a problem without filling the main conversation with all of its intermediate work. When it finishes, a summary of its work returns to the main conversation.
The cost is that it does not know the conversation that led you there. If the task depends heavily on decisions, discoveries, or dead ends from the current session, you have to provide that background yourself.
A forked subagent is different. It inherits the whole conversation so far: the same instructions, tools, model, and message history as the main session. It can start working without a briefing, while its own tool calls still stay out of your conversation and only its final result comes back.
Three commands, three jobs
Claude Code gives each of these ideas its own command.
/subtask followed by a task starts a forked subagent, for example /subtask draft unit tests for the parser changes so far. It works in the background while you keep going, and its result arrives as a message in your conversation. Claude can also start a fork on its own when a task needs the background of the conversation.
/fork copies the whole conversation into a separate background session, and you keep working where you are. Give it a prompt and the copy starts on it right away; without one, it waits for its first prompt in agent view, where your background sessions are listed. Unlike a subagent, the copy does not report back into your conversation. It is a session of its own.
/branch also copies the conversation, but switches you into the copy, so you can take the same history in a different direction yourself. The original stays as it was, and you can return to it with /resume.
If you read an older guide, the names may not match. Before version 2.1.212, /fork was the command for a forked subagent, the job /subtask does now. The same applies when agent view is turned off: /subtask is not available, and /fork still starts a forked subagent.
What forking does not isolate
Worth being precise here, because "isolated" can mean different things.
A forked subagent has its own working context. Its investigation does not become a long sequence of extra messages in your conversation, so the main session stays focused on its original task.
That is not the same as filesystem isolation. A forked subagent works in the same project folder as you, so any file it changes, it changes in your working copy. A conversation copied with /fork is told by default to create its own Git worktree, a separate working copy of the project, before it changes any code, so its edits stay apart from yours until you decide to bring them in.
So the important distinction is: Conversation isolation is not filesystem isolation.
Conclusion
None of this is worth memorizing as a command list.
A fresh subagent is not worse than a fork. Isolation is valuable for read-heavy work like research or review, where you want a large investigation to happen elsewhere and only the useful result to return to your context.
A forked subagent, started with /subtask, is useful when the investigation needs to understand the conversation that led you there. It saves you from reconstructing the briefing. A copy made with /fork suits work that should run as its own session, and a branch made with /branch suits continuing from the same history yourself, in a different direction.
The real question is not "Which command do I use?" It is "What should this agent inherit, and who should continue the work?"
Relevant Training
Subagents, background sessions, and worktrees, the building blocks behind every option in this post, are covered in Claude Code Agents and Automation, part of Cybrec's Claude AI training program.
0 Comments