Claude Code sessions can now find and message each other. That is discovery, inside one account.

Published 2026-08-12 · Last reviewed 2026-08-12

On 7 August 2026, Claude Code shipped something that looks small in a changelog and reads differently on a whiteboard. Two independent sessions, started separately and steered by you, can now find each other and pass text between them while work is in progress.¹ One session lists which sessions it can reach. It picks one by name. It sends a sentence.

That is a discovery step followed by an addressing step followed by a delivery step. Those three moves are the skeleton of every agent network anyone has proposed in the last eighteen months, and here they arrive not as a specification but as a default in a product a lot of people already have open.²

The part worth studying is not the messaging. It is the namespace. Sessions are addressable because they all live inside one account, on machines that account controls, under permission settings that account set. That constraint is what makes the feature safe, and it is also exactly the constraint that a network spanning more than one account has to solve differently. Here is what shipped, and where the line sits.

What actually shipped

Cross-session messaging requires Claude Code v2.1.224 or later, runs on macOS and Linux including Linux inside WSL 2, and is not offered on native Windows. The feature is also not available through Amazon Bedrock, Claude Platform on AWS, Google Cloud’s Agent Platform, or Microsoft Foundry. Where the requirements are met it is on with nothing to enable.¹

Two tools do the work. ListAgents discovers which agents the session can reach. SendMessage delivers text to one of them by name. You never call either one yourself: Claude decides a message is needed, or you ask for one in plain language, and Claude picks the target and writes the text. A session answers to the name you set with /rename or the --name flag, and when you set nothing, Claude Code derives a name from the working directory folder, such as myapp-3f. Running /list-agents, aliased /peers, shows which sessions Claude can currently reach. Two sessions can collide on a name, which the listing disambiguates with the working directory and a short identifier.¹

The listing spans four kinds of target: subagents inside the current session, your other local sessions on the same machine, your Claude Code on the web sessions, and your sessions on other machines while both ends are connected to Remote Control. Version 2.1.225 added the ability to start a conversation with a session on another machine. Before that, Claude could only reply to a message that arrived from one.¹

Transport follows the target. A message to a session on the same machine travels over a per-session Unix socket and never touches Anthropic servers. A message to another of your machines goes through Anthropic servers and arrives over that machine’s Remote Control connection. A message to a cloud session goes through Anthropic servers straight to it. Same-machine reachability is filesystem-scoped, which has a consequence worth knowing before you debug it: a session inside a container and a session on the host cannot see each other, because they do not share the files where sessions register themselves.¹

What crosses is deliberately thin. A message is plain text that one Claude wrote for another, carrying the sender’s name and usually a reply address. It is never the sender’s conversation history and never its files. To move a whole conversation, you resume the session instead. Loops are throttled: repeated messages are rate limited per sender, identical repeats inside a short window are dropped, and at most fifty accepted messages can be queued for a session to read. A separate cap holds at most a hundred messages awaiting your approval before the oldest are dropped.¹

The namespace is the interesting part, not the messaging

Read the design from the addressing end and it gets clearer. Every question that makes agent-to-agent communication hard has already been answered before the first message is written, because both sides belong to the same owner.

Who is allowed to appear in the listing? Your sessions, and only yours. What authenticates the sender? Filesystem registration on one machine, or an account-bound Remote Control connection across machines. Who resolves a name to an endpoint? The client, from files it wrote itself. What happens when two names collide? A working directory and a short identifier separate them, which works because the total population is small and the owner already knows what each session is doing. None of those answers survive contact with a second account.

This is not agent-to-agent interoperability, and it is worth saying plainly because the shape invites the comparison. A2A defines machine discovery through an Agent Card published at /.well-known/agent-card.json, so an agent that has never met yours can fetch a description and negotiate a task. Naming and lookup layers such as GoDaddy ANS, Infoblox DNS-AID and the various enterprise registries exist to resolve an unfamiliar agent to an endpoint you can verify. Those are open-world problems: strangers, verification, revocation. Claude Code solved a closed-world problem, elegantly, and only claims the closed one. What crosses between sessions is plain text, and structured protocol messages stay inside an agent team rather than travelling out of it.¹

Which makes this a useful piece of evidence rather than a competing standard. When a major vendor turns discovery and direct messaging into defaults its users get without asking, the primitives stop being a research topic. People will start expecting an agent to be able to find another agent and say something to it, in the way they expect a phone to find another phone. The expectation is what generalizes. The namespace is not.

A message is not consent, and Anthropic says so in the docs

The most instructive part of the documentation is the list of things an arriving message cannot do. It never counts as your consent, so it cannot answer a pending permission prompt on your behalf. It cannot cause the receiving session to change permission settings, CLAUDE.md, or other configuration. A slash command inside the text arrives as text and is never executed. If acting on the message needs a permission the receiving session lacks, the usual prompt fires and you answer it. The sending side is instructed not to ask another session for work its own permissions would block, and to hand that back to you instead.¹

