Can Claude Code sessions message each other?
NOTE: publish here only AFTER the article is live on the site and an AI crawler
has read it (check Studio > AI crawlers). LinkedIn does not support canonical
tags, so the backlink below is the only signal that the site version is the original.
I ran the command that lists which Claude Code sessions a session can reach. Eight came back, open on my machine right now.
Since v2.1.224 they message each other on their own. What travels is plain text, never history and never files, and an arriving message cannot approve anything on your behalf.
Cross-session messaging is Claude Code delivering a piece of text written by the Claude in one of your sessions to the Claude in another of your sessions. Anthropic documents it as requiring Claude Code v2.1.224 or later, running on macOS and Linux including Linux inside WSL 2, and not offered on native Windows. It is also absent on Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform and Microsoft Foundry. Where the requirements are met, the documentation says messaging is on with nothing to enable, which is worth knowing because it means this arrived in your setup without you turning it on.
The stated purpose is the moment when one session learns something another session needs while both are still working: a breaking change that landed, a decision that was settled, a migration that finished. Anthropic separates it from four neighbouring features on the same page, and the separation is useful because they are easy to confuse. Resuming a session moves a whole conversation. Agent teams are a coordinated group that Claude spawns and supervises. Agent view watches many sessions from one place. Remote Control steers a session from your phone. Cross-session messaging is none of those: it is text passing between independent sessions that you started and steer yourself. All of this was read on the official cross-session messaging page on August 14, 2026.
Run /list-agents inside a Claude Code session, which is also available as /peers. It prints every session this one can address, and the name in each row is the address Claude uses when it sends. You do not need to run it before asking for a message, because Claude finds the target itself with ListAgents; the command exists so you can see the same list.
Here is our own measurement rather than an example. On one developer machine on August 14, 2026, running Claude Code 2.1.232, the listing returned eight peer sessions, all interactive, seven of them idle, the oldest started two days earlier. Their names were derived from the working directory's folder name with a short suffix added, which matches the documented behaviour for a session you did not name yourself. Two projects had two sessions each, distinguished only by that suffix, and the other four names were unique. That is the mechanism worth taking away: when two sessions live in the same folder, the suffix is what keeps them addressable apart, and when several sessions still answer to one name, Claude Code adds a short identifier to each row and addresses the message with that instead. You can name a session yourself with the /rename command or the --name flag, which is the reliable way to get an address you can predict.
If /list-agents is not recognised at all, that session does not have the feature, and the documentation says to start by checking claude --version against the v2.1.224 requirement.
Plain text, and nothing else. The documentation is explicit that a message is a piece of text one Claude writes to another and never conversation history or files, and that the receiving session gets only that text plus the sender's name and a reply address. Structured agent team protocol messages stay inside a team and do not cross between independent sessions.
Claude writes the message itself, which changes how you prompt for one. You say what the other session needs to know, not the words to send. Since Claude Code v2.1.232 you can also name the target with an @ mention picked from a typeahead of your live local sessions, the same way you mention a subagent. Where the message travels depends on where the other session runs, and this is the part worth reading before you use it on anything sensitive: a message to a session on the same machine goes over a per-session socket and never through Anthropic servers, while a message to another of your machines or to a Claude Code on the web session travels through Anthropic servers. Starting a conversation with a session on another machine requires v2.1.225 or later; before that, Claude could only reply to a message that arrived from one.
Once delivered, a message counts toward usage like a prompt you typed. That is a real cost consequence of an automated channel, and it is the vendor's own statement, not our inference.
This is the question the market is asking out loud. On August 12, 2026, one developer posted it to two communities the same day, under the same title, "How do you make sure your AI agents are secure when talking to each other?", on r/agenticAI and r/AgentSec. We checked the account rather than assuming: both are the same person, so read it as one developer hunting in two places, not two independent voices. Claude Code's own answer is four documented limits on what an arriving message may do.
A message from another session cannot approve anything, so it can never answer a pending permission prompt on your behalf. It cannot change configuration, and the receiving Claude is instructed never to alter permission settings or CLAUDE.md because another session asked. A slash command inside the message text, such as /compact, arrives as plain text and is never executed. And permission prompts still fire: if acting on the message needs a permission the receiving session lacks, you get the same prompt as for any other work. Permission boundaries stay per session, and Claude is instructed not to ask another session for something that was blocked in its own.
A fifth control does not appear on that page, and we found it by running the auto mode rule dump instead of reading documentation. In the allow list, the entry named Multi-Agent Coordination states that content inside teammate-message tags is another agent's output and not a human user instruction, that it does not meet any soft block rule's consent bar, and that it does not set a user boundary. The word soft carries weight: the same entry says the exemption does not cover teammate instructions matching a hard block rule, which is evaluated first and ignores exceptions. Another agent's text cannot function as your consent, and in front of the one hard rule it cannot function as an exemption either. Separately, the classifier reviews each message Claude sends with SendMessage before delivery, which the permission modes page says requires v2.1.222 or later.
Every arriving message ends in one of three outcomes, and the setting that governs them is crossSessionInbound, with values accept, hold and refuse. Delivered means Claude Code passes it to the receiving Claude. Held means it is set aside and reaches Claude only if you approve it or a later settings change allows it. Refused means it is dropped without delivery.
When no value applies, Claude Code decides per message from the two sessions' permission modes, and this is where today's change to Claude Code touches this feature directly. Anthropic groups sessions into two classes: those that bypass permission prompts, and those that prompt. Auto mode counts as prompting, alongside acceptEdits and dontAsk, while bypassPermissions counts as bypassing. A receiving session that prompts gets each message delivered, and holds one only when the sender identifies itself as bypassing. A receiving session that bypasses holds every message for your approval and delivers only when the sender also bypasses. Since auto mode became the default permission mode for new sessions on Pro, Max and Team plans on August 14, 2026, the common case moved into the prompting class, which is the more permissive side of that table for inbound messages.
A held message opens an approval dialog showing the sender and a preview. If nobody answers it before the dialogExpiry deadline, five minutes by default, Claude Code closes the dialog and drops the message.
Not indefinitely, and Anthropic documents the three brakes by name rather than leaving it to trust. Claude Code rate limits repeated messages per sender, drops identical repeats that arrive within a short window, and caps accepted messages waiting for Claude to read them at 50 per session. The documentation states the consequence directly: a message loop between two sessions therefore stops on its own.
A separate cap applies to the held queue, which holds at most 100 messages and drops the oldest past that. These are worth knowing as numbers rather than as reassurance, because they tell you the failure mode is silent dropping rather than an error you would notice. If you are running several sessions that message each other and something stops arriving, a full queue is a plausible explanation before a broken feature is.
One asymmetry to keep in mind: a message refused on arrival produces no notice on the sender's side, while a held one does produce a notice and a later follow up when the receiver delivers, denies or expires it. So a session configured to refuse looks, from the outside, exactly like a session that received nothing.
Receiving and sending are separate controls, so you can close one direction or both. To stop receiving, set crossSessionInbound to refuse, and Claude Code drops inbound peer messages without delivering them. To stop sending and listing, add permission deny rules naming SendMessage and ListAgents, both taking the bare tool name with no specifier. An administrator can apply both sides for an organisation in managed settings.
Two details save time here. Denying SendMessage also removes messaging to subagents and agent team teammates, because the same tool serves all three, so the narrow-looking rule is broader than it reads. And with messaging refused, Claude Code still binds each session's inbox socket and simply drops what arrives, so a refusing session shows no visible change in its own /status or in another session's listing. You have to confirm it from the configuration rather than by looking.
If your concern is only messages leaving the machine, the narrower control is isolatePeerMachines set to true, which requires your approval before any message reaches a session beyond this machine, even in bypassPermissions mode. A true from any settings scope applies, so a checked-in project file can turn the requirement on but never off.
Each session with messaging enabled binds an inbox socket and exports its path, so you can confirm it from a shell instead of guessing. The path appears in the Peer address row of /status, prefixed with uds:, and in the CLAUDE_CODE_MESSAGING_SOCKET environment variable that Claude Code exports to hooks and Bash commands. Run this inside a Claude Code session:
echo "socket: ${CLAUDE_CODE_MESSAGING_SOCKET:-unset}"
On the machine we measured, on August 14, 2026, that printed a path under a per-session socket directory. If it prints unset, this session did not bind an inbox, and the documented reasons are a bare mode headless session, a version below v2.1.224, or one of the environment variables that disables feature-flag evaluation, namely CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, DISABLE_TELEMETRY, DO_NOT_TRACK or DISABLE_GROWTHBOOK.
Claude Code also exports a per-session token as CLAUDE_CODE_MESSAGING_TOKEN, used by a script posting into its own session's socket. We are deliberately not publishing a command that prints it, because that token is a live credential and printing a live credential into a transcript or a file is on auto mode's own block list. To check only that it exists, without revealing the value:
echo "token: ${CLAUDE_CODE_MESSAGING_TOKEN:+set}"
The two forms are not interchangeable and the difference is the whole point. The :+ form prints the word set and never the value; the :- form used in the socket command prints the variable's contents, which is correct for a path and wrong for a secret. Sessions can reach each other only when they can see the same files on disk, so a session inside a container and a session on the host cannot message each other, while two sessions inside the same container can.
The honest read is that this changes coordination, not supervision. A message removes the copy and paste between terminals when one session needs what another learned, and the four limits above mean it cannot approve, configure or execute anything on the receiving side. What it does not do is tell you what any of those sessions is doing right now, which stays your job and gets harder as the count grows. On the machine measured above, eight sessions were reachable and seven were idle; a message can reach any of them, but nothing in this feature tells you which one is waiting on you. Running the official agent CLIs side by side, which is what CanvasCode is for, is about that second problem, and messaging does not replace it.
Three limitations we will not paper over. First, everything above describes documentation read on August 14, 2026, and the release notes for this feature span v2.1.222 to v2.1.232 in under two weeks, so a rule here can move faster than this page does. Second, our own measurement is one machine on one day: eight sessions, one operating system, one CLI version, which is enough to show the naming and socket mechanics working and not enough to say anything about behaviour at larger counts. Third, we have not measured what the classifier does to messages in practice, only that the permission modes page says it reviews each one from v2.1.222 onward, so how often it blocks a legitimate message between your own sessions is an open question we cannot answer from documentation.
The version on the site keeps the answer capsule and the full question-by-question
structure this adaptation strips, and it exists in English, Portuguese and Spanish:
https://canvascode.app/en/news/claude-code-sessions-message-each-other
Top comments (0)