Two sessions, one checkout
By Soumen Sarkar · October 2026
Story. Two good Claude Code sessions in separate worktrees can rebuild the same part of the code in two directions, because neither can see the other's plan. Give every session a brief of the work in progress in an area before it edits there, and let it build on the plan that's coming.
What happens when two sessions change the same part of the code?
This story is a scene, built from how teams work with agents today. What comes after it is real.
It's 9:15 on a Tuesday, and I'm sitting on a spare stool between Dev's desk and Sara's. They work on the same small shop. Neither of them has said a word to the other yet this morning. They don't need to: they're working on different tickets.
Dev's ticket says the checkout total is worked out in three places and they don't always agree. He opens a Claude Code session in its own worktree and asks it to put every total in one place: one order summary that the cart, the payment page and the receipt all read. I watch the session read the checkout folder, trace each sum, and write a tidy plan. It's careful. It finds a rounding difference nobody had noticed.
Sara's ticket says customers want to pay part of an order with a gift card. She opens her own session, in her own worktree, and asks it to add gift cards at checkout. Her session reads the same checkout folder. It finds the payment page, where the total is worked out today, and adds the gift card there, after tax, with a clear message when the card doesn't cover everything. It writes tests. They pass.
At 11:40, Dev's session finishes. The payment page no longer works out a total at all; it reads the new order summary. His tests pass. He opens a pull request and goes for lunch.
At 2:10, Sara's session finishes too. Her change merges cleanly with the main branch, because Dev's hasn't landed yet. She opens her pull request.
At 3:30, Dev's change is merged. At 3:45, Sara rebases. The files merge without a single conflict marker, because the two sessions never touched the same lines. Her gift card code now subtracts from a total the payment page no longer owns. The order summary doesn't know gift cards exist. The receipt shows the full price.
Sara walks over to Dev's desk. It's the first time they've spoken today. "Did you move the totals?" He did. Neither of them knew the other was in checkout. They spend the rest of the afternoon deciding whose shape wins, and Sara's session spends the evening doing the gift card a second time, against the order summary.
Both sessions did beautiful work. Each one built exactly what it was asked for, on the code it could see. What neither could see was the plan in the other worktree, six feet away.
I come back two weeks later. It's a Tuesday again, and the team has changed one thing. Before a session edits a part of the code, it gets a short brief of what the team knows there. And when a session starts something others might touch, it says so, with its plan.
At 9:20, Dev starts a session on the next checkout ticket: moving delivery costs into the order summary too. Before it writes a line, it records its work in progress: the goal, a three-step plan, and that it expects to be done on Thursday.
At 10:05, Sara starts a session to add a "save for later" button to the cart. The moment her session opens the first file in the checkout folder, a brief arrives in its context. I lean over and read it with her. Work in progress here: Dev, moving delivery costs into the order summary, plan attached, due Thursday. A decision that applies: every total is read from the order summary, recorded the day Dev's first change merged. Recent changes: the gift card, done the second time.
Sara's session reads the plan and adjusts its own. It doesn't add a total to the cart. It reads the summary, the way the plan says delivery costs will be read on Thursday. Then it waits on Dev's work, so it will hear when that work lands.
On Thursday at 4:00, Dev's change merges. Sara's session, at its next turn, hears what landed against what was planned. One difference: the delivery cost has a new name in the summary. Her session changes two lines, runs its tests and opens its pull request.
At 4:30, Dev looks across at Sara. "Saw you were in the cart." She nods. That's the whole conversation, and it's enough.
Here's what I want you to notice
The agents were excellent both Tuesdays. On the first, each one built the right thing for the code it could see. What failed was between the people: two plans for one checkout, in two worktrees, and no way for either session to see the other's.
Look at the merge. It was clean. Git did its job perfectly, because the lines didn't collide. The directions did. Separate worktrees keep files apart, and that's exactly why they can't warn you that the thinking has split.
And look at what changed on the second Tuesday. Nobody held a meeting. Nobody posted in a channel. Dev said what he was building once, where the work lives, and Sara's session read it at the one moment it mattered: before it edited checkout. Stop asking your sessions to guess what's coming. Tell them, and let them build on it.
What's the proof?
- Every session starts without the others. In Anthropic's words, "Each Claude Code session begins with a fresh context window." It loads your CLAUDE.md files and auto memory, and auto memory "is machine-local" (Claude Code docs). Your teammate's plan is on another machine.
- Worktrees separate files, by design. Claude Code can start each session in its own git worktree, a separate checkout on its own branch, so parallel sessions don't edit each other's files (Claude Code docs). That's the right tool, and it's why the scene's merge was clean.
- We built briefs into our own work. The change that added area briefs, work in progress and waits to Campfyrr landed on 14 October 2026. Its commit message says: "The first time a session reads or edits a file in an area, the work hook adds what the team knows there: work in progress, decisions that apply, recent changes, what was tried and dropped, open questions."
- Every session on our codebase follows it. This repository's instructions say: "Follow the decisions it lists, and build on work in progress there rather than around it."
To be honest about our own record: so far it's mostly one person's sessions working on Campfyrr, so we can't yet point to a collision between two people that a brief stopped. The scene shows the moment briefs are built for.
What Campfyrr doesn't do: it doesn't run or isolate your sessions, merge your code or replace your CI. Keep your worktrees. Campfyrr briefs each session on the area and keeps the plans where every agent and person can see them.
What do I do on Monday?
- Give each session its own worktree.
- Connect Campfyrr from /connect. The paste installs the work hook and the MCP server.
- Ask each session to call
start_work with its goal and plan when others might touch the area. - Ask a session that depends on unfinished work to call
wait_on. - Read the brief your session gets the first time it enters an area.
- Record a decision when a shape wins, so the next brief carries it.
For the problem in full, read your teammates' sessions don't know about each other. The area brief and work in progress entries explain the two pieces, and git worktrees vs shared memory covers why you want both. The method for dependent changes is in working in parallel on dependent changes, and the idea behind it is build on what's coming.
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).