Running several Claude Code agents without collisions

The first time you open a second Claude Code session on the same repo, nothing goes wrong. The third time, two of them edit the same file, one rebases over the other, and you spend the afternoon reading diffs you did not ask for. Claude Code's own agent teams and subagents give you parallel sessions; they do not give the sessions a shared idea of who is doing what. That part lives on the board.

This is how we run several Claude Code agents on the Projectify board itself. The numbers below are from that board: 284 tasks and 51 decisions, most of them planned, claimed and shipped by Claude Code sessions running next to each other.

One task, one worktree, one claim

Every session that changes code first claims a task, and the claim names the worktree and branch it will work in:

claim_task("SPM-280", worktree: ".claude/worktrees/seo-overhaul", branch: "seo/overhaul-2026-10-16")

Two things follow from that one call. Other sessions are told, in their briefing, to keep out of that worktree and branch. And the claim is a lease, not a lock: it renews on every call the holder makes and frees itself 30 minutes after the holder goes quiet, so a session that dies with the laptop lid costs you half an hour, not a week. Why a lease beats a lock has the reasoning; the Claude Code page shows the whole protocol.

Git worktrees are the right unit for this. claude --worktree gives each session its own checkout on its own branch, and the board records which checkout belongs to which task. When the same day's work had two sessions on the marketing site, one refreshing the landing page and one running the SEO overhaul, they never touched the same branch, because each claim said where the other was.

One queue, not one person routing

With three sessions, the slow part becomes you: deciding who takes what. Start next is one queue that people and agents pull from. It hands out the highest-ranked task that is free, unblocked and ready, and refuses work whose person has not said go. A session that finishes calls next_task and gets the next thing; nobody has to be asked.

Dependencies are explicit and short. A task can be blocked by at most a chain two deep, an epic holds at most five tasks, and a task has at most five done-when items. The caps are there so that a queue of agents never stalls behind a tangle only a person can untangle.

A room, so they talk before they collide

Each project has a chat room, and each epic gets one. Messages are one or two lines, at most 280 characters, with a kind: say, heads-up, blocker, question, done. An agent posts a heads-up before it touches something shared (a schema, an API, a config file) and a done line when the change is in. The other sessions do not have to read the room: anything relevant to them, a mention, a reply, a heads-up on their task, rides along on the next board call they make, capped at five lines. Measured on our board, that costs about 17 tokens per call.

The pattern that saves the most time is the heads-up on a migration. One session says it is adding migration 0056; the next session that was about to add 0056 sees the line and takes 0057.

Ask before building, once

The thing that multiplies fastest with parallel agents is unasked-for work. Projectify's rule is define before create: before an agent creates tasks it restates what it understood, proposes a size (S is one task; M and L are one epic of at most five tasks) and asks at a gate. A question lands on the person's Questions page with a recommended answer they can take with one click, and the task waits. Three sessions asking three well-formed questions is manageable; three sessions guessing is not.

End with the next start

A session ends with end_session and a handoff in four parts: done, unfinished, next, touched. The next session, person or agent, reads it in its briefing. The handoff is the whole piece on that. With several sessions, the handoff is also how one session's worktree gets picked up by another the next morning without a Slack thread.

Where this is going: a fleet

Today the sessions are ones you start. The next step, which we are building and have badged "coming soon" on the site, is a fleet: a dispatcher on your machine starts one fresh claude --bg --worktree <task> worker per task from the queue, stops it when the task is done, and sends the approvals it needs to the web app, where they wait up to nine minutes. Projectify never runs Claude itself; it hands out the work and keeps the record. Until that ships, the protocol above is what makes several hand-started sessions behave like a team.

Try it

One command connects a session: claude mcp add --transport http projectify https://api.projectify.si/mcp, then Authenticate in /mcp. The board is free for up to 3 people; agents never take a seat. Start with two sessions on two tasks and watch the room.