Your Claude Code Sessions Now Talk to Each Other: ListAgents, SendMessage, and What the Docs Still Haven’t Caught Up With
In July, a Claude Code user opened a feature request with attached numbers. Over 30 days, they had instrumented their own workflow: 166 sessions, 13,782 edits, and 44% of writes landing in a shared primary checkout instead of the worktree where they belonged. Their conclusion was that collisions weren’t a hooks problem. Independently launched sessions had no way of knowing the others existed. The last item on their wishlist was a session registry: some way for separately launched sessions to discover each other’s state.
Claude Code 2.1.224, released August 7, 2026, delivers that primitive:
Added cross-session
SendMessage: Claude Code sessions can now message each other, on any of your machines, withListAgentsto discover them (macOS and Linux)
This is the second half of the same release that turned your own hardware into a place where cloud sessions can run — we covered the self-hosted-runner side separately, and both features point in the same direction: Your Claude Code Sessions Now Run on Your Machine: Guide to the self-hosted-runner.
What Actually Changed
Until now, messaging between Claude Code agents lived within a single session. Subagents report results back to the agent that spawned them and never talk to each other. Agent teams go further — teammates share a task list and message each other by name — but the team is scoped to a single session, with a mailbox at ~/.claude/teams/{team-name}/inboxes/{agent-name}.json and a lead that exists only for that session’s lifetime.
ListAgents breaks that boundary. It lists the sessions you can address: the subagents you spawned, other local Claude Code sessions on the same machine, and your sessions running in the cloud. The name each row prints is the address. SendMessage takes that name and delivers a message within that session’s context.
The mental model worth keeping: ListAgents is a directory, SendMessage is the delivery, and the name is the only routing key. When two rows print the same name, you disambiguate using the row reference.
Two restrictions that come straight from the changelog line, both easy to overlook:
- macOS and Linux. Cross-session capability isn’t listed for Windows.
- Discovery is scoped to your sessions, not a shared workspace. It’s a coordination tool for one person’s fleet, not a team messaging bus.
And a detail that says quite a bit about how new all this is: the same release also brings a fix for SendMessage when it reported “Message sent” but the write to the teammate’s inbox actually failed. Now failed deliveries are reported as errors. If you built something on that tool before this version, the confirmation you were reading wasn’t reliable.
The Part the Documentation Still Hasn’t Caught Up With
This is what you’ll find when you go looking for the knobs.
The changelog announces two settings together:
Added
crossSessionInboundanddialogExpirysettings: cross-session messages sent to a session running with bypassed permissions are held for your approval, and messages to other sessions auto-deliver
dialogExpiry is documented. It’s in the settings reference, requires v2.1.224 or higher, its default is "5m", it accepts "60s", "5m", "10m" or "never", and reads only from user, managed, and --settings sources. But the published description talks about dialogs Claude Code forwards to a remote client, like Remote Control or an SDK host — not cross-session messages specifically.
crossSessionInbound isn’t in the settings reference at all. Not on the rendered page, not in the raw markdown. Right now the changelog is the only place it’s described.
The agent teams guide, meanwhile, still carries a note stamping it “as of v2.1.178”, and still lists among its limitations: “One team per session: a session has exactly one team, scoped to that session. You can’t create additional named teams or share a team across sessions.” That sentence describes the release before this one.
None of this means the feature doesn’t work. It means the behavior you get is what’s in the changelog — messages to a session running with bypassed permissions are held waiting for your approval, and everything else delivers automatically — and the surface for tuning that policy isn’t documented yet. If you’re planning a setup where one coordinator session sweeps twelve others, budget approval prompts and check the settings reference again in a week.
That gap has a matching signal in the tracker. An issue opened July 18 asks for exactly the relaxation you’d want: an opt-in trust mechanism so local sessions from the same user don’t need confirmation per message, and whoever opened it reports about ten approval clicks per coordinator sweep. It’s worth reading with a caveat, though: that request is written against the author’s own MCP-based workaround, not the native tool, so take it as evidence of demand rather than a description of how SendMessage behaves today.
The Ceiling That Fell
Further down in the same changelog:
Removed the 200-subagent-per-session spawn cap; long-running sessions no longer refuse new agents (concurrency and depth limits still apply)
Read the parenthesis carefully, because it’s doing real work. What disappeared is the lifetime limit: a session that had already spawned 200 subagents refused to spawn the 201st, and that’s a wall you only hit in long sessions — a multi-hour migration, an audit sweeping a large codebase, a workflow iterating until it stops finding new results. How many agents run at the same time didn’t change, and neither did how deep they can nest.
So this isn’t “you can now run more agents in parallel”. It’s “a long session no longer dies of old age”. If you ever had a workflow that refused to spawn new agents mid-sweep and couldn’t figure out why, this was probably it.
Together with cross-session messaging, the shape of the release becomes pretty clear: fewer artificial limits between agents, in both directions — across time within a session, and across sessions and machines.
What You Can Build With This Today
The honest version is that this is a primitive, not a product. The interesting patterns are the ones you build yourself:
- A coordinator session. One session holds the plan, uses
ListAgentsto see what’s running, and messages each worker when their dependency clears. This is what the shared checkout problem really needed: for the coordinator to know which session owns which path. - Handoff instead of restart. A session finishing one piece of work messages the session that needs it, instead of you copying and pasting a summary between two terminals.
- Wake up a stalled worker. A message from another session wakes a teammate in-process waiting to retry a failed API request, so it retries immediately instead of waiting out the full delay.For work that fits into a single session, none of this is the right tool. Subagents are still cheaper — results get summarized back into a single context. Agent teams are still the better choice when workers need to question each other’s findings, something we covered when Agent View and Dynamic Workflows arrived: Agent View + Dynamic Workflows. Cross-session messaging is for the case that those two don’t cover: sessions you started separately, possibly on different machines, and that now need to know about each other.
What about you? Do you run multiple Claude Code sessions at once against the same repo — and would a coordinator session that could see them all change how you distribute the work, or would it just be another thing to supervise?