Claude Code Fork: How /fork Works, vs /branch and /subtask (2026)

Short answer: A Claude Code fork copies your current conversation into a new background session and leaves you in the original one. Give /fork a prompt and the copy starts working immediately. Run it with no prompt and the copy waits in agent view for its first instruction. Use /branch when you want to switch into the copy, and /subtask when you want a helper that inherits the same history and reports back into this chat. Since mid-2026, a /fork copy is told to make code changes in its own git worktree, so it should not edit the checkout you are sitting in.

Last updated: November 8, 2026. Behavior below comes from Anthropic’s Commands reference, Manage sessions, Run agents in parallel, worktrees docs, and the Week 32 changelog. Forum notes are paraphrased from r/ClaudeCode and Hacker News. I used Claude Code heavily in the past and do not have a Claude subscription now. I did not run /fork for this post.

What people mean by “Claude Code fork”

Searchers usually want one of three things:

  1. The /fork slash command inside Claude Code (this post).
  2. The CLI flag --fork-session, used with claude --continue or claude --resume, which starts a separate process from a saved transcript.
  3. A GitHub repository named something like “claude-code-fork.” Some of those are unofficial copies of leaked CLI source. That is a different, legally messy topic. This post does not link to them and does not tell you how to run them. If you want an open coding agent, start from free Claude Code alternatives instead.

A Claude Code fork is also not a git fork of your project, and it is not the same as asking Claude to “just spawn a subagent.” The vocabulary shifted during 2026, which is why older Reddit answers disagree with each other. Official docs fetched November 8, 2026 split the jobs as follows.

/fork vs /branch vs /subtask

CommandWhat you getWhere you stayDoes the result come back here?Typical use
/fork [prompt]A new background session that inherits this conversationIn the original sessionNo. It is its own session; watch it in agent view (claude agents)Ship in the main chat while a copy tries another approach
/branch [name]A new session that inherits this conversationSwitched into the copy; original stays on diskNo. You are now talking to the copyYou want to try a different direction yourself and keep a save point
/subtask <task>A forked subagent inside this sessionIn the original sessionYes. A summary returns to this conversationA side task that needs the history you already built, without becoming a second session

Two extras that people mix in:

  • A fresh subagent (the default when Claude delegates research) starts with an empty history. You have to brief it. A forked subagent started with /subtask inherits the whole conversation, so you skip the recap.
  • /background (alias /bg) detaches this session so it keeps running without you. /fork copies the conversation and leaves this session attached.

Official docs are explicit about the fallback: when agent view is turned off, /subtask is not available and /fork starts a forked subagent instead. If /fork suddenly “reports back” and never shows up as its own session, that is the mode you are in, not a different product.

On r/ClaudeCode in August 2026, a VS Code user asked how to enter, leave, and close a fork, and guessed that /branch made a new conversation while /fork happened inside the same one. The second half is the usual mix-up. /fork creates another session. It just does not move your cursor into it.

How to use /fork

Inside a session that already has the context you care about:

/fork write failing tests for the auth helper we just planned. Keep the public API the same. Use your own worktree and do not edit my current checkout.

What should happen on a current CLI build (v2.1.221 or later, agent view on):

  1. Claude Code copies the transcript into a new session with its own session ID.
  2. You keep typing in the original session.
  3. The copy starts on your prompt right away. Without a prompt, it waits in agent view.
  4. Unless the copy is set to edit in place, Claude Code instructs it to create a worktree of its own before it changes files. The Week 32 notes (August 3 to 7, 2026, around v2.1.220 to v2.1.224) said a session you copy with /fork now makes its code changes in a worktree instead of the original checkout.

To inspect the copy:

claude agents

That opens agent view: every background session, its state, and which ones need you. From inside a session, /resume also lists background sessions marked bg. Resuming one that is still running attaches this terminal to it and moves your current conversation to the background.

Enter, leave, and close a fork

This is the part the August 2026 r/ClaudeCode thread was really asking.

  • Enter the copy. You do not “enter” a /fork the way you enter a /branch. Stay in the original, or attach later with /resume (picker or session ID) or from claude agents. If you wanted to move into the copy immediately, you wanted /branch.
  • Leave without killing it. If you are attached to the background session, /exit (or /quit) detaches and the session keeps running. On an empty prompt, ← returns you to agent view.
  • Stop it. /stop stops the background session you are attached to. The transcript and any worktree stay on disk. Detach with /exit if you only wanted to look.

