Setting up parallel worktrees without conflicts
EngineeringEducation

How to Run Multiple Claude Agents at the Same Time Without Conflicts

Jul 08, 2026

Share this article:

Author: Pepe

To run multiple Claude agents at the same time without conflicts, isolate each agent so no two write to the same files at once. The reliable way to do that is to give each agent its own git worktree, a separate branch and checkout that shares one underlying repository. This stops the collisions that corrupt output when two agents edit the same file on the same working tree.

Below is how conflicts actually happen and how git worktrees prevent most of them. It also covers how to get that isolation running in parallel without the manual git plumbing the standard approach requires.

What Causes Conflicts When Running Multiple Claude Agents?

Conflicts come from shared state. When two agents run against the same checkout, both read and write the same files on disk at the same time. One agent rewrites a function while another is mid-edit in the same file, and the later write wins. The result is lost work, half-applied changes, and a working tree that no longer matches what either agent thinks it produced.

The most common failure modes are concrete:

  • Two agents editing the same source file, so one overwrites the other's changes.

  • Shared configuration files like package.json, lockfiles, or build configs that every agent touches.

  • Shared dev-database or migration state, where one agent's schema change breaks another agent's assumptions.

  • A single working branch, where uncommitted changes from one agent pollute the next agent's context.

Coordination alone does not fix this. You can tell agents to divide work by directory, front-end here and back-end there, but a single slip still writes to the wrong path. The durable fix is physical isolation at the filesystem level.

How Do Git Worktrees Prevent Conflicts?

A git worktree is a separate working directory with its own checked-out branch that shares the same .git repository and history. Each worktree has its own files on disk, so edits in one never touch files in another. You can have one agent building a feature in one worktree while a second fixes a bug in another, and neither can see or clobber the other's changes.

The standard manual setup looks like this:

# One worktree and branch per task
git worktree add ../project-auth -b feature/auth-refactor
git worktree add ../project-payments -b feature/payment-flow
git worktree list

Then you open a terminal per worktree, install dependencies in each directory, start a Claude agent in each, and merge the branches back when the work lands. Claude Code has since built this pattern in natively: the --worktree flag creates an isolated worktree from the CLI, and the desktop app creates a worktree for every new session automatically. That native adoption is a good signal for how central worktree isolation has become to running Claude Code in parallel, and it works.

It also carries real overhead. Every worktree needs its own npm install, its own .env, and often its own database and ports so services do not collide. You manage a terminal per agent and track which branch belongs to which task by hand. The isolation is sound; the plumbing around it is what slows people down (and that plumbing is part of why AI coding tools tend to cost more than the subscription price suggests).

How to Run Parallel Claude Agents Without Managing Git Worktrees Yourself

Unstoppable Code is an agentic development environment — a category distinct from AI-assisted editors like Cursor that bolt agent features onto an existing editor (see AI IDE vs. Agentic Development Environment for the difference) — that runs each agent in its own isolated git worktree automatically. You get the same branch-and-checkout isolation that prevents conflicts, without running git worktree add, wiring up per-worktree environments, or juggling a terminal per agent. Your working branch stays clean because no agent runs against it.

It's a desktop app, and currently macOS-first: that's the GA download, while a Windows build exists but is gated off for general release (unsigned, still maturing). If your team is on Windows, plan around that until it reaches parity.

That removes the setup cost of the manual approach, and it adds two controls the manual approach does not have.

Review the Plan Before Any Code Is Written

Unstoppable Code uses a plan, approve, then execute flow with a tracked audit trail. Each agent proposes what it intends to do, you review that plan, and code is written only after you approve it. This matters most when several agents run at once. You catch an agent that misread the task before it writes a line, not after it has produced a branch you throw away.

Choose the Model Per Task, and Keep Code Local

You can run Claude, Codex, or a local Ollama model, switchable per task in the same workspace. The manual worktree approach says nothing about which model runs where; here it is a per-task choice. The local-Ollama path is the one that keeps code fully on-device — Claude and Codex, like any hosted model, still send prompts and code context to Anthropic or OpenAI when you use them, so treat "keep it local" as an option you pick per task, not a blanket guarantee.

Two more capabilities extend this past a single burst of parallel work. Pipelines are a YAML execution engine, similar in shape to GitHub Actions, built for agent orchestration: repeatable multi-step workflows with retries, quality gates, and human-in-the-loop pauses. In practice, that looks like handing an approved plan straight to a preset such as Implementation (Autopilot), which implements, tests, and logs unresolved issues without you re-prompting at each step, or running a Code Review preset to get multi-provider review notes before you look at the diff yourself. It also ships MCP support, both an in-app MCP server and a manager for external MCP servers, useful if your team is already standardizing tools around the Model Context Protocol. Portal gives you browser remote control of local desktop sessions, so you can monitor and steer running agents from another device; it requires a connected cloud account, and chat content is relayed through Unstoppable's cloud to mirror it in the browser while a session is active. macOS is the primary platform. For the operational side of running several agents at once (naming conventions, monitoring, audit trails) see How to Manage Parallel Agents Without Losing Track.

Manual Worktrees vs. Unstoppable Code

For how this stacks up against an AI-first editor rather than a manual workflow, see Cursor vs. Unstoppable Code.

Does each agent get file isolation? Manual git worktrees: yes, one worktree per agent. Unstoppable Code: yes, one isolated worktree per agent, created automatically.

What's the setup per task? Manual: git worktree add, then install deps and configure env/ports by hand for each one. Unstoppable Code: handled by the app.

How do you manage sessions across agents? Manual: one terminal per agent, tracked by hand. Unstoppable Code: parallel sessions in one workspace.

Is there plan review before code gets written? Manual: none built in. Unstoppable Code: a plan, approve, execute flow with a tracked audit trail.

Can you choose a different model per task? Manual: not addressed — that's a separate tool choice, not something worktrees solve. Unstoppable Code: Claude, Codex, or a local Ollama model, switchable per task.

What about repeatable workflows? Manual: shell scripts you write and maintain yourself. Unstoppable Code: a YAML pipeline engine with retries and quality gates.

Which Conflicts Do Worktrees Not Solve?

Worktree isolation prevents file-level collisions. It does not resolve every kind of conflict, and it helps to know the edges.

  • Merge conflicts at integration. Isolated branches still have to merge. If two agents changed the same function on different branches, git flags the conflict when you combine them. Isolation defers the conflict to merge time, where it is visible and reviewable, instead of silently corrupting a shared file.

  • Shared external services. A worktree isolates files, not a live database or a third-party API. Two agents pointed at the same dev database can still interfere. You separate that state per worktree, which is part of the manual setup cost described above.

  • Semantic conflicts. Two agents can each produce correct code in isolation that breaks when combined, for example one renaming a function the other still calls. This is why reviewing plans before execution matters: you catch the disagreement before both branches exist.

The Short Version

Run each Claude agent in its own git worktree so no two write to the same files at once. That is the mechanism that prevents conflicts. Set it up by hand with git worktree add and a terminal per agent, or let Unstoppable Code create an isolated worktree per agent and add plan review and per-task model choice on top. Start at code.unstoppabledomains.com.