Your teammates' Claude Code sessions don't know about each other
By Soumen Sarkar · October 2026
Problem. "My teammates' Claude Code sessions don't know what each other are doing."
Each Claude Code session starts from the code and your CLAUDE.md, not from what your teammates' sessions are changing right now. Worktrees keep their files apart; to keep their work aligned, every session needs to see the work in progress, decisions and assumptions in the area before it edits it.
Why don't my teammates' sessions know what each other are doing?
Because nothing tells them. Each Claude Code session starts with a fresh context window and loads your CLAUDE.md files (Claude Code docs). That gives it the team's standing instructions. It doesn't give it what Dev's session started changing an hour ago, the plan behind that change, or the call Sara's session made last night about a field nobody had defined.
So two excellent sessions can do excellent work that doesn't fit together. Nothing is wrong with either agent. What's missing is between the people running them.
Why does this happen more now?
Because one person runs several sessions at once, and so does everyone else. A team of five can have a dozen sessions touching one product in an afternoon. Each one is fast and capable. The questions "who else is in this part of the code, and what are they turning it into?" now come up many times a day, and nobody can answer them by asking around.
Don't worktrees fix this?
They fix part of it, and you should use them. Claude Code starts a session in its own git worktree with claude --worktree <name>, a separate checkout on its own branch, so parallel edits don't collide (Claude Code docs).
Worktrees separate the files, not the thinking. A session in one worktree still can't see the plan in the next one. Claude Code's auto memory doesn't bridge the gap either: it is shared across worktrees of one repository, but it is machine-local and isn't shared across machines (Claude Code docs). Your teammates are on other machines. The longer answer is in do git worktrees stop parallel agents conflicting?
What do teams do about it?
Most teams do some mix of these:
- Post in a channel before starting on a shared area. It works while people remember, and the agents never read it.
- Grow CLAUDE.md. It holds rules well, but it's checked in and read at the start, so it can't say what's changing this afternoon.
- Ask the lead. The lead becomes the router, and sessions wait.
What actually keeps sessions aligned is shared memory that travels with the work, read at the moment a session enters an area. See how to avoid two agents changing the same thing in different directions.
What does Campfyrr do?
Campfyrr gives each session an area brief. The first time a session reads or edits a file in a part of the code, a hook adds what the team knows there: work in progress, decisions that apply, recent changes, what was tried and dropped, and open questions. An edit also tells teammates that the area is being changed.
Work in progress carries its plan. A session calls start_work with its goal, its plan and when it should be done. Another session that depends on it calls wait_on. It gets that plan to build against now, and hears what actually landed, compared with the plan, when the work finishes.
We run Campfyrr on itself. This repository's own instructions to every session say:
The work hook adds what the team knows about each part of the code the first
time you touch it. Follow the decisions it lists, and build on work in
progress there rather than around it.
That rule shipped with the change that built area briefs, waits and handoffs on 14 October 2026, so every session on this codebase gets briefs as it works.
What Campfyrr doesn't do: it doesn't run, schedule or isolate your sessions, and it doesn't merge code. Keep your worktrees and your CI. Campfyrr briefs the sessions and keeps their plans where every agent and person can see them.
Where do I start?
- Give each session its own worktree.
- Connect Campfyrr from /connect. The paste installs the hooks and the MCP server.
- Ask each session to call
start_work when it starts something others might touch. - Read the method in working in parallel on dependent changes.
Everything on this problem
- Comparison: Campfyrr vs Conductor: parallel agents that don't collide, and don't contradict: If you want to run many coding agents at once without them trampling each other's files, use Conductor. If those agents keep making calls that contradict each other, use Campfyrr. Most developers running agents in parallel on a team end up with both problems.
- Comparison: Campfyrr vs ContextStream: agents that find code fast, or a team that stays on one set of decisions: If your agents waste time finding the right code, and you're fine sending source to a hosted index, use ContextStream. If your problem is sessions building on calls nobody checked, and people outside engineering need to follow and answer, use Campfyrr: it never takes your code and costs a fraction per seat.
- Comparison: Campfyrr vs Entire: finding out why an agent did it, or telling the next one first: If your problem is finding out why an agent did something after it's done, use Entire: it keeps the full session behind every commit in git, so a reviewer can trace a line back to its prompt. If your problem is the next session undoing a call it never heard about, use Campfyrr: it gives that session the team's decisions and reasons before it edits. Many teams have both problems.
- Comparison: Campfyrr vs GitHub Copilot Memory: agents that know the code vs sessions that know the team's calls: If your problem is handing issues to agents and reviewing what comes back on GitHub, use Copilot with Agent HQ: its memory keeps the agents right about the code. If your problem is developers' own sessions breaking calls the team already made, use Campfyrr. Many teams on GitHub have both problems.
- Comparison: Campfyrr vs Kawa Code: agents editing the same lines, or following different decisions: If your agents keep editing the same lines as a teammate's, use Kawa Code: it flags overlapping uncommitted edits at the end of each turn. If your agents write different lines from different decisions, use Campfyrr: it briefs each session on what the team decided before it works. Many teams have both problems.
- Comparison: Campfyrr vs Lore: show one agent run, or keep every session in step: If you want to show a teammate exactly how one agent run went, use Lore. If your team's sessions keep building on decisions that changed this morning, use Campfyrr. Many teams have both problems.
- Comparison: Campfyrr vs Superconductor: share one agent run, or keep every run in step: If you want product, design and engineering in the same agent run, watching and steering it together, use Superconductor. If your runs on the same product keep making calls that contradict each other, use Campfyrr. Many teams have both problems.
- Comparison: Claude Code memory vs team memory: when CLAUDE.md and auto memory stop being enough: If you work alone, or each person owns their own repository, Claude Code's CLAUDE.md, auto memory and Projects are enough: keep using them. If a second person's sessions change the same product, a call made in your session has to reach theirs the same hour, and that's what shared team memory like Campfyrr adds. Most teams start with the first and grow into the second.
- For you: For engineering leads running a team on Claude Code: If you lead a team on Claude Code, you are probably the router: sessions don't know about each other, questions wait for you, and pull requests arrive without their reasons. Campfyrr briefs every session, routes assumptions to the person who knows, and puts reasons on every change. A team can set it up in about an hour.
- For you: For engineers running three or four sessions at once: If you run three or four Claude Code sessions at once, Campfyrr works in the background: each session gets a brief on what the team knows the first time it reads or edits a part of the code, and a handoff is written when a session stops, so your next session opens on it. There's nothing to fill in.
- Comparison: Memory MCP servers vs team memory: your agent's notebook, or your team's record: If your problem is that your own agent forgets your preferences and project facts, use a memory MCP server: the good ones do it well, and some are free. If it's that your session can't see what your teammates' sessions decided, and why, you need a team's record such as Campfyrr. Many engineers have both problems.
- Comparison: Sharing a session link vs sharing what sessions know: what does the next person need?: If you want to show someone exactly how a run went, share the session: a Claude Code link, Lore or an exported transcript. If each new session starts without what the last one decided, tried and dropped, share what sessions know. Many teams need both.
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).