Running coding agents in parallel

One coding agent working through a backlog is fast. Several working at once are faster, until two of them edit the same file, share a database, apply each other's stashed changes or open more pull requests than anyone can review. Running agents in parallel is an isolation problem first and a review-capacity problem second.

This article covers how to isolate agents from each other, what git worktrees do and do not isolate, the ways today's tools run agents in parallel, how to split the backlog so parallel work does not collide, and how to merge the results safely. Most of the failure modes below are ones we have hit running agents in parallel on Stride's own repository. The tool facts were checked against each vendor's documentation on October 20, 2026; the sources are listed at the end.

Start with one reliable loop

Parallelism multiplies whatever your single-agent loop produces, defects included. Before running several agents, get one to the point where its stories are well specified, its checks are real and its pull requests pass review without major rework. The articles on writing stories, test-first work and review cover that loop.

Then add agents one at a time, and watch the review queue rather than the agents. The limit is almost always the number of changes a person can review properly, not the number of sessions a machine can run.

Give each agent its own checkout

Agents sharing one working directory overwrite each other's files and break each other's builds. The standard fix is a git worktree per agent: a separate directory with its own branch and files, sharing one repository history.

Claude Code has this built in. Starting it with claude --worktree feature-auth creates a worktree under .claude/worktrees/feature-auth/ on a new branch named worktree-feature-auth and starts the session there. The branch starts from your repository's default branch, not from the commit you are on; setting worktree.baseRef to "head" makes it start from your current work instead. Add .claude/worktrees/ to your .gitignore so the worktrees do not show up as untracked files. You can also create one yourself:

git worktree add ../project-feature-a -b feature-a
cd ../project-feature-a

A new worktree is a fresh checkout: it has no installed dependencies and none of your git-ignored files, such as local environment files. Install dependencies in each one. Claude Code can copy listed git-ignored files into each new worktree through a .worktreeinclude file at the repository root; it copies only files that match a pattern and are git-ignored, so tracked files are never duplicated.

When you exit a Claude Code worktree session, a clean worktree from an unnamed session is removed automatically, and one with changes prompts you to keep or remove it. Commit what you want to keep before you exit, and run Claude Code 2.1.304 or later: it fixed a case where the worktree and its branch were removed without asking when the worktree's HEAD had moved to another branch, which could lose commits.

What a worktree does not isolate

A worktree isolates files. It shares almost everything else with the main checkout, and the shared parts are where parallel agents collide.

• The repository's references. Branches, tags and the stash live in the shared repository. A branch can be checked out in only one worktree at a time, and the stash is a single stack across every worktree, so an agent that runs git stash pop can apply another agent's changes. Tell agents never to use a bare stash: commit work in progress to the branch instead, or stash with a unique message and apply that entry by its commit ID (git stash apply <sha>), because a position such as stash@{0} moves whenever another agent stashes.
• Configuration and hooks. Repository configuration and git hooks apply to every worktree, so a hook that runs on commit runs for every agent.
• Links on disk. Some Windows setups share node_modules between worktrees through a directory junction. A recursive delete of the worktree can follow the junction and delete the shared folder. Remove the link itself first, then the worktree. Since version 2.1.205 (July 2026), Claude Code deletes only the link when it removes a worktree it created, but a manual rm -rf will not be so careful.
• Permission approvals. Since Claude Code 2.1.211, approving a command with "don't ask again" inside a worktree saves the rule to the main checkout's settings, so it applies in every worktree of the repository and outlives the one where you approved it.
• Your machine. A worktree separates files, not access. An agent in a worktree can still read your home directory, use your credentials and reach the network; to limit that, use your tool's sandbox.

The ways tools run agents in parallel

You do not have to manage worktrees by hand. Claude Code documents five ways to work on several tasks at once:

