How to Run Multiple Coding Agents in Parallel With One Git Worktree per Agent

Several coding agents in one Git repository can use separate chat sessions, but those sessions do not separate their file edits. A Git worktree gives each agent a separate working directory and branch, while connecting all those directories to one repository. That lets agents work at the same time without writing into one another’s working files.

Use one worktree for each agent, give each agent a clearly scoped task, and review and combine the results one branch at a time. Worktrees separate edits, but they do not resolve conflicting changes, coordinate task dependencies, or isolate shared services such as databases and ports.

What each worktree isolates

A working tree is the set of checked-out files a developer or agent edits. A Git worktree is a separate working directory connected to the same repository. Each worktree has its own current commit, called HEAD, and its own index, the staging area Git uses to prepare a commit. Git shares some repository data and references between linked worktrees, so the worktrees are not separate clones and do not isolate machine resources. The Git worktree documentation describes how linked worktrees let you check out multiple branches from one repository.

This separation keeps one agent’s uncommitted file edits from appearing in another agent’s working directory. It does not guarantee that their changes will fit together. Two agents can change different files while making incompatible assumptions about an interface, or they can both edit the same file on separate branches and create a merge conflict.

Git normally prevents the same branch from being checked out in multiple worktrees. Give each agent a separate branch rather than bypassing that protection.

Plan independent tasks first

Parallel work helps when agents can make progress without waiting for one another. Before creating worktrees, choose a shared starting commit and divide the goal into tasks with clear outcomes. Where practical, assign different files to different agents, and tell each agent which files or interfaces to leave unchanged.

If one task depends on another agent’s design or output, complete the prerequisite first or make that dependency explicit. For example, an agent implementing an API should agree on the interface with an agent writing its tests before both start work. Visual Studio Code’s guidance for parallel agent sessions likewise recommends independent tasks, followed by review and validation.

Assign one person to review the branches, resolve conflicts, and verify the combined result. In each agent’s instructions, identify the task and relevant file paths. Also state which checks show the task is complete and which test commands to run. Ask the agent to report changed files, test results, and unresolved assumptions.

Create a branch and worktree for each agent

The commands below assume the integration branch is named main and the repository directory is named repo. Adjust the branch name and sibling directory paths to match your setup.

First check for local changes, then update the shared starting branch:

git status --short
git switch main
git pull --ff-only

If git status --short shows work you need to keep, commit or otherwise preserve it before switching branches. Then create one worktree and branch per agent:

git worktree add -b agent/api ../repo-api main
git worktree add -b agent/tests ../repo-tests main
git worktree add -b agent/docs ../repo-docs main

git worktree list

Each agent now has a separate directory and branch based on the same main revision. Start each coding session from its assigned directory, and tell the agent which directory and branch to use. Confirm its working directory before it edits files or runs commands. A separate session without a separate worktree does not provide file isolation.

Some coding tools create worktrees for you. For example, Claude Code documents a CLI worktree option, and Visual Studio Code provides a “New Worktree” choice in its Agents window. These features change how you create the checkout. You still need to assign tasks, review branches, and test the integrated result.

Prepare each checkout and shared resources

A new worktree contains files from its starting commit. It does not automatically include files with uncommitted changes, untracked files (files Git is not tracking), or ignored files (files Git excludes based on ignore rules) from the original directory. Visual Studio Code documents that behavior for its agent worktrees and notes that ignored files, such as local configuration or dependencies, need separate setup or configuration.

Check what each agent needs to run the project. That may include dependencies, generated files, local configuration, or an .env file. Avoid copying credentials into agent directories unless the agent needs them and the handling is appropriate for your environment.

Worktrees also do not isolate agents from shared machine resources. If two agents start a service on the same port or write to the same database, their worktrees do not prevent interference. Give test sessions separate resources or coordinate their use. The Codex worktree documentation describes worktrees as separating code changes, while the surrounding environment still requires separate management.

Review and integrate one branch at a time

When an agent finishes, inspect its changes and test them before merging. Check whether it committed its work, confirm that the diff (the list of changes) stays within the assigned scope, and review any tests it skipped or could not run. Then integrate one reviewed branch at a time from the main checkout:

git -C ../repo-api status --short
git diff main...agent/api

git switch main
git merge --no-ff agent/api
# Run the relevant project tests against the merged result.

Resolve any conflicts deliberately. After each merge, test the combined code, since a branch that passed on its own can still break when combined with earlier changes. If main advances while other agents are working, decide whether those branches need a merge or rebase under your normal Git practice, then test them again.

Keep each worktree until its changes have been reviewed and validated. After you no longer need it, remove it through Git and delete the merged branch:

git worktree remove ../repo-api
git branch -d agent/api
git worktree list

Git protects worktrees with uncommitted changes from ordinary removal. If you deleted a worktree directory outside Git, git worktree prune removes stale administrative records; do not use forceful cleanup as the routine path.

Add agents only when review can keep up

More agents do not automatically mean faster delivery. A March 2026 preprint tested an approach that accounts for task dependencies while coding agents work asynchronously. It reported higher benchmark accuracy than single-agent setups on the tasks it evaluated. In one Commit0-Lite comparison, the Claude Sonnet 4.5 single-agent setup scored 53.1, while the four-agent setup scored 59.1. These results apply to that benchmark and setup; they do not predict performance in every repository. The study’s abstract and full paper provide the scope and results.

Start with a small number of clearly independent tasks. Add concurrency only when agents can work without sharing files or waiting on unfinished decisions, and when someone can review and test their output. No universal agent count fits every codebase; the useful limit depends on task dependencies and the capacity to integrate changes.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com