How to run multiple Claude Code sessions in parallel

Why two sessions in one checkout go wrong

You can start claude in two terminal tabs in the same folder, but both sessions then edit the same files on the same branch. One agent's half-finished change breaks the other's test run, a formatter rewrites a file the other agent is mid-way through, and when you finally commit you get a single diff mixing two unrelated tasks. Nothing crashes, the work just gets tangled.

The fix is to give every session its own working directory. A git worktree is exactly that: a second (third, fourth...) checkout of the same repository, on its own branch, sharing one .git history. It is cheaper than a second clone, and every branch you create is immediately visible from all the others.

Option 1: the built-in --worktree flag

As of September 2026, Claude Code can create the worktree for you (Anthropic's worktree docs). The repository needs at least one commit first. From your project root:

claude --worktree feature-auth

This creates .claude/worktrees/feature-auth/ at the repository root on a new branch called worktree-feature-auth, and starts the session inside it. Run the same command with a different name in a second terminal to start a second, isolated session. A few details worth knowing:

• Add .claude/worktrees/ to your .gitignore so the worktrees don't show up as untracked files in your main checkout.
• By default new worktrees branch from your repository's default branch on the remote, not from whatever you have checked out. Setting worktree.baseRef to "head" in your settings branches from your current HEAD instead.
• Gitignored files such as .env are not copied. List them in a .worktreeinclude file at the project root (same syntax as .gitignore) and Claude Code copies them into each new worktree.
• When you exit, Claude Code checks for uncommitted changes and new commits. A clean, unnamed worktree is removed automatically; otherwise it asks whether to keep or remove it.
• Recent versions also list a --tmux option in claude --help, which opens the worktree session in its own tmux session (it requires --worktree).

If you are happy with those defaults, this is the quickest route. The manual route below gives you full control over folder names, branch names and the starting point, and it works with any agent, not just Claude Code.

Option 2: create the worktrees yourself

1. Start from a clean state. Commit or stash what you have, so every worktree starts from a known commit.

2. Add a worktree per task. Put them next to the repo rather than inside it, so tools that scan the project folder don't pick them up:

cd ~/code/myapp
git worktree add ../myapp-auth -b feature/auth
git worktree add ../myapp-billing -b fix/billing-rounding

-b creates a new branch from your current HEAD. To check out a branch that already exists, drop -b: git worktree add ../myapp-review some-branch.

3. Set each one up. A worktree only contains tracked files. Install dependencies and copy any local config it needs:

cd ../myapp-auth
npm install            # or pnpm install, uv sync, bundle install...
cp ../myapp/.env .env  # untracked files don't come along

4. Start Claude Code in each worktree, one per terminal:

cd ~/code/myapp-auth && claude
cd ~/code/myapp-billing && claude

5. Check what you have at any point with git worktree list.

Keeping several sessions on one screen

Terminal tabs are fine for two or three sessions. Beyond that, tmux keeps them organised and lets them survive a closed terminal window:

tmux new -s agents -c ~/code/myapp-auth   # first window, first worktree
# inside tmux:
#   Ctrl-b c   new window (cd to the next worktree, run claude)
#   Ctrl-b %   split the current window side by side
#   Ctrl-b n   next window
#   Ctrl-b d   detach; everything keeps running
tmux attach -t agents                        # come back later

Name each tmux window after its branch (Ctrl-b ,) so you can tell at a glance which agent is which. If you also want the sessions to keep going after you close your laptop, see keeping Claude Code running with the lid closed.

Gotchas

• Ports. Two worktrees running the same dev server will fight over port 3000. Give each one its own port, for example PORT=3001 npm run dev if your framework reads PORT, and tell the agent which port it owns.
• Dependencies per worktree. Each worktree has its own node_modules, virtualenv or build folder. That costs disk space, but it means one agent upgrading a package can't break another agent's build.
• .env and other untracked files. They exist only where you created them. Copy them in (or use .worktreeinclude with --worktree), and never commit them from a worktree by accident.
• Shared services. Worktrees isolate files, not databases, Docker containers or caches. If two agents run migrations against the same local database, they will still collide. Use separate database names per worktree where it matters.
• One branch, one worktree. Git refuses to check out a branch that is already checked out in another worktree. That is a feature: it stops two sessions from committing to the same branch.
• Shared git state. Branches, tags and the stash are shared across all worktrees. A git stash pop in one worktree can pop a stash made in another, so tell your agents to prefer commits over stashes.
• Usage limits. Every session draws on the same Claude account. Five busy sessions use your plan's limits roughly five times as fast as one.

Merging the work back

Each worktree is just a branch, so you merge it the way you merge any branch. Commit inside the worktree, then either push it and open a pull request:

cd ~/code/myapp-auth
git add -A && git commit -m "Add OAuth login"
git push -u origin feature/auth       # then open a PR

or merge it locally from your main checkout:

cd ~/code/myapp
git merge feature/auth

If two agents touched the same files, merge the smaller change first and ask the other agent to rebase onto main (git rebase main inside its worktree) and fix the conflicts itself.

Cleaning up

git worktree remove ../myapp-auth     # refuses if there are uncommitted changes
git branch -d feature/auth            # once it's merged
git worktree prune                    # forget worktrees whose folders you deleted by hand

git worktree remove --force discards uncommitted changes, so only use it when you are sure. If you deleted a worktree folder with rm -rf, git keeps a stale record of it until you run git worktree prune.

The easier way: Maestro

All of the above works, and it is how most people start. After a week of juggling tabs, copying .env files and remembering which branch lives where, the bookkeeping becomes the job. Maestro is a free desktop app that does it for you: each workspace is its own git worktree on its own branch, with the agent's chat, a terminal and the diff side by side, and there is no cap on how many you run.

• Each workspace gets its own port (exposed to your scripts as $WORKSPACE_PORT), and a per-repo setup script such as npm install runs in every new worktree.
• Review each diff with inline comments that go back to the agent, then open a pull request from the app.
• Mix agents: Claude Code, Codex, Cursor, OpenCode, Kimi Code and Grok Build, with your own accounts.
• Follow and steer every session from your phone with Maestro Web.
• Runs on macOS, Windows and Linux.

More on how it wraps Claude Code specifically: a GUI for Claude Code. Running OpenAI's agent instead? The same workflow for Codex is in how to run multiple Codex agents in parallel.