• Subagents do side tasks inside one session, each in its own context, and can each get their own worktree. By default a session runs at most 20 at a time.
• Agent view (claude agents, a research preview) lets you dispatch sessions to run in the background and watch them from one screen. Each moves into its own worktree before it edits files.
• Agent teams have a lead session that splits the work, assigns tasks from a shared list and coordinates teammates. They are experimental and off by default, and they do not give teammates separate worktrees, so each teammate must own a different set of files. Anthropic suggests starting with three to five teammates.
• Dynamic workflows run many subagents from a script and check their results against each other, for jobs too big to coordinate one turn at a time.
• Projects run parallel sessions, called threads, in the cloud or on your computer, from one ongoing conversation. They are in public beta on the Pro and Max plans.

The /batch command packages the same idea: it splits one large change across 5 to 30 subagents, each in its own worktree.

The cloud agents isolate work differently. Each of Cursor's cloud agents runs in its own virtual machine on its own branch, and Cursor sets no limit on how many run at once, billing them at the model's API price. A GitHub Copilot cloud agent works on one branch and opens one pull request per task, and each session stops after 59 minutes. Whichever you use, the rest of this article still applies: isolation decides whether agents collide, and the review queue decides how many you can run.

Give each agent its own runtime

Files are only part of the environment. Parallel agents also collide on:

• Ports. Two development servers cannot both listen on the same port. Give each worktree its own.
• Databases. Two agents running migrations or integration tests against one database corrupt each other's state. Give each agent its own database, and make any destructive test setup refuse to run against anything that is not a disposable test database: a suite that truncates tables truncates whatever the connection string points at.
• Caches and generated files. Build caches, code generators and lock files written from two places at once produce confusing, intermittent failures.
• Rate limits. Services usually limit requests per user or per key, not per session. We have tripped our own per-user limit by running several agent-driven browser checks at once under one login, and every page after that showed an error state that looked like a real bug. Give each agent its own credentials where the service allows it, with only the access its story needs.

Split the backlog so agents do not collide

The best isolation is work that does not overlap. When you choose stories to run in parallel:

• Prefer stories that touch different files. Git reports a conflict when two branches change adjacent lines, not only the same line, so two small edits next to each other in one file are enough to collide.
• Serialise work on shared registries. Migration sequences, translation catalogues, route tables, lock files and generated clients attract conflicts from every story. Let one agent at a time change them, or batch those changes.
• Claim a story before work starts, so that a second agent, or a person, does not pick it up. Claude Code's agent teams do this for their own task list, with file locking so two teammates cannot claim the same task. In Stride, the MCP call an agent uses to take its next staged story claims it atomically, so two agents asking at the same moment never receive the same one.

Merge one at a time

Parallel branches still land in sequence. Merge one, bring the next up to date with main, re-run its checks, then merge it. A merge with no textual conflicts can still be wrong: two changes that are each correct can combine into one that is not. Re-run the tests after every rebase rather than trusting a clean merge.

When a conflict does appear, resolve it with both stories' acceptance criteria in front of you. Whoever resolves it, person or agent, should know what each side was for, not only what each side changed.

Keep work in progress small

Agents make it easy to start work, and a WIP limit keeps the team finishing it. Cap the number of open agent pull requests at what your reviewers can clear in a day, and let the review queue, not the number of agents, set the pace.

Checklist for running agents in parallel

• One agent's loop is reliable before a second one starts.
• Each agent has its own worktree, dependencies and git-ignored files.
• No agent uses a bare git stash.
• Each agent has its own port, database and credentials.
• Stories running at the same time touch different files, and shared registries change one story at a time.
• Each story is claimed before work starts.
• Branches merge one at a time, with checks re-run after each rebase.
• Open agent pull requests never exceed what reviewers can clear in a day.

Sources

Checked on October 20, 2026:

• Git: git worktree and git stash.
• Anthropic: run parallel sessions with worktrees, run agents in parallel, subagents, agent teams and the Claude Code changelog (2.1.304, October 19, 2026).
• Cursor: cloud agents.
• GitHub: Copilot on GitHub.com, for the cloud agent's limits.
• Visual Studio Code: agent harnesses, on worktrees as a code boundary rather than a security one.