Name sessions if you run more than one (/rename auth-tests or claude -n auth-tests at launch). The session picker is much less painful when the rows are not all AI-generated titles.

When /branch is the better save point

/branch copies the conversation too, then switches you into the copy and leaves the original intact. Official session docs say the confirmation prints two session IDs: the branch you are now in, and the original. Go back with /resume and the original ID.

/branch try-streaming-approach

Then keep talking in that branch:

Implement the streaming version we outlined. Leave the original conversation untouched so I can resume it if this path fails.

/branch is the right tool when the next hour of work is yours and you want an undo point that is the whole conversation. File-level undo inside one session is /rewind, a different feature.

/branch stays in the same process, so “Allow for this session” grants carry over. A --fork-session launch starts a new process and does not inherit those grants. Background subagents and Bash commands keep running after /branch, and their output lands in the branch you switched into, not the original. Remote Control follows you into the branch.

When /subtask is enough

Use /subtask when the extra work should fold back into this chat:

/subtask Based on everything we discussed, list the edge cases the parser still does not cover and draft unit tests for them. Do not edit production files. Return a short summary and the test outline.

The helper inherits the conversation, works in the background, and sends a result back here. Official docs: to copy the conversation into a separate background session instead, use /fork. A /subtask is a worker. A /fork is a second you, with the same memory, who will not automatically file a report.

A fresh subagent (empty history) is still better for noisy search, such as “find every call site of chargeCustomer.” You do not need the last forty turns of product debate for that, and you do not want the search dumped into your main context. See the skills guide for how skills, subagents, and hooks split that work.

Does a Claude Code fork create a worktree?

On current docs: usually, yes, for /fork. Claude Code instructs the copy to create a worktree before it edits (v2.1.221 or later). That is different from claude --worktree feature-auth, which creates .claude/worktrees/<name>/ up front on a new branch.

A worktree is a separate working directory with its own files and branch, sharing the same git history, so two sessions can edit without colliding. Defaults put those checkouts under .claude/worktrees/ at the repo root; add that path to .gitignore.

What a worktree does not copy automatically:

  • gitignored files such as .env and .env.local, unless you list them in a .worktreeinclude at the project root
  • node_modules or a virtualenv (install dependencies in the worktree)
  • Hook path tricks: ${CLAUDE_PROJECT_DIR} still points at the project root where the session started. The hook’s cwd field follows the worktree.

A .worktreeinclude uses .gitignore syntax and only copies files that are both matched and gitignored:

.env
.env.local
config/secrets.json

--fork-session is stricter about where it starts. Official worktree docs: the forked session starts in the directory you launched Claude from, and Claude Code leaves the original session’s worktree untouched. If you resume a worktree session with --fork-session from the main checkout, do not assume the copy is already sitting in that worktree.

Older builds (before the Week 32 isolation change) could let a forked session edit the same checkout you were using. If two Claudes rewrite the same file, you get a mess that looks like a merge conflict without the merge. Upgrade, or start the second session with claude --worktree yourself.

The CLI flag: --fork-session

From your shell, combine --continue or --resume with --fork-session:

claude --continue --fork-session

claude --resume SESSION_ID --fork-session

Use this when you want a separate process from a saved transcript, not an in-session slash command.

A useful pattern showed up on Hacker News and in an r/ClaudeCode thread titled “Who’s using fork-session?”: treat one conversation as an immutable brief (the plan, the constraints, the files that matter), then --fork-session from that session ID for each candidate implementation. People also forked after planning so the planning context survived while coding started in parallel copies.

Do not resume the same session in two terminals without forking. Official session docs warn that messages from both terminals interleave into one transcript.

If you resume a session that is still running, and your command line includes flags such as --permission-mode, --model, or --output-format json, Claude Code will not attach to it. Add --fork-session to get a copy, or run claude stop <id> and then repeat the command if you need those flags on the original conversation.

--fork-session also skips restoring plan mode, and “Allow for this session” grants do not carry into the new process, so a fork can feel stricter than the chat you copied. That is safer than inheriting YOLO. Read YOLO mode in Claude Code before you “fix” it by skipping permissions again.

Three copy-paste workflows for a solo founder

These assume a current CLI with agent view on, inside a git repo.

1. Keep shipping, test in the background

You just planned an auth helper in the main session and you still have coding to do there:

/fork Write failing tests for the auth helper we planned. Do not change production code. Use your own worktree. When the tests fail for the right reasons, stop and wait; I will merge or discard later.

