<!-- Canonical: https://www.agentlist.io/learn/guides/parallel-agents-git-worktrees -->

[The agent fieldbook](https://www.agentlist.io/learn/guides)

# Run two coding agents without sharing a working directory

Set up separate Git worktrees for coding agents, define file ownership, and review the combined change before integration.

Supplemental guide4 min readPublished October 22, 2026Updated October 23, 2026

Two coding agents can make useful progress at the same time. They can also overwrite each other's changes, start competing development servers, or test a mixture of unfinished work. Before adding another agent, give each task a separate place to run and decide who will integrate the results.

This guide uses a small example: one agent fixes a CSV parser while another improves its documentation. The commands are illustrative. Use a disposable repository to try the procedure before applying it to active work.

## Start from a known commit

Run these commands in the repository you want to use:

```
git status --short
git rev-parse HEAD
git worktree list
```

Keep the commit ID in your task notes. If the checkout contains unfinished changes, leave them in place. Decide whether the agents need those changes before proceeding. A worktree created from `HEAD` starts from the committed version; it does not copy your uncommitted edits.

[Git worktrees](https://git-scm.com/docs/git-worktree) let one repository have multiple checked-out working trees. They share repository data while keeping per-worktree state such as the index and `HEAD` separate. That makes them useful for separating edits, but they are not a security sandbox.

Check for submodules before using this procedure. Git documents incomplete submodule support for multiple worktrees and advises against multiple checkouts of a superproject. If your repository uses them, stop and choose a repository-specific isolation procedure.

The manual also labels multiple checkout experimental. Branch refs, the stash, and default repository configuration remain shared. Limit each agent to its assigned branch and avoid repository-wide configuration or stash operations during concurrent work.

## Create one worktree per task

Choose unused branch names and directories. From the original checkout, run:

```
git worktree add -b agent/parser-fix ../agent-parser HEAD
git worktree add -b agent/parser-docs ../agent-parser-docs HEAD
git worktree list
```

The final command should show both paths and their branches. Give each agent its exact path. Ask it to confirm the path and branch before editing.

Assign the parser agent the implementation and its tests. Assign the documentation agent the guide and examples. If the parser's behavior is still undecided, have the documentation agent prepare an outline first. Parallel work helps when tasks have stable boundaries; it creates rework when one task depends on decisions the other has not made.

## Separate the runtime too

Give each development server a distinct port. Use separate test databases or fixtures when tests change shared state. Check where build tools write generated files. Two directories do not prevent two processes from modifying the same external service.

Put the integration rules in both briefs:

> Work only in your assigned checkout. Report any required change outside your file scope. Return the final commit ID, changed paths, checks run, and known limitations. Leave integration to the reviewer.

Install dependencies using the repository's documented setup. If setup fails, report the failing command before changing the project configuration to accommodate the new directory.

## Review the combined result

Inspect each diff before combining the work. Verify that the documentation describes the final parser behavior. Then run the relevant checks on the combined revision, including a documented example against the updated parser.

A passing test in each worktree does not establish that the merged result works. The parser could change a field name that the guide still uses. Integration is its own piece of work, with its own evidence.

Keep the worktrees until the results are preserved and accepted. Before removing the parser worktree, run this from the original checkout:

```
git -C ../agent-parser status --short --ignored --untracked-files=all
```

The [status command](https://git-scm.com/docs/git-status) marks ignored files with `!!`. Preserve any needed artifacts outside the worktree before removing it; ordinary status output hides ignored files. Repeat the check for the documentation worktree. If `git worktree remove` refuses because work remains, inspect that work rather than forcing removal.

Continue with [Ship a small change with a coding agent](https://www.agentlist.io/learn/guides/ship-with-a-coding-agent) for the review and release steps around a single task.

Sources checked October 23, 2026. Commands are illustrative; adapt the paths to your checkouts.

---

Source: [Run two coding agents without sharing a working directory | agentlist.io](https://www.agentlist.io/learn/guides/parallel-agents-git-worktrees). This is the public page rendered as Markdown; interactive controls require the website.
