Do git worktrees stop parallel AI coding agents from conflicting?
By Soumen Sarkar · October 2026
Short answer: Git worktrees stop parallel agents from editing the same files at the same time, but not from building in different directions. Each agent also needs to know what the others are changing, what was decided and what they assumed.
What do worktrees solve?
A worktree is a separate checkout of the same repository on its own branch. Give each agent its own, and two sessions can't overwrite each other's files halfway through a change. Claude Code can create one for a session, and most tools for running agents in parallel do the same. It's the right first step, and every team running several agents should take it.
What don't they solve?
Worktrees separate the files, not the thinking. Each agent still starts from the code as it is, with no idea what the agent in the next worktree is about to change. So two excellent agents can each do excellent work that doesn't fit together:
- One splits the checkout into three steps while another adds a field to a page that's about to disappear.
- One stores money in decimal pounds while the team decided months ago on whole pence.
- Two agents meet the same unknown on different nights and answer it two different ways.
None of these show up as a file conflict. They show up at merge time, or later, as rework.
What keeps parallel agents aligned?
Three things travel with the work, so every agent reads them before it starts:
- Work in progress, with its plan. When an agent starts a change in a shared area, it says what the change will be and when it'll land, so the next agent builds on it rather than around it. See work in progress.
- The area's decisions and assumptions. The first time an agent touches a part of the code, it's told what was decided there and what's being assumed. See area brief.
- What landed. When the change finishes, everything built on it hears what it turned out to be compared with its plan, and adjusts. See landed.
For example, Sara's agent opens Checkout · app/checkout in its own worktree. Its brief says: "Dev's agent is splitting checkout into three steps, landing this afternoon; payment moves to step 3." It builds the discount field into step 3. When Dev's change lands, Sara's agent adjusts one import, and both merge the same day.
Campfyrr adds that layer to the worktrees you already use. It doesn't run or isolate agents; it briefs them, and keeps their plans, decisions and assumptions where every agent and person can see them. For the full method, read working in parallel on dependent changes.
Words used here
- Work in progress: Work in progress is work under way, shown with its plan, so others build on it rather than around it.
- Area brief: An area brief is what a person or agent is told the first time they touch a part of the code: what's changing there now, what was decided, and what was tried.
- Landed: Landed means work that finished, shown with what it turned out to be compared with its plan.
The principle behind this: Build on what's coming: Unfinished work is a promise, and a promise can be built on.
Move as one at agent speed. Nobody waits. Add Campfyrr to Claude: it briefs every agent before it touches the code, keeps assumptions and handoffs where the team can see them, and never takes your code (what it keeps).