If you searched for "run parallel Claude Codes," you are probably past the first-agent stage. One Claude Code session in one terminal is fine. The trouble starts when you have several terminal tabs and windows open, and you cannot quickly tell which directory, branch, or task each session owns.
Then the same-repo problem shows up. Two agents can edit the same checkout, overwrite local state, or leave you with changes that are hard to separate into clean reviews.
The practical answer is worktrees plus a good UI. Worktrees give each task its own checkout and branch. Conductor gives those worktrees a Mac app around them: chats, terminals, run scripts, diffs, checks, pull requests, and archive flow.
Use one workspace per independent Claude Code task
Conductor's unit of independent work is a workspace. Each workspace is backed by a git worktree, gets its own branch and working directory, and keeps its terminal, diff, checks, and pull request path separate.
Use separate workspaces when the tasks can ship separately: independent features, bug fixes, GitHub issues, Linear issues, pull request fixes, or experiments you may discard.
Use multiple chats in one workspace when the Claude Code sessions need the same branch and current code state, such as one session implementing while another reviews or repairs tests.
Split sessions by task
A single terminal session works for one task. When work can ship separately, move it into its own workspace.
Use worktrees for isolation
Each workspace gets its own branch and working tree, so Claude Code is not editing the same checkout as another agent.
Keep runs attached to the branch
Start app processes, commands, and validation from the workspace that owns the change.
Review from one UI
Inspect one diff at a time, check status, open a pull request, then merge or archive the workspace.
For the full step-by-step workflow, see Run multiple Claude Code sessions in parallel.
Watch the workflow
Use these walkthroughs to see the terminal-to-workspace problem and the Conductor workflow in context.
They cover:
- why several Claude Code terminal sessions become hard to track across tabs, windows, directories, and branches
- how worktree-backed workspaces isolate independent tasks in the same repository
- how Conductor keeps each task's chat, terminal, local run state, diff, checks, pull request, and archive flow visible
- how Claude Code and Codex can run in parallel when you want to compare plans or split work across agents
Managing multiple Claude Code sessions with Conductor
Choose when agents should use separate workspaces or share one workspace.
Conductor CEO Charlie Holtz walks through his AI coding setup
See how Conductor fits into a real parallel agent workflow.
Where native Claude Code worktrees fit
Claude Code documents native parallel sessions with worktrees through claude --worktree. That workflow is useful when you want isolated Claude Code CLI sessions and are comfortable managing setup, local processes, diffs, and cleanup yourself.
Conductor is for the next layer up: the workspace around the agent. It creates isolated workspaces, copies or prepares local state, starts run scripts from the right directory, keeps each diff visible, tracks checks, and gives each task a path to a pull request.
Read the official Claude Code worktrees docs if you want the native CLI model. Use Conductor when you want parallel Claude Code sessions plus workspace setup, review, and merge flow in one UI.
Set up the repo before you fan out
Parallel Claude Code sessions work best when a new workspace can become runnable without manual repair. Put static gitignored files in Files to copy. Put dependency installation, generated files, symlinks, local database setup, and other repeatable preparation in setup scripts.
If several workspaces need local dev servers at once, use CONDUCTOR_PORT so each workspace gets a separate port range.
Before you start five agents
Prepare the repo once, then fan out safely.
- Give every agent a task that can finish independently.
- Copy required `.env` files or configure Files to copy before fanout.
- Move generated setup into setup scripts instead of doing it by hand.
- Use `CONDUCTOR_PORT` when several workspaces need local servers.
- Avoid assigning two agents the same broad file-heavy refactor.
- Review, merge, or archive one workspace at a time.
Common patterns
For issue fanout, create one workspace per issue, give each Claude Code session a narrow prompt, and review the resulting branches separately.
For implementation plus review, keep both sessions in one workspace if the reviewer needs to comment on the same in-progress diff.
For risky experiments, use separate workspaces. Archive the branches that do not work and keep the one worth turning into a pull request.