Three AI Agents, One Laptop: The Git Worktree Trick That Makes Parallel Coding Work

Your AI coding agent is fast. Your checkout is not. The agent writes code in ninety seconds, and then it sits in the same directory as your running dev server, your uncommitted changes, and the branch you were halfway through reviewing. So you wait, serially, for one agent at a time, because everything else collides.

The fix is not a new app. It is a Git feature from 2015 that you probably use twice a year, promoted to the main event: git worktree.

Full disclosure: I have not run these exact three-agent sessions myself. What follows is a researched guide built from the official Git documentation, Anthropic's own worktree docs, Conductor's published workflow guide, and the brand-new open-source app Maestro. The workflow is real, the commands are real, and the pattern is what an entire wave of new tools is built on. The parts that are opinion are labeled as mine.

Why the whole industry suddenly agrees on one trick

Something shifted this week, and it was not one product. It was the convergence of several.

Cursor shipped Projects on September 10, 2026. A coordinator agent that directs fleets of subagents, keeps context across months of work, and can pick up work from Slack messages, pull requests, or a schedule. Cursor's own numbers: new users merge 30% more PRs, and users who primarily use Projects merge six times as many.

Maestro hit Hacker News on September 12, 2026. An open-source, cross-platform desktop app that runs Claude Code, Codex, Cursor, OpenCode, Kimi Code, and Grok Build in parallel, each in an isolated git-worktree-backed workspace with its own branch, terminal, chat, and diff. The README is explicit that it is a functional clone of Conductor. Auth passes through to each CLI's existing login, so the app never stores model API keys.

Conductor itself has published the playbook. Their docs describe the exact workflow: one workspace per task, each backed by a git worktree and its own branch, with setup scripts, run scripts, and a PR flow attached. The unit of independent work is the workspace, not the chat window.

Three different products, three different teams, one shared primitive underneath: one agent, one branch, one directory, zero collisions. You do not need to install any of them to get the benefit. You need git worktree and about ten minutes.

The problem worktrees actually solve

Run two agents in one checkout and you get a specific, predictable mess:

• The branch problem. Both agents need their own branch. But a Git checkout has one HEAD at a time. When agent B switches branches, agent A's uncommitted work breaks or vanishes from view.
• The file collision problem. Both agents edit the same files. Even on different branches, they are editing the same working directory, so git status becomes a crime scene.
• The environment problem. Both agents run npm install, kick off builds, or start dev servers. Port conflicts, half-installed dependencies, clobbered node_modules.

git worktree fixes all three at once. Instead of one checkout, you keep one repository with multiple working directories, each checked out to a different branch, each with its own files and its own node_modules if you want them. The repository data stays shared, so a second worktree costs you disk only for the working files, not a full clone.

$ git worktree list
/home/jamil/app                  abc1234 [main]
/home/jamil/app-agents/auth      def5678 [agent/auth-flow]
/home/jamil/app-agents/search    9876abc [agent/search-api]

One repo, three directories, three branches, three agents. They physically cannot collide.

The ten-minute setup

Here is the whole workflow, without any app. Git 2.5 added worktrees in 2015; everything below works on any Git from the last decade and any machine that runs your agent CLIs.

Step 1: One-time repo prep

# From your main checkout
git fetch origin
mkdir -p ../app-agents

# Naming convention: <project>-agents/<task-name>

That is it. No config, no plugins. If your repo has gitignored files you need per worktree (like .env), copy them manually or script it, because worktrees only carry tracked files.

Step 2: One worktree per task

# Terminal 1: the auth task
git worktree add ../app-agents/auth -b agent/auth-flow origin/main

# Terminal 2: the search task
git worktree add ../app-agents/search -b agent/search-api origin/main

# Terminal 3: the flaky test fix
git worktree add ../app-agents/flaky-tests -b agent/flaky-tests origin/main

Each command creates a directory, a branch, and a clean checkout of origin/main inside it. Three terminals, three directories, three agent sessions. Nothing shared except the object database.

Step 3: Isolate the environment too

This is the step most guides skip, and it is where parallel agents go wrong in practice.

cd ../app-agents/auth
npm install                      # its own node_modules, its own versions
cp ../../app/.env .env           # worktrees only carry tracked files

# Per-worktree port so two dev servers can run at once
PORT=5174 npm run dev

The new tools solve this with env injection. Conductor exposes a CONDUCTOR_PORT variable for exactly this purpose. Maestro goes further and checks shared setup into the repo so every workspace bootstraps itself, taken from its repository settings:

# .maestro/settings.toml, from Maestro's docs
[scripts]
setup = "npm install && cp ~/secrets/.env .env"
run = "npm run dev -- --port $WORKSPACE_PORT"

