Two sentences, published the same week, describe the same Claude Code feature. The trade headline says Claude sessions “can now talk to each other and share context across terminals.” Anthropic’s own documentation says: “A message is a piece of text one Claude writes to another, never the sender’s conversation history or files.” Both cannot be true, and the one that is happens to be the one that decides how you should build on this.
The feature is cross-session messaging, shipped in Claude Code v2.1.224 on August 8, 2026 for macOS and Linux, with native Windows following in v2.1.234. When it is on, and on a qualifying session it is on with nothing to enable, one of your Claude Code sessions can hand a note to another: a finding, a status, a decision, a question. Two tools do the work, ListAgents to see which sessions are reachable and SendMessage to deliver to one by name, and you never call either yourself. Claude decides a sibling session needs to know something and sends it, or you ask it to.
That is genuinely useful, and the coverage of it has been mostly correct about the mechanics and mostly wrong about the meaning. The gap between “share context” and “send a text message” is not pedantry. It is the difference between a shared brain and a message queue, and if you are wiring several agents together to do real work, you are choosing between those two architectures whether you name the choice or not.
What actually moves between sessions
Nothing but text. Not the conversation history, not the open files, not the permissions, not the memory. When session A messages session B, B’s Claude receives the sender’s name, a reply address, and the message body. That is the whole payload. If the message says @migrations/schema.sql, the receiving Claude sees those characters as written; Claude Code attaches no file. The receiving session can go open that path with its own tools, if its own permissions allow, but the sender never reached across and handed it over.
Anthropic is not coy about this. The documentation points you somewhere else for the thing the headlines promised: to move a whole conversation or its context, you resume the session, a different feature entirely. To run a coordinated team of sub-sessions one Claude spawns and supervises, you use agent teams. To push external events like CI results into a session, you use channels. Cross-session messaging is the narrow one: independent sessions you started and steer yourself, passing each other short notes mid-task.
So the honest one-line description is closer to this: your parallel Claude sessions got a way to leave each other a sticky note, not a shared workspace. A migration finishes in one terminal and tells the session waiting on it “the new column is tenant_id, rebasing on main is safe now.” That is the canonical example in the docs, and it is a summary, not a state dump.
Message passing is the decision, not the shortcoming
The instinct, reading “it only sends text,” is to file it as a limitation, a version-one feature that will grow into real shared memory later. That reading gets the engineering backwards. Message passing between isolated processes with no shared mutable state is not the compromise; it is the pattern distributed systems converged on because the alternative does not survive contact with concurrency.
Anyone who has run production infrastructure has watched the shared-state version fail. Two workers holding the same mutable context drift, race, and clobber each other, and the bug shows up three steps downstream where it is unreadable. The fix, every time, is to stop sharing the state and start passing explicit, bounded, immutable messages, so that each worker owns its own world and the only thing crossing the boundary is a fact you can log. This site has made the point before in the multi-agent context: the failures in production agent systems live in the handoffs, not the model. Cross-session messaging is Anthropic building the handoff as the primitive, on purpose, and declining to build the shared state that would generate the failures.
It also sidesteps a quieter problem the site has documented as context rot: the longer and more crowded a context window gets, the worse a model attends to any single part of it. Merging two sessions’ full histories would double the noise in both. A one-line summary is not a lossy version of shared context. For a model whose accuracy degrades as the window fills, it is often the better input.
The security model is the part worth reading twice
Here is where the “shared context” framing stops being merely inaccurate and starts being dangerous, because it invites you to trust an inbound message the way you trust your own prompt. Anthropic’s design refuses to let you, and the refusals are specific.
A message from another session cannot approve anything. It “never counts as your consent,” so it cannot answer a pending permission prompt on the receiving side. It cannot change configuration: the receiving Claude is instructed never to alter permission settings, CLAUDE.md, or other config because a peer asked it to. Commands embedded in the text do not run; a /compact or any other slash command arrives as inert plain text. And if acting on a message would require a permission the receiving session does not have, the normal prompt fires, to you, exactly as it would for any other work. Permission boundaries stay per session, and Claude is told never to ask a sibling to do something that was denied in its own session, but to route that back to you.
Read that as a list and you have the correct mental model: an inbound message is untrusted input from a party that is not you. It is the same posture the browser-agent research forced on the industry this year, where any content an agent ingests has to be treated as potentially hostile. A peer session is friendlier than a web page, but the principle that a message cannot silently escalate is the reason this feature is safe to leave on, and the reason “they share context” is the wrong thing to tell your security team.
The channel is bounded in ways that also matter operationally. A session holds at most 100 messages and drops the oldest past that; it queues at most 50 accepted messages for Claude to read; a same-machine message is refused once it passes roughly a million characters; rapid bursts to one session get refused at the sender; and identical repeats inside a short window are dropped, so a message loop between two sessions throttles and dies on its own instead of spinning your token bill. Held messages that never get approved expire, by default after five minutes. These are the numbers of a rate-limited queue, not a shared memory space, and they are worth knowing before you point ten agents at each other.
Same machine stays on the machine. Across machines, it does not.
For anyone who has to answer where the data goes, the routing split is the single most important fact in the documentation, and it is clean. Two sessions on the same computer talk over a per-session Unix domain socket on macOS and Linux, or a named pipe on native Windows, and that traffic “never through Anthropic servers.” The socket is restricted to your operating-system user, so another user on a shared box cannot deliver into it.
The moment a session is on another of your machines or in the cloud, the message routes through Anthropic’s servers to get there. Reaching those sessions at all requires a claude.ai sign-in through Remote Control; Claude cannot find them with an API key, or on Amazon Bedrock, Claude Platform on AWS, Google Cloud’s Agent Platform, or Microsoft Foundry. So the enterprise reading is straightforward: local coordination is a local IPC channel you can reason about, and the second you span machines you have added a network hop through a vendor, with all the data-routing and retention questions that implies. If that hop is unacceptable for a given workload, the control is isolatePeerMachines, set to true, which forces your explicit approval before any message leaves the machine, even in a mode that skips ordinary prompts, and a checked-in project file can turn that requirement on but never off.
When the note is the wrong tool
Because the feature does one narrow thing, most of the value is in not reaching for it when you need one of its neighbors. If you want a second terminal to actually continue the first one’s work with all its history intact, that is resume, not a message. If you want one Claude to spawn and supervise a coordinated crew, that is agent teams, which pass richer structured protocol messages that stay inside the team. If you want CI output or a chat event to land in a session, that is channels. And if you are tempted to have agents relay large artifacts to each other as text, the million-character ceiling is telling you to write the artifact to disk and send the path.
The messaging tool earns its place in exactly one shape of problem: several long-lived sessions you are personally driving, in separate worktrees or on separate tasks, that occasionally need to tell each other a fact. A schema landed. A test suite went red. The interface you were both coding against changed. For that, a note beats copy-pasting between terminals and beats a human noticing the breakage three commits later. For anything heavier, the note is the wrong tool, and the docs say so by pointing elsewhere.
What to set before you turn a fleet loose
If you run this beyond a single laptop, treat it like any other automated channel between privileged processes, which is to say govern it before you scale it. Three settings carry most of the weight. crossSessionInbound, set per session to accept, hold, or refuse, decides what arriving messages do; a headless claude -p worker cannot show an approval dialog, so if you want it to take messages unattended you set accept explicitly in its own settings rather than inheriting a broad user default. isolatePeerMachines keeps everything on the box unless you approve a departure. And administrators can shut both directions off for an organization in managed settings by adding deny rules for SendMessage and ListAgents alongside crossSessionInbound: refuse, which still binds each inbox socket but drops everything that arrives.
The default, when no explicit value applies, is already conservative in a way worth understanding: a session running in a permission-skipping mode holds inbound peer messages for your approval rather than acting on them, precisely because a bypass session is the one you least want a peer nudging unsupervised. That is a sane default, but defaults are for the demo. The version you ship should name the inbound policy, name whether cross-machine hops are allowed, and log which session told which what, the same way you would for any service account that can talk to another service account.
None of that is exotic. It is the deny-by-default, log-the-handoff, scope-the-credential discipline that has governed machine-to-machine traffic for decades, applied to a new pair of talkers. The one thing that will get a team into trouble is the framing the headlines handed them: that these agents now share a mind. They do not. They pass notes, on a rate-limited queue, that cannot consent to anything on your behalf, and the day you internalize that is the day you can actually trust them to talk.