Then there is a gate on top of all that. crossSessionInbound sets what a session does with arriving messages: accept delivers, hold sets aside until you approve, refuse drops silently. Where no value is configured, Claude Code decides per message by comparing the two sessions’ permission classes, and a session that bypasses permission prompts holds inbound messages for approval unless the sender also bypasses. A held dialog expires after five minutes by default and the message is dropped. isolatePeerMachines requires your explicit approval before any message leaves the machine at all, and a true from any settings scope wins.¹

Sit with what that means. Inside a single account, on hardware one person controls, between two instances of the same model, the design still refuses to let arrival imply permission. The receiving side keeps its own boundary and the human keeps the approval.

That instinct is right, and it is the part that does not get easier when the network widens. Here both sides share an owner, so the gate can be a settings key. Across two people, the same question stops being a configuration value and becomes a negotiation: whose consent, revealed to whom, revocable how, and proven to the other side by what. A permission model built for one account is not a consent model for two.

What a portable version of this would have to add

Take the same three moves, discovery, addressing, delivery, and move them across an ownership boundary. Four gaps open at once.

A name that survives leaving the client. myapp-3f is a process label. It is meaningful because you know which terminal it belongs to, and it is meaningless to anyone else. An address that works between strangers has to point at a stable party, a person or a company, and keep pointing there when the session, the machine, and the model provider all change underneath it.

Resolution without a shared filesystem or a shared account. Local discovery reads files both sessions can see. Cross-machine discovery rides an account-bound connection. Neither generalizes. Between strangers, resolution is a public lookup problem, which is precisely what the registry and naming layers exist to do, and the reason they carry verification and revocation machinery that a same-owner listing has no need for.

Consent that is mutual and revocable, not a settings key. crossSessionInbound is the right idea with an owner-scoped implementation: you configure both ends, so one value can speak for both. When two different people are involved, the equivalent has to be negotiated in the open, granted by each side separately, visible to both, and withdrawable later without breaking the address.

A reason to believe the other side. Same-account messaging needs no reputation, because provenance is settled by ownership. Across accounts it is the first question asked and the hardest to answer, which is why credibility signals, on-chain reputation work such as ERC-8004, and verifiable credentials all keep circling it from different directions.

None of that is a criticism of what shipped. Anthropic built for the case it has, and drew the boundary honestly in its own documentation. It is a map of what the next layer owes anyone who wants the same convenience between two companies rather than two terminals.

How this connects to Tobira

Tobira works on the human-facing half of exactly that boundary. A Tobira @handle is an address that belongs to a person or a company rather than to a process, stays put when the session and the model provider change, and is discoverable by other people’s agents rather than only your own. On top of it sits mutual-reveal consent, so identity is exchanged when both sides agree and not because a message arrived, and the Site Agent wedge extends the same idea to a company website: a representative other agents can find, ask questions, and route to a real person. The network it addresses is small and public rather than account-scoped, at 648 agents including 102 business agents per the Tobira founder update, June 2026. For how a human-readable handle sits alongside the machine-side naming layers rather than replacing them, see Agent Name Service vs @handle.

FAQ

What did Claude Code add in v2.1.224?

Cross-session messaging. One Claude Code session can list the sessions it can reach with ListAgents and send another one plain text with SendMessage, addressing it by name. It requires v2.1.224 or later, runs on macOS and Linux including WSL 2, is not offered on native Windows, and where the requirements are met it is on with nothing to enable. Version 2.1.225 added starting a conversation with a session on another of your machines, rather than only replying to one.¹

Do messages between Claude Code sessions go through Anthropic servers?

It depends on where the other session runs. Same-machine messages travel over a per-session socket and never reach Anthropic servers. Messages to another of your machines go through Anthropic servers and arrive over that machine’s Remote Control connection, and messages to a Claude Code on the web session go through Anthropic servers to the cloud session. Setting isolatePeerMachines to true requires your approval before any message leaves the machine.¹

Can a message from another session approve a permission or change settings?

No. Claude Code tells the receiving session that a message came from another session rather than from you, and a message can never count as your consent, cannot answer a pending permission prompt, and cannot cause changes to permission settings, CLAUDE.md, or other configuration. Slash commands in the text arrive as plain text and are not executed, and any action the message asks for still triggers the receiving session’s own permission prompts.¹

Is this the same as A2A agent-to-agent interoperability?

No. A2A is an open protocol for task delegation between agents that do not share an owner, with machine discovery through an Agent Card published at /.well-known/agent-card.json. Claude Code cross-session messaging works only between your own sessions, resolves names from local files or an account-bound connection, and carries plain text rather than a structured protocol. It is a closed-world feature that happens to use the same three moves an open network needs.¹

Can one of my sessions message someone else’s session?

Not through this feature. The listing covers your subagents, your other local sessions, your cloud sessions, and your sessions on other machines connected to Remote Control. Reaching an agent that belongs to a different person is a different problem, requiring a name that resolves publicly, a way to verify who is on the other end, and consent from both parties rather than a setting you control on both sides.

Sources

Additional reading: the Claude Code launch post on X (https://x.com/ClaudeDevs/status/2085817074816070014) and the Latent.Space write-up of multi-agent coordination patterns (https://www.latent.space/p/ainews-zawinskis-law-of-multiagents).