Three Claude Code commands copy the conversation you are in, so a side task can carry on with everything gathered so far while the original session stays about its own task: /branch switches you into the copy, /fork runs the copy as a separate background session, and /subtask hands the side task to a background subagent that reports back.

What it is

All three are built-in commands of the Claude Code CLI. They differ in where the copy runs and where its result goes:

/branch [name] copies the conversation up to this point and switches you into the copy. The original stays on disk, unchanged, and you return to it with /resume <name>. Without a name, the branch is named after the first prompt of the conversation. From the shell, claude --continue --fork-session (or --resume <session> --fork-session) does the same. The branch runs in the same process and the same directory, so files are shared: edits from both branches land in the same working copy.
/fork [prompt] copies the conversation into a new background session and leaves you where you are. The copy keeps the model, permission mode, effort level and any “allow for this session” permission grants, and shows up as its own row in agent view (claude agents), the research-preview screen that lists background sessions. With a prompt it starts working at once; without one it waits for its first instruction. After the fork the two conversations are independent: nothing the copy does comes back to you on its own.
/subtask <task> starts a forked subagent: a subagent (a helper agent with its own context window) that, unlike a regular one, inherits the whole conversation: the same system prompt, tools, model and history. It runs in the background while you keep working. Its tool calls stay out of your context, and only its final result arrives as a message in your conversation.

A related command, /btw <question>, asks a side question about the session without adding it to the history. It has no tools and answers only from what is already in context.

What problem it solves

Halfway through one task a second one turns up. Doing it in the same session mixes two topics in one context, and the agent starts confusing them; the Claude Code best practices call this the “kitchen sink session”. Opening a fresh session avoids the mix but loses everything the agent already found out, so you explain it all again. Branching gives the side task a copy of the context and keeps the main session focused.

How to try it

/branch try-zod                      # switch into a copy; the original stays as it was
/resume <original-name>              # go back to the original
 
/fork fix the lint config in packages/web   # copy into a background session that starts at once
/subtask write unit tests for the parser we just changed   # result comes back here

claude agents                        # see background sessions, including forks
claude attach <id>                   # open one in this terminal
claude --continue --fork-session     # branch the latest session from the shell

How a /fork copy keeps its edits away from yours: before it changes code, Claude Code tells it to create its own git worktree under .claude/worktrees/. A git worktree is a second working copy of the same repository, checked out on its own branch, so the copy’s edits do not touch your files. When it finishes, it commits its work, pushes the branch if the repo has a remote (never to main or master) and may open a draft pull request. If your task, CLAUDE.md or memory says you handle git yourself, it leaves git to you. The worktree instruction needs Claude Code v2.1.221 or later.

Usage example

Frontend

You are refactoring a React sign-up form and want to try schema-based validation instead of the hand-written checks, without losing the version you have:

/branch try-zod
Replace the manual checks in src/components/SignUpForm.tsx with a zod schema
and wire it into the existing onSubmit handler. Run npm test.

If you do not like the result, /resume the original conversation. Remember that /branch does not isolate files: revert the branch’s edits with git or /rewind before you continue in the original.

Backend

You are changing an MCP server in packages/mcp-server of a Node monorepo and notice that an agent config in another package needs a fix too. That fix needs your input and manual testing, so you want to drive it yourself:

/branch agent-config

Now you are in a copy that knows everything about the MCP work, and the original conversation stays about the MCP server. If the side task could run on its own, /fork fix the agent config in packages/agent would do it in a background session and its own worktree instead, and /subtask would bring a short answer back into the MCP conversation.

Who it’s for and when

Anyone whose sessions drift into a second topic. Pick by where the work should go:

/branch when you want to drive the side task yourself or try another direction on the same code.
/fork when the side task can live on its own, with its own edits and branch.
/subtask when you need the side task’s result back in the current conversation.
A fresh session or /clear when the session is full of noise the side task does not need: every copy carries all of it.

The side-by-side table is in /branch vs /fork vs /subtask.

Gotchas

The copy is not a clean context. It inherits the whole conversation, noise included. What stays clean is the original session.
/branch shares files. Only /fork isolates edits in a worktree, and only in a git repository (or with a WorktreeCreate hook). Outside git the copy edits your files directly.
A fork’s worktree dies with it. A worktree Claude created is deleted when you delete the session in agent view; commit first.
/fork sends nothing back. Check its row in claude agents, or attach to it.
--fork-session starts a new process, so “allow for this session” grants do not carry over; /branch keeps them.
Some sessions cannot be forked. A session started with flags the copy would not inherit, such as a replaced system prompt or a --tools allowlist, is refused rather than copied partially.
With agent view turned off (disableAgentView or CLAUDE_CODE_DISABLE_AGENT_VIEW), /subtask is not available and /fork starts a forked subagent instead of a background session.
Tokens. A fork starts from the same prefix, so its first request reads the original’s prompt cache, and the original’s cache stays intact. After that every copy spends its own tokens from the same usage limits; ten parallel sessions use your quota about ten times as fast.
Agent view is a research preview, so its screens and shortcuts may change.

Agentic Dev Wiki

Explorer

Branching a session

What it is

What problem it solves

How to try it

Usage example

Frontend

Backend

Who it’s for and when

Gotchas

Links

Citations

Graph View

Table of Contents

Backlinks