Run several agents. Without the conflicts.

One coding agent is a helper. Three at once can be a team, or a mess. Two agents in the same folder will sooner or later edit the same file, run the same dev server on the same port, or rewrite a lockfile the other one just changed. None of that is the model’s fault. It’s a setup problem, and it has a setup fix.

This guide is the setup we use every day: one git worktree per agent, one lane per agent, a three-line brief, and small merges. It works the same way for Claude Code and for Codex.

1. Give every agent its own worktree

A git worktree is a second (or third, or fifth) working folder for the same repository. Each one has its own files and its own branch, and they all share one history and one remote. That’s exactly what parallel agents need: separate desks, same filing cabinet.

Create one per agent by hand:

git worktree add ../app-auth -b agent/auth
git worktree add ../app-tests -b agent/tests
git worktree list

Now ../app-auth and ../app-tests are full checkouts on their own branches. Start an agent in each folder and they can’t overwrite each other’s files, because they aren’t the same files.

Both CLIs can also do it for you:

• Claude Code: claude --worktree feature-auth (or -w) creates a worktree under .claude/worktrees/feature-auth/ on a new branch named worktree-feature-auth and starts the session there. Run it again with another name in a second terminal for a second isolated session. Add .claude/worktrees/ to your .gitignore.
• Codex: codex --worktree runs the session in a new managed git worktree.

A worktree is a fresh checkout, so gitignored files such as .env aren’t there, and neither is node_modules. Install dependencies in each worktree. Claude Code can copy gitignored files for you: list them in a .worktreeinclude file at the project root, using .gitignore syntax.

When a branch is merged, clean up:

git worktree remove ../app-auth
git branch -d agent/auth

2. Know what worktrees don’t isolate

Worktrees separate files. They don’t separate everything else your project touches:

• Ports. Two dev servers that both want port 3000 will still collide. Give each worktree its own port, for example through an environment variable in its .env.
• Databases and caches. Two agents running migrations against the same local database will step on each other. Use a database per worktree, or keep migrations to one agent.
• Merge conflicts. A worktree stops two agents writing the same file at the same moment. It can’t make two incompatible changes merge cleanly later. That part is about lanes.

3. Give each agent a lane

Most agent conflicts happen in shared files: lockfiles, migrations, routing tables, global config. The fix is old-fashioned ownership. Before you start, give each agent a lane, which is a folder or a feature that is clearly its own:

• Agent 1 owns src/auth/.
• Agent 2 owns tests/.
• Agent 3 owns docs/.

Then name one owner for each shared file. If the auth agent needs a new dependency, it says so in its summary instead of editing the lockfile itself, and the lockfile’s owner adds it. Lanes sound strict, but they’re what lets you merge three branches in ten minutes instead of an hour.

4. Brief every agent in three lines

Parallel agents can’t ask each other what you meant. Each one needs a brief that stands on its own:

Goal: cut checkout p95 under 400 ms.
Done when: npm run perf:checkout passes.
Don't touch: billing/, the lockfile.

A one-sentence goal, a command that proves the work is done, and a short list of things to leave alone. The “done when” line matters most: an agent that can run a check iterates until it passes, instead of stopping when the work looks done.

5. Merge small, one branch at a time

Long-lived agent branches drift. Merge each one as soon as its check passes, starting with the most foundational change. Then update the other branches onto the new base, rerun their checks and fix what moved. If two branches keep conflicting, their lanes overlap; redraw them before the next round.

Read every diff before it lands. Agents can do the work. Keep the irreversible steps for yourself: commit, push, deploy, delete.

6. Watch the agents, not the terminals

Past three or four agents, the hard part stops being conflicts and starts being attention. Which one finished? Which one is waiting on a question? Which one has been idle for an hour and is still holding memory? Name every session after its task (claude -n auth-refactor, or /rename inside a session) so you can find it again, and check in on a schedule instead of tab-cycling all day.

If your Mac starts to struggle, stagger heavy jobs: eight agents can mean eight test suites at once. Cap the parallel workers in your test runner and close dev servers you aren’t using.

A checklist you can copy

1. One worktree and one branch per agent.
2. Dependencies and env files set up in each worktree.
3. A lane per agent, and one owner for each shared file.
4. A three-line brief: goal, done when, don’t touch.
5. Each agent asks before commit, push, deploy or delete.
6. Merge small, one branch at a time, and read every diff.

Where XAgents fits

We build XAgents, a native Mac app for exactly this way of working. Each project gets a space, each agent gets its own tab, and helper agents open as green tabs beside the agent that started them. Only the agent that is waiting on you turns amber (Needs you), and idle agents sleep until you press ⌘R. The worktrees and lanes are still yours to set up; XAgents keeps every agent in view while they work. See the product tour.

XAgents is a home for your agents. Join the waitlist and we’ll email you when your invite is ready.