You can get the same effect with two lines in your own repo: a scripts/setup.sh that installs dependencies and copies local files, and a run command that takes a port argument. Check them in so every worktree, and every teammate, gets them free.

Step 4: Run the agents

Now open one terminal per worktree and start your agent in each:

# Terminal in app-agents/auth
claude "Implement email + password auth per the spec in docs/auth-spec.md.
Write tests first. Run the test suite before you finish."

# Terminal in app-agents/search
codex "Add a paginated search endpoint for the products table.
Match the existing handler patterns. Verify with the integration tests."

# Terminal in app-agents/flaky-tests
claude "Fix the intermittent failure in orders.spec.ts. First reproduce it
10 times, then fix the race, then prove it passes 10 runs clean."

Each agent sees only its own directory, its own branch, its own changes. When two of them want to touch the same file, you find out at PR review time as a normal merge conflict, not as silent corruption in your main checkout.

Step 5: Land the work, then clean up

# In each worktree, when the agent finishes
git add -A && git commit -m "agent: add auth flow"
git push -u origin agent/auth-flow
gh pr create --fill

# Cleanup reclaims the disk immediately
cd ../app
git worktree remove ../app-agents/auth
git branch -d agent/auth-flow   # after merge

git worktree remove deletes the directory and unregisters the worktree in one step. The full lifecycle is one command to create, one to retire.

The house rules that make it scale

The commands are the easy part. These rules are what separates a smooth parallel workflow from three agents stepping on each other through the merge queue.

One task per worktree, and one worktree per task. The moment a task grows a second concern, split it. The whole point is that each directory has exactly one job, one diff, one review.

Branch from the same base. Branching all three from origin/main keeps the eventual merges symmetric. If one task depends on another, do not run them in parallel; run them in sequence in the same worktree, or rebase the dependent worktree when its dependency lands.

Cap it at three or four concurrent agents. Every agent is burning tokens and CI cycles. Cursor's Projects launch advertises delegating to thousands of subagents, but that is a cloud product with dedicated computers per Project. On one laptop you are the scheduler, and the bottleneck is your review attention, not the agents' speed. Conductor's docs put it plainly: parallel work is still limited by your account, model access, local resources, and permissions.

Your machine is still the trust boundary. Worktree isolation is development-grade convenience, not a sandbox. Maestro's own README says it outright: agents run with your local permissions. If a task is risky, that is a container problem, not a worktree problem.

Write the setup script before the second worktree. The first worktree works fine with manual copying. The second one is where "why is the dev server port already taken" starts. Check in scripts/setup.sh and per-worktree port handling early.

When to graduate to a tool

Plain worktrees scale surprisingly far. Graduate when one of these becomes true:

• You are re-typing the same setup and port juggling every day, and checked-in scripts stop being enough. Conductor, Maestro, and similar apps wrap the exact workflow above with a sidebar, per-workspace chats, diff review, and a PR flow.
• You want work to continue when the laptop closes. Cursor's Projects runs each Project on a dedicated cloud computer. Local worktrees die with the laptop.
• You want external triggers. A coordinator watching Slack, reacting to CI failures, or running on a schedule is a tool feature, not a Git feature.

Until then, the tool-free version has one honest advantage: nothing new to trust. No Electron app with database access, no analytics, no vendor wrap around your agent logins. Maestro is open source under BSL 1.1 (converting to Apache 2.0 after four years per version), which is a reasonable license, but the zero-dependency version needs trust in exactly one thing: Git, which you already trust.

The takeaway checklist

• [ ] One repo, N worktrees, one task per worktree
• [ ] All branches cut from the same base
• [ ] Checked-in setup script plus per-worktree port
• [ ] Copy gitignored files (.env) manually or by script
• [ ] Cap at 3 or 4 concurrent agents
• [ ] Review every PR like the agent is a junior dev, because it is
• [ ] git worktree remove the moment a task lands

What I would watch next

The interesting question is no longer "can agents run in parallel," it is "who coordinates them." Cursor's Projects bets on a coordinator inside your editor. Conductor and Maestro bet on human-driven workspaces. OpenAI shipped an Agents API aimed at the same layer. The coordination layer is where the next twelve months of competition will happen, and it is also the layer where, per Cursor's own launch numbers, the productivity multiples live.

But the foundation under every one of those bets is the same ten commands you just read. Learn the primitive first. The tools will keep changing; the worktree will not.

---

I write about developer tools, AI agents, and backend engineering every week. Subscribe, it is free.

Have you run multiple coding agents in parallel yet? Did you go straight to a tool like Conductor, or roll your own worktree setup? Tell me in the comments.