Running Multiple Coding Agents in the Same Repository

Running multiple coding agents in the same repository is a coordination problem before it is a coding problem. Parallel work succeeds when teams establish workspace isolation, file ownership, distinct identities, and conflict prevention before implementation begins. Git worktrees are the base, but teams also need shared engineering standards and control over merges to work well together, especially when separate tasks change the same behavior.

Why multi-agent repositories have become the default and what that shift demands

GitHub's Agents HQ expansion made it possible to select GitHub Copilot, Claude by Anthropic, and OpenAI Codex within one repository, run parallel sessions, monitor progress, and compare outputs. One developer prefers Claude Code, another uses Cursor, and others choose Codex or Copilot for particular tasks in the same repository. Parallel agents are now routine for many teams. Engineering now requires several agents to work together without undermining one another, extending beyond an individual agent's ability to code.

The coordination problems that appear before an agent writes its first line

Workspace isolation prevents agents from overwriting uncommitted changes, sharing dirty build caches, and confusing test output. File ownership determines who may change routing tables, configuration files, and component registries when unrelated tasks converge on them. Identity separation keeps commits, pull requests, and audit records attributable to individual agents. Conflict prevention addresses the less visible failure in which non-overlapping edits merge cleanly but disagree at runtime. Each problem needs a mechanism of its own. Separate directories cannot establish ownership, and distinct credentials cannot make two changes compatible.

What the research shows about how badly coordination actually fails

AgenticFlict found that 27.67% of agent-generated pull requests conflict with concurrent work, substantially exceeding typical human-authored conflict rates. The research attributes this to larger changesets, more files modified per pull request, and agents' lack of awareness of concurrent work. CooperBench tested how well agents code together on hundreds of tasks across multiple libraries and programming languages. It found that average success rates were roughly a third lower when agents worked together than when they did the same tasks on their own. Parallel execution has a measurable coordination penalty.

CooperBench identified work overlap, divergent architecture, and repetition as the most frequent failure symptoms, in that order. Messages can be vague, ill-timed, or inaccurate, but agents also deviate from commitments and form incorrect expectations about their counterparts. Because these failures tend to involve shared work and wrong assumptions, preventing them starts with boundaries that do not rely entirely on agents remembering what others said.

Using git worktrees to give each agent its own working directory

A git worktree is a separate working directory linked to the same repository, with its own branch, staged changes, and files on disk. All worktrees share the same git history. This makes them lighter than full clones while preventing agents from overwriting one another's uncommitted work. Branches alone do not provide that separation when agents operate in the same directory. In that arrangement, one agent's uncommitted changes appear in another's environment, stash operations collide, and build artifacts and caches become contaminated.

The command git worktree add .agents/agent-1 -b agent-1/task-auth creates a fresh checkout in a new directory on a new branch. Each agent then starts in the directory it was given. Running tests in that worktree before merging also catches an agent declaring completion because code compiles even though tests fail. An existing worktree can be reused by checking out a new branch, which is faster than creating another worktree on large repositories.

However, agents in separate worktrees can still compete for the same port or database, so each task needs its own port and tasks must be designed for independence. Branches can also conflict when they eventually merge. The repository's architecture therefore sets the useful concurrency limit. Loosely coupled modules and independent features support more parallel agents than tightly coupled code with shared state, regardless of how easily a tool can launch additional sessions.

Managing file ownership and preventing semantic conflicts in shared hotspot files

An agent tightens a validation helper to reject empty values while another adds a caller that passes an empty default. Neither edit overlaps the other's lines. Git merges both changes, the build stays green, and the disagreement is visible at runtime. This is a semantic conflict. Separate directories preserve both edits faithfully, but they cannot establish whether the edits agree about the helper's contract.

Routing tables, configuration files, and component registries create similar coordination pressure because many nominally separate features need to change them. Git can identify overlapping lines, and file ownership must be decided before implementation begins. The practical response is to assign tasks with clean module boundaries, mark hotspot files as shared in task descriptions, and prohibit changes to them without coordination. Configuration and registry edits can be reserved for a designated agent or a human-reviewed step.

Independence is what makes parallel work inexpensive. Tasks in separate services, modules, or repositories with no shared runtime state can proceed with almost no coordination cost. Where boundaries are less clean, a serialized merge queue brings branches into the canonical branch one at a time, exposing overlap incrementally. Merging agent-1 first means agent-2's merge encounters the changes already accepted from agent-1. This makes integration conflicts manageable, but a clean merge still does not prove behavioral compatibility, and genuinely cross-cutting work retains its coordination cost.

