---
title: Three Claude Code sessions, and who is on what
description: Who is on what across parallel Claude Code sessions, for you and for each session. How a claim says it, how a restart takes it back, when it lets go.
url: https://hamloy.com/blog/three-claude-code-sessions
---

[Blog](https://hamloy.com/blog)

# Three Claude Code sessions, and who is on what

Who is on what across parallel Claude Code sessions, for you and for each session. How a claim says it, how a restart takes it back, when it lets go.

9 October 2026 · Rahmakyan

If you run several Claude Code sessions on one project, in tabs or in worktrees, the first thing you lose is who is on what. You can't say it without reading every window, and the sessions can't say it at all, because none of them knows the others exist. In Hamloy a claim answers it. Each session claims a task before it starts, the board shows that claim the moment it is made, and the next session to reach for the task is told who has it and what is free. 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 told who has it, and 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.

_Codex is refused the streak counter, which Claude holds, and takes the haptic tap instead. Claude Code or Codex, the claim holds._

## Four sessions, eight tasks, each told what's free

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, each by one session. 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](https://hamloy.com/blog/why-agents-need-a-shared-list).

## 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. Right now has a row for each session, with its branch, the task it's on and when it was last active, and every task's row says who holds it. You don't have to watch the claims or carry them between windows: the sessions keep them, and you read the result.

_Right now: claude and codex at work in pebble, each on its branch with the task it holds and the tests it ran, then the tasks ready and an answer an assistant went ahead with._

You can read more in [Claims](https://hamloy.com/claims), [the overview](https://hamloy.com/overview) and [the claims docs](https://hamloy.com/docs/claims), and setup is in [Hamloy for Claude Code](https://hamloy.com/for/claude-code).