Git worktrees vs shared memory for parallel agents
By Soumen Sarkar · October 2026
Comparison. If your parallel agents keep overwriting each other's files, use git worktrees. If they never touch the same file but still build in different directions, you need shared memory. Most engineers running several sessions on a team need both.
What are you trying to fix?
Worktrees keep files apart. Shared memory keeps work aligned. If your parallel agents keep overwriting each other's half-finished edits, use git worktrees. If they never touch the same file but still build in different directions, you need shared memory. These aren't rivals: they fix different problems, and most engineers running several sessions on a team have both.
- "Two of my sessions edited the same file and one undid the other." Worktrees. A worktree is a second checkout of the same repository on its own branch, sharing the history but not the working files,
HEAD or index (git-worktree). Claude Code makes one per session with claude --worktree <name>, under .claude/worktrees/ on its own branch (Claude Code docs). - "My own sessions need to tell each other what landed." Also covered without anything new. Claude Code's cross-session messaging lets one of your sessions warn another when a change breaks what it's building on (Claude Code docs).
- "My teammate's sessions decided something on Tuesday, and mine built against it on Wednesday." Shared memory. Worktrees separate the files, not the thinking. Messaging reaches your own sessions. Neither tells your session what someone else's team decided about this part of the code.
The same day, with each
This is a scene, not a customer: three developers and a PM. Priya runs three Claude Code sessions, each in its own worktree: one builds an invoice export, one fixes a settings bug, one writes tests. On another laptop, Tom is renaming the customer's "plan" to "tier" across billing, because he and the PM decided on Tuesday that "plan" means something else now.
With worktrees alone, Priya's day is calm. No session overwrites another; her bug-fix session messages the export session when it changes a shared helper, and the export session adjusts. But the export reads plan everywhere, because that's what the code says on her branch. Tom's rename lives on his branch, on his machine. On Thursday the two merge, and nothing conflicts in git. The export just exports the wrong field. Priya loses an afternoon to rework, and the PM is asked again about a naming call she made on Tuesday.
With worktrees and shared memory, the files are kept apart exactly the same way. The difference comes the first time Priya's export session opens the billing code. A hook adds the area brief: Tom's rename is in progress, landing Thursday, with the decision and who made it. The export builds on tier from the start. Where the brief doesn't settle something, the agent records an assumption instead of stopping, and it goes to Tom, who answers from a link. When his change lands, Priya's sessions hear what it turned out to be. Thursday's merge is a merge.
Both teams had zero file collisions. Only one had zero rework.
When worktrees alone are the better choice
- You work alone. All the sessions are yours, on one machine. Worktrees isolate the files and cross-session messaging carries what one session learns to another. Shared team memory adds little until a second person's sessions are in the codebase.
- The tasks are independent and short. A bug fix, a dependency bump and a docs change rarely share a decision. Worktrees, a review and a merge are enough.
- Teammates work in separate parts of the code. If nobody else touches billing this month, nothing about billing needs to reach you.
Worktrees have their own upkeep, and it's worth knowing before you start. Each one is a fresh checkout, so you install dependencies again and copy files like .env across, which Claude Code automates with a .worktreeinclude file. Worktrees with work in them stay on disk until you keep or remove them (Claude Code docs).
What it costs
Worktrees cost nothing: they're part of git, and Claude Code creates and cleans them up for you. Campfyrr is $9 per developer a month, minimum 3, and business teammates who read and answer are free. For 5 developers and 3 business teammates, five times nine is $45 a month, or $35 at the yearly $7, and nothing during early access (/pricing).
The daily cost matters more. Worktrees ask you to set up and clean up a checkout per session. Shared memory asks each developer to install the plugin once, and someone to answer an assumption when it's sent to them. Nobody runs a command to brief a session. Campfyrr doesn't create worktrees, run your agents, review code or replace CI. It never takes your code or diffs (/trust).
Verdict
Use worktrees alone if you're the only person running sessions in this codebase, or your parallel tasks never share a decision.
Add shared memory if teammates run sessions on the same code, and you've merged cleanly only to find the work didn't fit (sessions don't know about each other).
Use both if you run several sessions on a team. Keep a worktree per session, and let the brief tell each one what the others are changing. If you already use an orchestrator that creates worktrees for you, read Campfyrr vs Conductor. For the method, read working in parallel on dependent changes and do worktrees stop parallel agents conflicting?. See what a session gets, and the research behind this page.
The problem this answers: Sessions don't know about each other: "My teammates' Claude Code sessions don't know what each other are doing."
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).