Your Sessions Can Talk. The Design Is in the Refusals.

On 7 August 2026 Anthropic announced that Claude Code sessions can message each other. The framing was pure convenience:

Read that as a productivity tweak and you would move on. I went and read the documentation instead, and the shape of the thing is different from the shape of the announcement. Everything below comes from that page or from the tool contract the model itself receives.

What shipped is an addressable peer network between agent processes. Every session now has a name, that name is a routable address, and a session can put text directly into a reachable peer's context window. That is a much larger change than not re-explaining yourself, and Anthropic clearly knows it, because the majority of the engineering is not in the sending. It is in an elaborate set of rules governing what a session refuses to accept.

The feature shipped with its own threat model already written into the product. That is the part worth reading.

What actually happens

You have two terminals open. In one, Claude just changed a database schema. In the other, Claude is building against the old one and does not know yet.

The first session writes a sentence and hands it to the second. Not a file, not a diff, not its conversation history. A sentence. Something like:

Schema migration finished: the new column is tenant_id, and rebasing on main is safe now.

The second session receives it labelled with the sender's name, reads it between two tool calls without interrupting whatever it was running, and carries on with that new fact in hand. If it was idle, the message starts a fresh turn. Once delivered it counts against your usage exactly like a prompt you typed yourself.

Two tools do this, and Claude calls both of them, not you: ListAgents to discover who is reachable, and SendMessage to deliver by name. You can see the same list yourself with /list-agents, aliased to /peers. Your own inbox address shows up in /status as a Peer address row.

Version update, checked 20 September 2026: current documentation lists native Windows support from v2.1.234 and same-machine messaging on all providers, including with flag fetching disabled, from v2.1.248. Earlier launch restrictions no longer describe every installation.

The name is the address

There is no separate addressing scheme. A session answers to its name, which you set with /rename or the --name flag. Leave it unset and Claude Code derives one from the working directory's folder name, giving you things like myapp-3f. Two sessions can absolutely end up with the same name, so the listing shows each local session's working directory to tell them apart, and Claude's own listing appends a short identifier it uses in the address when names collide.

That sounds cosmetic right up until the name becomes a destination. Naming your sessions clearly just stopped being terminal decoration and became operational hygiene.

Discovery is filesystem-based. Each session writes itself into files on disk and binds an inbox socket there. Two sessions can find each other only if they can see the same files, and the socket is restricted to your operating-system user, so on a shared machine another user's sessions cannot reach yours.

Discovery and local transport depend on the relevant filesystem and socket being reachable with compatible permissions. Containers are isolated by default, so host and container sessions normally cannot discover each other. Deliberately shared paths and sockets can change that boundary; do not describe it as impossible under every configuration.

Transport depends on the destination

Two things in that table deserve more attention than they will get.

Same-machine delivery uses local Unix-socket IPC rather than routing that transfer through Anthropic. That does not make the ensuing model turn network-free: delivered text can enter a request to the configured model service. Transport locality and model-processing locality are separate properties.

The original launch limited cross-machine conversations to replies. From v2.1.225, a session can initiate to a listed peer on another machine. That historical limit is no longer a universal boundary; explicit cross-machine approval and inbound controls still matter.

The refusal machinery

Here is the part that made me want to write this. A messaging feature is mostly plumbing. This one comes with four independent layers of things that stop a message from doing what it says.

1. An incoming message is structurally demoted

When session A messages session B, Claude Code explicitly tells B that this came from another session and not from you. That distinction is load-bearing, and four things follow from it:

That is the right instinct, and it carries more weight than it looks like. Without those constraints, sending text would also be a way to send authority: a confused or compromised session could clear another session's pending prompt, rewrite its operating rules, or smuggle slash commands into its control surface. The message carries information, not your identity. Three of the four are enforcement. The configuration rule is the odd one out, since the receiver is instructed rather than prevented, and it is worth knowing which layer you are standing on.

2. Permission laundering is a named attack, written into the tool contract

This is the single most interesting detail available, and you will not find it in the announcement. It is in the instructions the model itself receives when it uses the tool:

They shipped a convenience feature with the name of its own abuse case baked into the prompt. You denied something in this session, so do not go asking the session next door to do it for you. The name is exact: route the request through a party with cleaner permissions and it comes out the other side looking legitimate.

Be clear-eyed about what kind of defence this is, though. It is prompt-level. It works because the model follows an instruction, not because a boundary check refuses the call. That is genuinely softer than the structural demotions above, and it is worth saying out loud rather than pretending the whole stack is enforcement. What keeps it from being hollow is that the layer underneath is real: a laundered request still lands under the receiver's own permission policy rather than yours. Note the word policy. If the receiver is itself running with prompts bypassed, that policy is to not ask, which is exactly why the default holds messages that cross the boundary at all.

3. Three outcomes, and a default that reads privilege gradients

Every arriving message is checked against the receiver's inbound controls and ends up in one of three states.

You can force any of these with the crossSessionInbound setting, using accept, hold or refuse. But the interesting behaviour is what happens when you set nothing at all, which is what almost everyone will be running.

