How to run multiple Claude Code agents on a Mac

There are three working ways to run multiple Claude Code agents on a Mac: git worktrees managed by hand, a dedicated orchestrator that manages worktrees for you, or a task board that dispatches one agent per task inside a running local environment. They solve different problems, and the right answer depends on whether your bottleneck is throughput or verification.

Option 1: git worktrees — by hand, or built in

This is the approach Anthropic's own Claude Code docs describe. A git worktree gives each agent an isolated copy of the repository on its own branch, so two agents can edit the same file without touching each other's work:

# one worktree per parallel task
git worktree add ../myapp-auth feature/auth
git worktree add ../myapp-billing feature/billing

# one terminal tab per worktree, one agent each
cd ../myapp-auth && claude
cd ../myapp-billing && claude

It works, and for two or three tasks it's honestly fine. The costs show up at scale: every worktree needs its own npm install or composer install, its own .env, and — the part everyone forgets — its own running services if the agent is supposed to check its work. You also become the scheduler: which tab was doing what, which branch is mergeable, which agent stalled twenty minutes ago.

Since v2.1.50, Claude Code does the worktree half of this natively — no git worktree add required:

claude --worktree auth     # or -w auth
claude -w billing
claude --worktree          # auto-named session

The mechanics, per Anthropic's worktree docs: each session gets an isolated checkout under .claude/worktrees/<name>/ on a fresh worktree-<name> branch cut from your default branch. A .worktreeinclude file copies the gitignored pieces a checkout normally loses — .env, local certificates — into each worktree. Cleanup is handled too: worktrees with no changes are removed when the session ends, and ones with commits prompt you to keep or discard. That erases most of the by-hand bookkeeping. What it doesn't change: the worktree still has no database, no running server and no inbox — the verification gap stays open.

Background agents: parallel sessions without the tabs

The same release line added background sessions, which replace the terminal-tab juggling entirely. claude --bg "fix the flaky auth test" launches an agent and returns immediately; /bg moves a running session to the background; and claude agentsopens a dashboard grouping every session into Needs Input, Working and Completed. Background sessions get their own worktrees automatically, so parallel edits can't collide. Two pieces of guidance straight from the docs are worth repeating: split tasks so agents touch different parts of the codebase (overlapping files still mean conflicts, worktrees or not), and remember that ten parallel agents burn your quota roughly ten times as fast as one.

With worktrees and background dispatch built in, the honest question for the tools below is what they add beyond that — and the answer is interface (boards, diff queues, dashboards-with-history) and, in one case, the environment itself.

Option 2: an orchestrator manages the worktrees

The current crop of orchestrators automates exactly that bookkeeping. Each takes a different interface to the same core idea — parallel agents, one worktree each:

• Claude Squad — terminal-native. Each agent gets a tmux session plus a worktree, with an experimental auto-accept background mode. Closest to the by-hand workflow, minus the tab juggling.
• Vibe Kanban — a Kanban board over worktrees, supporting 10+ agents. Community- maintained since Bloop wound down in 2026.
• Superset — branch-and-PR-first, with a built-in diff viewer and per-workspace port ranges. The founders themselves put the practical parallel ceiling at 2–3 complex tasks today, with human review as the bottleneck.
• Conductor — Mac-native, diff-first review UI over parallel Claude Code and Codex runs.
• Kanbots — a newer open-source board (May 2026) with per-run worktrees, a pre-push guard and GitHub Issues sync.

Pick by interface preference — terminal, board, or PR sidebar — and by agent roster. What none of them change is what's inside the worktree: code, and nothing else.

Option 3: a Kanban board inside a running environment

The third approach trades raw parallelism for verifiable work. In PortBay, the unit of work is a card on a Kanban board, and the project the card belongs to is already running — managed PHP or Node runtime, a per-project MySQL or PostgreSQL database, trusted HTTPS on a real .test domain, an email inbox, an optional public tunnel. The Claude Code Kanban workflow looks like this:

1. Write the task as a card: what to build, where, what done means.
2. Assign Claude Code (or Codex, Cursor, Antigravity — whichever is installed) and move the card to Todo.
3. PortBay dispatches the agent inside the running project. A lease marks the card In Progress so no second agent can claim it.
4. The agent does the work and checks it — runs the migration against the real database, loads https://yourapp.test, verifies the email landed in the local inbox.
5. It comments on the card describing what changed and moves it to Done. You review a described, tested change — not a mystery diff.

You can also dispatch conversationally: type @claude in any card comment, optionally with a directive, and the agent picks the task up from there.

The catch nobody mentions: verification, not generation

Run enough parallel agents and a pattern emerges: the constraint is never how many agents you can start — it's how much finished work you can trust. An agent in a bare worktree can't run a database migration, can't load the page it built, can't click the button it wired up. It reports done because the code compiles. The more agents you run that way, the more unverified diffs queue up for the one human in the loop.

That's the case for giving agents a real environment before giving them more parallelism — the argument What is a dev environment for AI coding agents? makes in full. Three verified cards beat eight unverified branches.

Practical guardrails, whichever option you pick

• One writer per surface. Parallel agents on the same feature converge on the same files. Split tasks by boundary — module, route, package — not by sentence in the same spec.
• Be careful with auto-accept modes.Unattended yes-to-everything flags (Claude Squad's is explicitly experimental) trade safety for throughput. Use them on tasks whose blast radius you've already bounded.
• Make “done” mean something. Whatever the tool, define done as verified in a running app, not “tests pass.” If your setup can't express that, that's the gap to fix first.
• Keep a claim mechanism.Two agents grabbing one task is wasted tokens at best. Boards with leases (PortBay) or per-run worktrees (Kanbots, Superset) handle this structurally; hand-rolled tabs don't.

Which setup should you use?

Two or three tasks, stack already running:plain git worktrees and two terminal tabs. Don't add tooling you don't need. Many small, low-risk tasks: an orchestrator — Claude Squad if you live in the terminal, Superset if you review by PR. Tasks that need a database, a browser and proof: a board with an environment under it — that's the job PortBay was built for, free and open source on macOS. And the options compose: wide sweeps in an orchestrator, verification-heavy cards on the board.