Run several Claude Code agents in parallel with git worktrees

Git worktrees let multiple Claude Code sessions work in one repository without sharing a checkout. Each session can edit and test its own branch, while the main working directory stays available to you.

Why use a worktree for each agent

When two agents work in the same checkout, they can overwrite each other's edits, change files while another agent is testing, or leave the repository in a state that is hard to review. A git worktree gives each agent a separate working directory attached to its own branch. The branches still belong to the same repository, so you can compare changes and merge them when they are ready.

This is useful when a request has independent pieces. For example, one agent could update a backend endpoint while another adds a frontend view. If both need to edit the same files or depend on each other's unfinished changes, splitting the work may create more coordination than it saves. Make the boundaries clear before starting.

Create a worktree with git

Start from a clean, committed base so each branch begins from code the other sessions can see. Use git worktree add to create a directory and a new branch for each task:

git status
git worktree add -b feature/api ../app-api main
git worktree add -b feature/ui ../app-ui main

Replace main with the base branch for your repository. The example places sibling worktrees next to the current checkout; choose paths that make sense for your machine. Open a separate Claude Code session in each directory, and give each a focused task, the relevant paths, and the checks that show when its part is complete.

Keep the task descriptions narrow enough that agents can work independently. Tell each agent which files it is expected to change, what behavior to implement, and which test or build command to run. Ask it to commit its work on its own branch when finished. You can then inspect each branch's diff from its worktree and decide how to integrate it.

Coordinate agents with brindle

Creating worktrees by hand handles isolation, but you still have to start sessions, track progress, review branches and clean up. brindle supervises Claude Code and other coding agents, assigning workers their own branches and git worktrees. A supervisor can split a larger goal into tasks, keep track of dependencies, and review a worker's exact commit before merging it.

From a repository, start brindle and describe the goal along with what done means. For a multi-part task, include checks that can be run to verify the result. In autopilot, brindle uses goal milestones and their checks to track progress. Each worker has an isolated worktree, and brindle can queue a task until its declared dependencies have merged. The sidebar gives you a view of active workers and ones waiting for your decision.

cd ~/code/myapp
brindle init
brindle

brindle init detects project setup and check commands, then writes a .brindle/config.json for the repository. Review what it found and commit the config if your team should share it. Start brindle in the repository and give the supervisor the goal, its separate pieces, and the checks that apply. For example, you could ask for an API change and a UI change, with the API task completed before the UI integration begins.

Workers use their own branches. Under autopilot, or when review is enabled, brindle merges a branch only after a reviewer approves that exact commit and the configured checks pass. That gives you a review point for each worker's contribution instead of combining several uninspected changes in the shared checkout.

Make parallel work easier to review

Parallel work is most useful when tasks have clear interfaces. Agree on an API shape, file ownership or expected behavior before workers begin. If two tasks must modify the same component, assign them in sequence or have one worker own the integration. Worktree isolation prevents filesystem collisions; it does not decide how changes should fit together.

Give each task a specific check. A test for the API can catch a regression before its branch merges; a focused UI check can validate the other branch. A repository-wide check still matters before the overall goal is done. brindle can run configured checks before a merge and rerun milestone checks as the work progresses. The checks should be commands that actually exercise the behavior you asked for.

Keep the base branch current as work moves forward. A branch created earlier may need changes from a task that has since merged. brindle supports syncing a workspace from its base, and tasks with declared dependencies can wait until their prerequisites merge. If you use plain git worktrees, fetch or merge the relevant branch yourself and resolve conflicts in the worktree that owns the integration.

Finish and clean up

After reviewing a branch and confirming its checks, merge it into the base branch. With manual worktrees, remove a finished checkout using git once you no longer need it. Keep any branch with unmerged work; a worktree is a directory, while its branch holds the commits you may still need.

With brindle, review and merge through the supervisor, then close or remove finished workspaces as appropriate. A paused brindle session can be resumed with brindle continue. If the task was too small to divide, a single Claude Code session is usually simpler. For guidance on choosing work and setting checks, see Recommended use; for Claude Code workers and other providers, see Providers and models.

curl -fsSL pawdelta.com/brindle/install | sh