TL;DR
Running two coding agents at once usually goes wrong in three places: the files they edit, the runtime they share and the merge. A separate Git worktree per agent is the practical default for the first, because each gets its own checkout and branch. Ports, databases, containers and Git's shared branches and config still need separating by you, and some tasks should simply wait their turn. Agree file ownership and merge order before starting, then test the combined result, because two branches that pass alone can fail together.
Three places parallel agents collide
Two agents working in one checkout share one set of files, one Git index and one current branch. If one of them switches branch, stashes or reformats a file while the other is halfway through an edit, the second agent's work changes underneath it. That is the collision the question names, and most tools now handle it. Two more sit behind it.
In January 2026 someone asked on Hacker News how others run parallel agent sessions. Despite Anthropic's worktree documentation and apps built on worktrees, they still preferred separate clones when they needed to be sure the agents would not overlap. One reply said attention capped them at about three sessions, partly spent wondering how the agents would step on each other at merge time.
In May 2026 a feature request on Claude Code's GitHub asked for configurable worktree behaviour for background agents. One commenter added that many backend projects run on Docker, where a worktree per agent is not practical. A third Ask HN thread put the same problem plainly: multiple checkouts are easy, but they still share one local database, one set of services and one set of ports.
So the work has three layers: files and branches, the runtime, and integration.
Give each agent its own checkout and branch
A Git worktree is a second working directory linked to the same repository. It has its own files, index and HEAD, and Git refuses by default to check out a branch that another worktree already has. Each agent in its own worktree on its own branch no longer edits the other's files in passing. A worktree is a separate checkout, not a security boundary: an agent that writes to an absolute path or into the other directory can still reach it.
The main tools create worktrees for you, each with its own defaults (all checked on 1 October 2026):
- Claude Code.
claude --worktree <name>creates.claude/worktrees/<name>/on a new branch calledworktree-<name>. Background sessions move into a worktree before their first edit, and Claude Code blocks edits and commands aimed at the main checkout while a session is isolated (Claude Code worktrees). - Codex app. Worktrees live under
$CODEX_HOME/worktreesand start in a detached HEAD from the branch you selected. Work moves back to your checkout through its Hand off feature (Codex worktrees). - Cursor. Each task gets an isolated checkout, set up by the commands in
.cursor/worktrees.json, and/apply-worktreebrings the result into your main checkout (Cursor worktrees).
Two things surprise people. Git shares branches, tags and the repository config file across all worktrees, so an agent that deletes a branch or changes a config value does it for every worktree. And a worktree is a fresh checkout: .env, installed dependencies and build output are missing until a setup step adds them, which is what Claude Code's .worktreeinclude and Cursor's setup file are for.
Separate what the worktree leaves shared
Everything outside the checkout is still shared:
Comparison
| Resource | Shared between worktrees? | How to separate it |
|---|---|---|
| Files, index, HEAD | No | Nothing more to do |
| Branches, tags, repository config | Yes | Give each agent its own branch prefix; no config edits, no force pushes to shared branches |
.env, dependencies, build output | Not copied | A per-worktree setup script |
| Docker Compose containers, networks, volumes | If project names match, and always for explicit names and host paths | A distinct COMPOSE_PROJECT_NAME, then check the resolved config |
| Host ports | Yes, one machine | A port offset in each worktree's .env |
| Local database | Yes, if both use the same server and database name | A database name or container per worktree |
| Staging, sandboxes, queues, caches | Yes | Read-only access, a per-task prefix, or no parallel writes |
The Docker row has a trap. Compose uses the project name to keep environments apart, and without other settings that name comes from the directory, so two worktrees with different folder names get separate containers, networks and volumes (Docker Compose project names). A top-level name: in the Compose file overrides the directory, and then every worktree starts the same project unless COMPOSE_PROJECT_NAME overrides it. A volume with an explicit name: is "used as is and is not scoped" by the project (Compose volumes), an external volume is shared by design, a host bind mount points at the same folder, a fixed container_name collides, and published host ports collide because there is only one host. Run docker compose config in each worktree and compare the project name, volume names, mount sources, container names and published ports. In a test of two directories sharing one file, only the project, network and unnamed volume names differed; the named volume, bind mount, container name and port matched.
When separating the runtime costs more than it saves, run the tasks that need it one after another and parallelise only those that do not. Claude Code added worktree.bgIsolation: "none" for repositories where worktrees are impractical; background sessions then edit your working copy directly (agent view), so give them only tasks that touch different files.
Agree who owns what before the agents start
Most overwrites that worktrees cannot prevent are planned in, by two tasks that need the same file. Before starting either agent:
- List the files each task expects to change. Ask each agent for its plan before it edits, with the files named, and compare the two lists. Any overlap means split the tasks differently or run them in sequence.
- Name the hotspots. Lockfiles, database migrations, route and dependency registration, generated clients, test snapshots, translation files and changelogs are touched by almost everything. Give each one a single owner for this round; the other task notes the change it needs instead of making it.
- Land shared contracts first. If both tasks depend on a new interface or schema, merge that as its own small change and start both worktrees from it. Claude Code branches worktrees from the default branch unless
worktree.baseRefis set tohead; Codex starts from the branch you pick. - Fix the merge order and who rebases. The foundational or smaller change merges first. The second rebases onto the updated main branch, regenerates anything ordered or generated (migration numbers, lockfiles), and reruns its checks.
- Write the boundary into each prompt. Which files the agent may change, which it must not, and that it stops and asks rather than editing a file owned by the other task. A boundary hard to draw is a warning sign; the article on when parallel coding agents create more work than they save explains why.
Test the combination, not just the two branches
Two branches can merge without a conflict and still break each other. As an illustration: task A renames a configuration key and updates every reader it can find, while task B, written against the old code, adds a new reader that uses the old key. Git sees edits in different files, both suites passed in their own worktrees, and the merged application fails on start. Only a check of the combined code catches that:
- Preview the merge without touching a checkout.
git merge-tree --write-tree task-a task-bperforms the merge in Git's object store, writes nothing to any working tree or index, and reports conflicts (git merge-tree). - Run the full checks on an integration branch holding both changes, in a fresh worktree with its own runtime: the whole test suite, migrations applied to an empty database, and the application started and used along the paths both tasks changed.
- Let the host test merges in order. A GitHub merge queue groups each pull request with the latest base branch and the pull requests ahead of it, and merges only when the required checks pass on that group; CI workflows must trigger on the
merge_groupevent. It needs an organization-owned public repository, or GitHub Enterprise Cloud for private ones (GitHub merge queue). Elsewhere, requiring branches to be up to date before merging gives a similar check, with the author doing the rebasing.
When the two tasks turn out to depend on each other, a stacked series may suit them better than two parallel branches; the article on turning a huge AI-generated change into pull requests people can review explains how to order dependent pieces.
Paqad does not schedule parallel agents or create worktrees; that isolation stays with Git, your tools and your environment. Within one change, its graduated and full lanes on Claude Code and Codex CLI hand each stage to a fresh worker one at a time, so its own stage workers do not edit the same checkout at once. Since 1.91.1, two sessions in the same project keep separate "framework loaded" markers, and the end-of-turn check examines only the change owned by the session that made it, so work in one window does not block a question in another. Paqad's session continuity page explains what happens when two sessions work in the same project.
Frequently Asked Questions
How do I run coding agents in parallel without them overwriting each other's changes?
Start with two agents on tasks you already know are independent, each in its own worktree and branch, before trying more. The limit usually turns out to be your own review and integration time rather than the agents, so more sessions only help while you can still read and merge what they produce.
Which files and external resources could both tasks change?
Besides the files each plan names, look for what the tools write on their own. Run each worktree's setup and build once, then check git status: formatters, code generators and package managers often rewrite shared files that neither plan mentioned.
When do separate worktrees isolate enough, and which shared databases or ports still need separation?
A worktree is enough when a task's checks need no running service: unit tests with in-memory or mocked dependencies, documentation, refactors inside one module. As soon as a check needs a port, a database, a container or an external account, that resource needs its own copy or a queue.
How should file ownership and integration order be agreed before work starts?
Write it where the agent will read it: in the task prompt or the plan you approve, not only in your head or a chat with a colleague. A short line per task, such as "owns the billing module and its migration; must not edit the shared router", is enough to make a violation visible in review.
What combined checks prove the merged result works even if both isolated tasks passed?
Run both tasks' new tests together on the merged code, because each was written without seeing the other. If either task changed the schema, migrate a copy of the current database as well as an empty one, since an upgrade path can fail where a fresh install passes.