You stay on the implementation. The fork owns the test file in a worktree.

2. Try a risky rewrite without losing the working path

/branch redis-sessions

Then:

Keep the public API the same, but store sessions in Redis instead of Postgres. If this gets messy I will /resume the original session.

3. Ask a question that needs the history, then keep talking

/subtask From this conversation, extract the decisions we already made about pagination and list any place the current code still violates them. Read-only. Return a bullet list I can paste into a PR description.

A starter line I would put in CLAUDE.md so the agent does not invent its own parallelism:

## Parallel work
- Use /subtask for investigations that should report back here.
- Use /fork when a second session should edit in its own worktree and not report back.
- Use /branch when I want to steer an alternate path myself and keep a save point.
- Never edit the main checkout from a background session. Prefer a worktree.
- Do not resume the same session ID in two terminals; fork or branch instead.

Pitfalls

Agent view is off, or you are on an older build. /fork then behaves like a forked subagent (/subtask‘s job). You will not see a second session in claude agents. Check /status and update Claude Code before you debug “missing” forks.

Conversation isolation is not filesystem isolation. /subtask inherits history; it still works in the same project folder unless you isolate that subagent with a worktree (isolation: worktree in a custom subagent, or ask Claude to use worktrees for agents). /fork is the command that is told to create its own worktree.

.env is missing in the worktree. The copy starts a fresh checkout. Tests that need secrets will fail in confusing ways until you add a .worktreeinclude or copy the file yourself. Do not commit those files.

Parallel sessions multiply usage. Official parallel-agents docs say running several sessions or subagents at once multiplies token usage. Two long forks on Pro will burn a 5-hour window faster than one careful chat. Measure with /usage and see how to reduce Claude Code token usage and Claude extra usage cost if you are close to a cap.

The fork will not ping you when it is done. Unlike /subtask, a /fork session does not paste a report into the original chat. Check agent view, or ask the original session to message the other one if you have cross-session messaging (/list-agents, v2.1.224+ on macOS and Linux).

Permissions feel “reset” after --fork-session. That is expected: new process, no session-scoped grants, and plan mode is not restored. Re-approve, or set durable rules in settings.json instead of repeating “allow for this session.”

My take (past Claude Code use)

When I still ran Claude Code daily, the sessions that went well were the ones where I decided who steers before I multiplied the agent. Need an answer back in the same thread? That is a subagent (today: /subtask). Want to wander down a rewrite yourself and maybe throw it away? That is /branch. Want two implementations at once? Use separate checkouts, not two writers in one working tree.

/fork is the command I would have used for that third case: keep the main session on the path that already works, and let a copy try the experiment in a worktree. The failure mode I would still watch for is an old build, or agent view turned off, so /fork never becomes a second session and both halves write to the same files. I would not fork every side question. /btw exists for a question that should not even enter the history.

FAQ

Is a Claude Code fork the same as a git fork?

No. A Claude Code fork copies a conversation (and, on current builds, tells that copy to use a git worktree). A git fork is a copy of a repository on GitHub or GitLab. They share a metaphor, not a workflow.

Can I use /fork in the VS Code extension?

The commands exist there, but the August 2026 r/ClaudeCode thread shows the UI is easy to misread. Use the extension’s session list, or claude agents in a terminal. Do not assume /fork nests a side pane the way some chat products do.

What version do I need?

Official commands docs: /fork as a background-session copy needs a current build with agent view. The worktree isolation instruction requires v2.1.221 or later. On v2.1.161 through v2.1.211, and whenever agent view is off, /fork starts a forked subagent instead. Check claude --version and /release-notes.

Does /fork use extra usage?

Yes, in the ordinary sense: you now have two conversations sending tokens. There is no separate “fork fee” in the public pricing pages, but parallelism is how people blow a Pro window. See Claude Code pricing for plan limits.

How do I merge the fork’s code back?

Treat it like any other branch. The worktree has its own git branch (Claude Code’s --worktree default names look like worktree-<name>). Review the diff, run tests, then merge or open a PR into your main checkout. Do not copy files by hand if git can do the merge.

What if I am not in a git repository?

Worktree isolation uses git by default. Without git, /fork cannot lean on that isolation the same way. claude --worktree errors with “Can only use --worktree in a git repository” unless you have a WorktreeCreate hook. For a solo project, git init and a first commit are the cheap fix.

Related reading

Leave a Comment