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.

Requirements are narrow and worth knowing before you go looking for it: Claude Code v2.1.224 or later, macOS or Linux only, including Linux inside WSL 2. Not native Windows. Not on Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform or Microsoft Foundry. Where it does run and the account is eligible, it is on by default with nothing to enable. There is a way to lose that eligibility silently, which is its own section further down.

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.

What this adds up to is a compact local service-discovery system: names for addressing, filesystem visibility for membership, Unix-user permissions for isolation, and sockets for transport. The one-line announcement hides most of that architecture. It also means filesystem isolation is now messaging isolation, and that has one consequence that will bite people: a container has its own filesystem. A session inside a container and a session on the host cannot reach each other at all. Two sessions inside the same container can. If you run your agents in containers for isolation, you have already opted out, and the failure mode is that the other session simply does not appear in the list.

Three transports, and one of them is deliberately crippled

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

The first is that same-machine messaging never touches the network. It is peer-to-peer over a Unix domain socket, scoped to your filesystem and your user account. For a company shipping a cloud product, choosing the local path for the local case is a real design decision and they should get credit for it.

The second is that cross-machine is reply-only. You cannot start a conversation with a session on another machine or on the web. You can only answer one that it started. The documentation presents that as a limit rather than a to-do, and I read it as blast-radius thinking: the only way text crosses a machine boundary is if something on the far side opened the channel first.

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. It sorts every session into exactly two classes: those that bypass permission prompts, and those that prompt. Plan mode counts as bypassing where bypass is available; auto, acceptEdits and dontAsk all count as prompting.

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.

4. Holds expire, and loops die on their own

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.

On the same machine the sender is kept informed: it gets a notice when its message is held, and a follow-up when it is eventually delivered, denied or expired. A message refused on arrival produces no sender-side notice at all, which is the correct asymmetry. Held means pending, and you deserve to know. Refused means the other side does not want to talk to you, and you do not get to confirm they are even listening. The operational consequence is worth stating plainly: a successful send is not evidence that anything was read, and a peer you can see in the listing may be deliberately unreachable.

Loop protection is similarly unglamorous and correct. Repeated messages are rate-limited per sender, identical repeats inside a short window are dropped, and accepted-but-unread messages are capped at 50 per session. Between them, two sessions that start talking to each other in circles run down instead of running up, without anyone intervening.

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.

I went and checked my own autonomous harness while writing this. It launches every worker as a headless print-mode session with permissions skipped, and passes no settings file at all. Which means the fleet is currently in the worst square of that table: reachable in the listing, permanently unable to accept anything I send it. Nothing is broken. It has just never been configured for a feature that did not exist last week.

The other way to lose it silently

Cross-session messaging depends on feature-flag evaluation. If any of CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, DISABLE_TELEMETRY, DO_NOT_TRACK or DISABLE_GROWTHBOOK turns that evaluation off, the feature stays off entirely. Those variables can come from your shell, from a settings file's env map, or from managed settings.

So the most privacy-hardened setups lose it without being told, and it is easy to misdiagnose: the version is new enough, both sessions are on one machine, the names look right, the filesystem is shared, and still nothing works. Check those four variables before you go debugging sockets, containers or permission rules. There is a real tension there and I do not think it is dishonest, but it is worth naming: the feature whose local path deliberately never touches Anthropic's servers is gated on a flag check that does.

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, you do not have the feature, and claude --version against 2.1.224 is the first thing to check. If it works but a message never lands, messaging is on and something narrower is eating it: a deny rule, the receiver's inbound controls, or the reply-only rule if the target is on another machine.

If you run headless workers you want to reach, add crossSessionInbound set to accept to their settings now, before you spend an afternoon debugging a message that was held rather than lost. If you run them in containers, accept that they are unreachable from the host and stop looking.

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.

One more thing about turning it off, because it will surprise someone. A refusing session looks completely normal from the outside: unchanged in its own status output, unchanged in other sessions' listings. Nothing at the protocol level distinguishes a silent refusal from any other reason a message did not land, so the effective configuration is the authoritative check.

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.