Giving each agent a distinct identity so attribution, peer review, and audit trails work

Shared credentials erase distinctions that separate worktrees leave untouched. The commit log may credit a human with work that person never saw, while the pull request history shows several agents as one actor. GitHub's self-approval block means a security agent cannot give a valid approval on an infrastructure agent's diff if both use the same account. When something goes wrong, “an agent did it” provides no useful attribution.

GitHub Apps can provide separate name[bot] identities, but authentication and commit authorship require independent setup. Git still draws that information from local configuration, so a pull request can show the bot while its commits name the machine owner. Both GIT_AUTHOR_* and GIT_COMMITTER_* must be set independently of the push token. One-hour installation tokens scoped per agent are preferable to long-lived secrets, with the private key kept in a vault and a token minted per session.

The EU AI Act requires high-risk systems to record events in enough detail to trace how they work, so a shared agent identity is a weakness when records need to show who did what. Retroactive attribution is not a reliable substitute. The Who&When benchmark found that the best judge-style attribution methods achieved only 53.5% accuracy at the agent level, with far lower accuracy at the step level. That result supports establishing identity before work starts rather than reconstructing responsibility from output after a failure.

Keeping engineering standards consistent across agents without duplicating them

Distinct identities make actions attributable, but they do not keep engineering practices consistent. Different agents read different instruction formats, and copying the same standards into each configuration leaves teams with separate versions to keep up to date. Drift follows when one workflow changes and the others do not. Key details about a feature can also stay buried in a chat session, so another agent lacks the information it needs to carry on. The coordination layer above git therefore needs a repository-owned source of truth.

The AGENTS.md convention provides a low-tech foundation through a single file at the repository root that supported agents read on startup. Portable guidance stays in one place, exposed through thin tool-specific adapters where needed. Specs, plans, and tasks kept in Git rather than chat history let agents resume work from repository artifacts during handovers. CI checks for missing or stale tool integrations make this harness approach verifiable without duplicating the engineering playbook for every new agent.

Tools that automate the worktree-isolation pattern at scale

Herdr is a Rust binary that runs in the terminal and describes itself as “tmux for coding agents.” It gives each agent a real terminal pane, with agent state, clickable panes, persistent sessions, remote attach, and a CLI/socket API. It detects 22+ agent CLIs, including Claude Code, Codex, OpenCode, Pi, Cursor, Copilot, and Grok. Its interface distinguishes agents working, blocked on input, or done. These controls address the practical difficulty of supervising many independent sessions without combining their workspaces.

Orca, by Stably AI, is a free, MIT-licensed desktop app that runs Claude Code, Codex, Cursor CLI, and approximately 30 other CLI agents side by side, each in its own git worktree. Parallel Code, by johannesjo, is also an MIT-licensed desktop app. It dispatches agents into worktrees and provides diff review and merge support for Claude Code, Codex, Gemini, Copilot, and Antigravity CLI agents. Both provide desktop interfaces for managing parallel work. Teams can compare which agents the tools support and what review controls they offer, though they still need isolation and control over how changes are merged.

Batty creates persistent worktrees per agent, dispatches tasks from a Markdown kanban board, runs tests before merging, and serializes concurrent merges with a file lock. Agents run in tmux panes, and installation uses cargo install batty-cli. The file lock makes serialization an enforced mechanism.

Bill Mongan's nine-agent setup illustrates the scale possible on a small always-on Ubuntu box with ~14 GiB RAM. It runs Claude Code, Codex, Antigravity, Grok Build, Hermes, GitHub Copilot, two copies of OpenCode, and Pi through Herdr. Each has a labeled tab and its own directory under ~/agents/<name>. The hardware need not be elaborate. At the platform level, Agents HQ provides monitoring, structured sessions, and output comparison within the repository workflow, moving some supervision out of local tooling without removing the need for explicit ownership and identity.

Where the worktree-and-serialized-merge pattern reaches its limits

The strongest limitation is the assumption that tasks can be partitioned cleanly. Routing tables, configuration files, and registries are cross-cutting by nature, so isolation moves part of their coordination cost into the merge queue. Autonomous coding models can hallucinate resolution logic, discard peer agents' committed changes, or preserve broken conflict markers in production builds. A system that merges more readily is not necessarily one that integrates correctly.

CodeCRDT explores conflict-free replicated data types at the abstract syntax tree level as a research direction for concurrent editing. CoAgent takes a different route through MTPO, a serializable concurrency-control protocol with advisory notifications. These remain research-stage approaches. For most teams today, the practical choice is still worktree isolation with human-reviewed merge serialization for hotspot files.