How to Run Many AI Coding Agents in Parallel Safely

A git worktree is "a separate working directory with its own files and branch, sharing the same repository history and remote as your main checkout," as the Claude Code documentation defines it (Claude Code worktrees docs). Each agent edits its own copy of the files, so one can build a feature while another fixes a bug in the same repository.

Worktrees are a plain git feature, so they work with any agent. Superset's guide to parallel agents shows the setup from a clean repository (Superset):

git rev-parse HEAD                                   # record the shared base
git worktree add -b task/format-tests ../app-format-tests HEAD
git worktree add -b task/search-copy  ../app-search-copy  HEAD
git worktree add -b task/setup-docs   ../app-setup-docs   HEAD
git worktree list

Then start one agent in each directory. Superset adds a warning worth repeating: "Use a worktree per independent writer. Opening three terminals inside one workspace does not give them three isolated working directories."

Record the starting commit and use it for every worktree. That gives you "a known point to compare against during review."

Two details catch people out:

• A worktree is a fresh checkout. Untracked files such as .env are not copied, and dependencies are not installed. The Claude Code documentation recommends initializing the environment in each worktree and describes a .worktreeinclude file that copies listed ignored files into new worktrees automatically.
• Some things are shared. All worktrees write to the same .git directory, so commits and branches from one are visible in the others. Some tool settings are also shared across worktrees of the same repository, which the Claude Code documentation lists.

Agent tools increasingly create worktrees for you. Claude Code can start a session in a worktree and can give each subagent its own temporary one, removing it automatically when the subagent finishes without changes (Claude Code worktrees docs). Osmani lists several orchestration tools that run each agent in its own worktree with a shared review dashboard.

Superset states the limit of worktrees clearly: "A Git worktree separates files and the index. It does not allocate a new database, port, container name, or provider rate limit" (Superset).

Ports. Two dev servers cannot both bind to the same port. Give each worktree its own, usually through a PORT variable in that worktree's .env.local (MindStudio).

Databases. A shared local database is the most common source of confusing failures. "If agent A runs a migration or seeds test data, agent B is now working against a different schema or dataset than it expects." MindStudio describes three options:

1. A separate SQLite file per worktree, set by environment variable.
2. A separate Postgres database per worktree, such as my-project-feature-a.
3. A database branching service that forks a copy of the database per branch.

Other services. Caches, search indexes, queues and object storage all need the same treatment if agents write to them. The engineering team at Trigger.dev found this cost too high for their monorepo: each worktree would have needed its own Postgres, Redis, ClickHouse and more just to run the dev server, and disk use climbed fast (Trigger.dev). They moved to a different branching approach in a single working directory. The lesson is not that worktrees are wrong but that the runtime cost of isolation depends on your stack. Count the services an agent needs to run your app before deciding how many agents to run.

Write each worktree's runtime settings down where the agent will read them:

## This workspace
- Dev server: http://localhost:3002 (PORT=3002)
- Database: postgresql://localhost/app_search_copy
- Do not change shared config, dependencies or other packages.

MindStudio recommends exactly this, because without it, "agents will sometimes make 'helpful' changes to shared utilities or configs that create merge conflicts later."

Worktrees keep agents from colliding with each other. They do nothing to keep an agent from reaching your home directory, your cloud credentials or the open internet. With several agents running unattended, that matters more.

Penligent's guide to sandboxes for coding agents frames the purpose well: sandboxes do not make models trustworthy, but "they define the blast radius when a coding agent inevitably does something you did not mean to authorize" (Penligent). It describes five boundaries a sandbox should enforce:

• Filesystem: the agent reads and writes only its working tree or mounted volumes.
• Process and kernel: packages, services and subprocesses stay inside the sandbox.
• Network: outbound access follows a policy instead of being open by default.
• Credentials: the agent cannot read the keys you meant to protect.
• Lifecycle: the sandbox can be started, paused and deleted, keeping and destroying the right things.

The same guide compares isolation models, from shared-kernel containers through application-kernel sandboxes to microVMs and full virtual machines, and notes that their security properties are "materially different." A container may be fine for trusted internal automation. An agent that installs arbitrary packages and runs builds unattended deserves a stronger boundary.

The practical minimum for parallel agents: give each agent only the credentials its task needs, keep production credentials off the machine entirely, and do not let unattended agents push, deploy or merge.

Isolation prevents agents from editing the same files at the same moment. It does not prevent their changes from conflicting when you combine them. Superset is direct about this: worktrees "do not prevent merge conflicts or incompatible changes when you combine the branches" (Superset).

The answer is task selection. Superset's first example uses three tasks with clearly separate ownership: tests for an existing helper, an interface copy change, and a documentation fix. It warns: "Avoid pairing an API rewrite with tests that depend on the old API. Different filenames alone do not make two tasks independent."

Rules for choosing parallel tasks:

1. Separate ownership. Each task owns a distinct part of the codebase. Osmani notes that focused agents do better work: an agent that "only sees the files it owns" writes better code in that area (Addy Osmani).
2. No shared contracts in flux. If one task changes an API, a schema or a shared type, run the tasks that depend on it afterward, not alongside.
3. One owner for shared changes. "If two tasks need to change the same dependency, assign that change to one agent before the others continue."
4. A scope and a check for each. Superset's task prompts each name the files to change, the check to run, what to do if something is ambiguous, and end with "Do not commit, push, or merge."
5. A plan first for risky tasks. Osmani recommends requiring a written plan and approving it before implementation, because "it's far cheaper to fix a bad plan than to fix bad code."

When tasks do depend on each other, coordination tools help. Osmani describes agent teams with a shared task list, dependency tracking and file locking, so a blocked task starts automatically when the task it depends on finishes. Even then, his advice on scale is restrained: three to five teammates, because "three focused teammates consistently outperform five scattered ones."

Parallel work ends in serial review. Superset's per-workspace checklist (Superset):

1. Inspect git status --short for unexpected files.
2. Read the diff, including changes outside the requested scope.
3. Check the exact test command and its output. "A skipped or failed check stays unresolved."
4. Ask for corrections in that workspace before accepting the patch.
5. Commit and open a pull request through your normal review process.

Then merge carefully. "Integrate accepted branches one at a time. Run the relevant checks on the combined result after each merge. Two individually passing branches can still fail together, even when Git reports no textual conflict." Contracts, permissions and error paths deserve the closest look, because those are where two correct changes combine into a broken one.

Watch your own capacity. Superset advises watching "memory, build load, and provider limits" and starting fewer agents "if the machine becomes slow or the review queue grows." Osmani suggests a dedicated reviewer agent for every few builders, which can catch obvious problems before a person looks, but it does not replace the person who approves the merge.

Worktrees and branches pile up. Clean up only after the work is accepted or deliberately abandoned.

Stop each workspace's dev server and agent first, then remove the worktree from the main checkout:

git worktree remove ../app-format-tests
git worktree list

Superset notes that "Git refuses removal when a worktree contains changes it needs you to handle," and advises inspecting those changes "instead of adding --force." Removing a worktree keeps its branch, so decide separately whether to delete the branch.

Agent tools that create worktrees may clean them up on their own. The Claude Code documentation describes checking a worktree for uncommitted or untracked work before removing it, prompting when work exists, and sweeping old subagent worktrees on a schedule (Claude Code worktrees docs). Know what your tool does before you rely on it, so a forgotten worktree with useful work in it is not swept away.

Run this way, parallel agents become a queue of small, isolated, reviewable branches. The speed comes from the agents. The safety comes from isolation, task choice and one-at-a-time merges.