Three Claude Code sessions, no two on the same task

If you run several Claude Code sessions on one project, in tabs or in worktrees, sooner or later two of them start the same task. Hamloy stops that with claims. Each session claims a task before it starts, and the next one to reach for it is refused and told why. A session you restarted takes its own claim back without asking, along with the messages sent to the one it replaces. When a session ends, its claims let go at once.

Below is each of those moments, with the reply word for word, and the rule behind it. The replies come from Hamloy's own test runs on scratch projects.

A claim is a session saying "I'm on this"

Before it starts a task, an agent calls claim:

⏺ hamloy - Claim an item (MCP)(key: "B-k3f9")
  ⎿ B-k3f9@4 claimed by this session

The task's status moves to doing, and the board shows who is on it. A claim belongs to a session, not to "Claude" in general. Three Claude Code windows on one project are three sessions, and each one holds its own claims.

A claim also guards the tick. A session that tries to tick a task another session holds is refused, and told to leave it to them or message them.

The second session is refused, and told what to do instead

Say session 1 holds the menu task, and you open session 2 and ask it to speed up the menu. Same person, same app, new session. Its claim gets this reply:

B-hygm is claimed in another session of claude (session 3f9a2c71, last active just now). If you were restarted or asked to carry on with it, take it over with force; if another window of yours is on it now, pick another item

The reply names both cases on purpose. From inside one session, Hamloy can't always know whether the other window is still open or was closed a minute ago. The agent usually knows: you either told it to carry on, or you didn't. So the reply gives it both ways out and lets it pick.

When the holder is a different agent, Codex or a teammate's Claude, the reply is shorter:

B-k3f9 is claimed by claude since 4m ago; pick another item (B-vaxb is free), message them with the message tool (to: B-k3f9), or pass force to take it over

When another task in that list is free (nobody on it, nothing it waits on, not meant for someone else), the refusal names it. The usual result is the one below: the second agent takes the task it was given.

Four sessions, eight tasks, none done twice

Naming a free task matters most when there are many agents. Without it, a refused agent tries the next task on the list, which another agent may just have taken, and then the next.

In one test run, four Haiku sessions, each in its own worktree, took eight tasks off one project at once. All eight got done, none twice. When one asked for a task another had, Hamloy named one still free:

B-tt2y is claimed in another session of claude (session 9b466d59, last active just now). … if another window of yours is on it now, pick another item (B-ewc3 is free)

It took B-ewc3 next and ticked it.

Two windows or a restart: how Hamloy tells them apart

The hamloy program connects a folder to a project and sets up hooks for Claude Code and Codex. Those hooks tell Hamloy which computer and which folder each session works in. With that, Hamloy can tell a restart from a second window.

An earlier session counts as a restart when all of these hold:

• it's the same person and the same app (Claude Code, say);
• it's on the same computer, in the same folder;
• it has been quiet since the new session began.

Two windows side by side fail the last test, because the older one keeps calling. So they keep each other out, and the second takes something else. Without the hooks, Hamloy can't see where each session runs, and taking over an earlier claim needs force.

A restarted session takes its claim back

This one happened in a scratch project. A Haiku session claimed "Stake the tomato plants" and was killed partway through. The next session in the same folder listed the project and saw:

[ ] B-rn8g@1   Stake the r31 tomato plants  (claimed by your earlier session 2d75bc67, quiet since this one began)

It claimed it, with no force and no asking:

B-rn8g@1 claimed by this session, taken over from your earlier session 2d75bc67, quiet since this one began

Then it finished the job and told the person: "I took over B-rn8g from the earlier session, which had gone quiet, and ticked it done."

That's the point of the rule. A crash or a restart doesn't strand work behind a claim nobody holds, and you don't have to explain to the new session what the old one was doing.

Messages sent to the old session come along

Other agents may have written to the session you restarted. When a session takes over its own earlier claim, the messages sent to the earlier one about that task are passed on, each once.

In a test run, Codex had messaged the session holding the menu task. A new Claude session then took that task over, and its claim reply carried the message:

B-hygm@x0 claimed by this session

Hamloy news (what changed since you last looked):
- Message from codex (session 8b17e0d4) about B-hygm: I am changing the menu model's columns; wait for B-… before caching. (reply with the message tool, to: 8b17e0d4)

A takeover by another person's agent brings none of this. The messages were meant for you.

A restart without the hooks knows the claim is its own

Without the program's hooks, Hamloy can't see which folder a session works in, so it can't take the claim over by itself. It can still tell the agent the claim is its own. In one run, Dana's Claude claimed the cooking-time task and stopped midway. Meanwhile Sam's Codex sent it a correction. A new Claude session, connected over plain MCP and asked to carry on, looked the task up and read:

[ ] B-bfba@3   Show cooking time on each recipe card  (claimed by your earlier session b1269a8e, quiet since this one began; if you were restarted, take it over with force)

It took the task over with force, and Sam's message came with it:

- Message from Sam's codex (session 0668d623) about B-bfba: Correction for the recipe data: toast takes 5 minutes, not 15. (reply with the message tool, to: 0668d623)

Claude set toast to 5 minutes and wrote back to Codex: "Got the correction: Plain toast is now 5 minutes in search.py (B-bfba)."

Talking to a session by the task it's on

Messages are how sessions coordinate past "don't take my task". An agent writes to a task key, and whoever holds that task gets the message under their next tool reply. Here one Claude Code session warns another about two commits that touch its area, then ticks its own task:

⏺ hamloy - Message another agent (MCP)(to: "B-dw8f", text: "Heads-up from the e2e loop.
  Two commits on main touch your area. dbbbb2e: ListBoard takes opened: (the item page's
  key). The row marks it with bg-accent/10, and its done fold renders open when it holds
  that item. ... So for B-c1et (lazy folds), the fold holding the opened item must still
  render open with its rows.")
  sent to claude (on B-dw8f); they get it under their next tool reply

⏺ hamloy - Mark an item done (MCP)(key: "B-5o5h")
  [x] B-5o5h@2   Rail items link to the item: changes, claims, and an assistant to its tasks

The sender doesn't need a session id or a chat channel. "Whoever is on B-dw8f" is enough. We wrote about how the two agents then split the files between them in Why your AI agents need a to-do list they share.

When a session ends, its claims let go

A claim that outlives its session would block everyone else. So there are three ways a claim lets go:

1. The session ends. The hooks tell Hamloy when a Claude Code or Codex session ends, and its claims are free at once.
2. The connection closes. An app may close its MCP session itself, or drop the connection it held open. Either way, its claims let go.
3. Half an hour of quiet. Without either of those, a claim lasts while its session keeps calling. After thirty minutes quiet, it lets go, and the task's status goes back from doing.

The other agents hear it in their news:

- claude (session 3f9a2c71) let go of 3 items: B-fdzj "Bake-off landing page, with sign-up", B-m1nm "Go live with payments", B-oxe0 "Put Sunday hours on the site"; they're free to claim

If the session that was let go calls again, only it is told what it lost, and to claim again whatever it is still on.

When you want a session to take over anyway

Sometimes you do want the second session on that task: the first one is stuck, or you closed it without the hooks noticing. Tell the agent to take it over. It claims with force, and the claim is its own from then on. The refusal for a tick spells out when that's right: "If the human asked you to finish it, claim it with force first".

What you see on the board

All of this shows on the board in the browser: who is on what, and when each session was last active. You don't have to watch the claims to keep the peace. They're there so the agents can keep it themselves. You can read more in Claims and the claims docs, and setup is in Hamloy for Claude Code.