With no value set, Claude Code decides per message by comparing the two sessions' permission modes. For inbound-message classification, it groups sessions as bypassing or prompting. Plan mode counts as bypassing where bypass is available; auto, acceptEdits and dontAsk fall into the prompting classification. That classification does not promise an actual prompt: dontAsk denies actions that still require approval.

Read the table twice, because the symmetry is the point. Messages flow freely between peers in the same class. Crossing the boundary in either direction needs a human to approve the step. That is not a permissions rule, it is an information-flow rule.

A session running with permissions bypassed is, in effect, a more trusted process, and an addressable agent with broader permissions is a deputy. The upward guard stops an ordinary session appointing that deputy without you seeing the handoff. The downward guard stops a process that runs without interruption from quietly injecting instructions into a session you are actually watching. The upward case is the classic confused deputy; the downward one is closer to instruction injection. Both are guarded by default. That is a well-understood shape from operating-system design, and finding it as the default in an agent CLI is more thought than this feature needed to ship with.

Holds expire and backlog is bounded

The hold path is fully specified rather than hand-waved, which is usually where features like this get sloppy. The approval dialog shows you the sender and a preview. Leave it unanswered past the dialogExpiry deadline, five minutes by default, and it closes and the message is dropped. At most 100 messages sit in the hold queue, oldest evicted past that. If your session's permission class changes while messages are held, the rules re-run and anything now acceptable gets delivered. If a change makes refuse apply instead, every held message is dropped and a denial is reported back to each sender it can still reach.

Delivery, refusal and expiry are distinct outcomes, and notices vary by client version and transport. A successful send alone does not establish that a model read the message or completed the requested work. Inspect current documentation and receiver state when diagnosing delivery.

Rate limits, duplicate suppression and an unread-message cap bound delivery rate and queued work. They do not prove that a ping-pong exchange terminates. A workflow still needs explicit stopping conditions, limits and escalation.

The trap that will cost people an afternoon

Everything above is well behaved for two ordinary interactive terminals. Automation is where it gets sharp, and the failure is silent.

A headless claude -p session does bind an inbox socket. It can receive messages and it shows up in the listing, same as an interactive one. So far so good. Three facts then combine badly.

The message never arrives. Your sending session does get a hold notice, so this is not invisible if you go looking, but nothing errors, the worker carries on, and a hold notice reads like a delay rather than a dead end. You conclude the feature is broken when every component behaved exactly as documented.

A headless worker that holds messages but cannot display approval can appear reachable while never delivering them. Inspect the effective inbound policy and choose explicitly whether to accept, refuse or use another coordination mechanism.

The other way to lose it silently

Feature-flag settings can affect availability in older releases. Current documentation states that v2.1.248 and later supports same-machine messaging even with flag fetching disabled. Do not undo privacy settings solely to reproduce launch-era behavior.

Check client version, destination, provider and effective configuration before debugging transport. Local IPC avoids relaying that delivery through the service, but later model processing remains a separate data path.

What it is not

Anthropic is unusually direct about the boundaries here, and it saves you from reaching for the wrong tool. Cross-session messaging is for independent sessions that you start and steer yourself. Everything adjacent has its own feature.

The distinction that matters most: this moves a fact, not a context. A message is plain text one Claude wrote for another, and the tool never attaches your history or your files to it. Worth being precise, because that is a property of the transport and not a guarantee about content: the text is whatever the sending Claude chose to write, so a summary can always quote from either. If you need the other session to have what this one has, you do not want a message. You want to resume the session.

Five things I take from this

What to actually do about it

Check whether you have it: run /list-agents. If the command is not recognised, check feature availability for your installation with claude --version and the current platform requirements. If discovery works but a message never lands, check the effective deny rules, the receiver’s inbound controls, and the installed version’s cross-machine discovery and approval rules.

For headless coordination, choose an inbound policy deliberately and test a harmless message. Do not enable accept globally just to solve a connectivity problem. For containers, inspect filesystem and socket visibility before assuming either connectivity or isolation.

If you work anywhere with a security team, there are two levers they will want. The first is isolatePeerMachines: true, which demands your approval before any message leaves the machine, even in bypassPermissions mode. It ratchets one way: a true from any settings scope applies, so a checked-in project file can turn the requirement on but never off. The second is the full shutdown, and know the collateral before you reach for it: denying the send tool also kills messaging to subagents and agent-team teammates, because it is the same tool doing all three jobs. It takes both halves — deny rules on SendMessage and ListAgents to stop sending, and crossSessionInbound set to refuse to stop receiving.

Discovery and status alone do not establish delivery. A listed session may still refuse an incoming message; inspect the effective configuration and receiver state. Treat any delivery notice according to the behavior documented for the installed version and transport.

The feature is good. It is more carefully built than the announcement suggests, and the thing I would want other people building agent tooling to copy is not the messaging. It is the decision to write the abuse case into the product on day one, under its own name, where the model that could commit it will read it.