AI Catchup

Claude Code Sessions Can Now Message Each Other

By 6 min read

Claude Code now lets independent sessions discover and message one another. The feature supports local coordination on macOS and Linux, reply-only communication across machines or the web through Remote Control, and controls for holding, refusing, or approving incoming messages.

Claude Code sessions can now discover and message one another. The feature is designed for independent sessions running in parallel: one can hand off a finding, ask another session whether a migration finished, or coordinate work happening in separate worktrees. (Claude Code docs; ClaudeDevs on X)

This is different from resuming one conversation or using an agent team. Cross-session messaging connects independent sessions and sends plain-text messages without transferring the sender's conversation history or files. (Claude Code docs)

What the feature adds

Claude Code exposes two capabilities for this workflow:

  • ListAgents discovers reachable sessions.
  • SendMessage sends a plain-text message to a named session.

The same message tool can reach subagents, agent-team teammates, or independent Claude Code sessions. The useful distinction is that cross-session messaging is for sessions that are otherwise separate. The receiving session gets the sender's name, a reply address when one exists, and the message text, but not the sender's context or files. (Claude Code docs)

Claude can send a message when it notices a useful handoff, such as a breaking change that affects another session's work. You can also ask it directly to contact another session with a prompt such as “Ask the session running in my other terminal whether the migration finished.” (Claude Code docs)

Where messages can travel

Other sessionTransportWhat is allowed
Same machinePer-session socket; messages do not go through Anthropic serversNew messages and replies
Another machineAnthropic servers through that machine's Remote Control connectionReplies only
Claude Code on the webAnthropic servers to the cloud sessionReplies only

The reply-only rule matters for expectations. A local session can ask another local session a question, but it cannot open a fresh conversation with a session that is only reachable through another machine or the web. Across machines, the remote session must send the first message before the other session can reply. (Claude Code docs)

Messages are not permission grants

Claude Code treats an incoming peer message as text from another session, not as user consent. A message cannot approve a pending permission prompt, change CLAUDE.md or other configuration, or execute a command written inside the message. If acting on the message requires permission, the receiving session shows the same permission prompt it would show for other work. (Claude Code docs)

That separation is the feature's most important safety boundary. It enables coordination without turning a message from a less-trusted session into an implicit approval to run a command or rewrite project settings.

Delivery can be accepted, held, or refused

The crossSessionInbound setting controls incoming messages:

SettingBehavior
acceptDeliver each message to Claude
holdShow a notice and wait for approval before delivery
refuseDrop incoming messages without delivering them

When no explicit value applies, Claude Code decides based on the permission modes of the sending and receiving sessions. A receiving session that prompts for permissions can accept messages from ordinary sessions, while a session that bypasses prompts may hold messages for approval. Held messages can expire after the default five-minute dialog deadline. (Claude Code docs)

You can separately deny ListAgents and SendMessage with permission rules. That makes it possible to turn off discovery and sending while still leaving the rest of a session's tool surface intact. (Claude Code docs)

Cross-machine isolation

The isolatePeerMachines setting requires explicit approval before a reply leaves the current machine. Anthropic says this applies even in bypassPermissions mode, which skips ordinary permission prompts. A project file can turn the requirement on, but cannot turn it off. (Claude Code docs)

On the same machine, Claude Code uses a per-session Unix-domain socket restricted to the operating-system user. The session's peer address appears in /status, and the socket is exposed to hooks and Bash commands through CLAUDE_CODE_MESSAGING_SOCKET. (Claude Code docs)

Version and platform requirements

Cross-session messaging requires Claude Code 2.1.224 or later. It is available on macOS and Linux, including Linux inside WSL 2. It is not available on native Windows, Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform, or Microsoft Foundry. (Claude Code docs)

The feature also depends on feature-flag evaluation. The documentation says settings such as CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, DISABLE_TELEMETRY, DO_NOT_TRACK, and DISABLE_GROWTHBOOK can turn that evaluation off, which can leave cross-session messaging disabled until the relevant variable is unset. (Claude Code docs)

Non-interactive sessions and limits

Long-running claude -p sessions can bind an inbox and receive messages, but they cannot show an approval dialog. If a message is held, it stays held until a later mode or settings change permits delivery. Bare-mode sessions do not bind an inbox socket and do not appear in the agent list. (Claude Code docs)

Messages are plain text, and the docs describe a few delivery limits: identical repeats are dropped within a short window, accepted messages waiting for Claude are capped at 50 per session, and repeated message loops are rate-limited. Those constraints keep a pair of sessions from creating an unbounded feedback loop. (Claude Code docs)

Workflows worth trying

The simplest use case is a status handoff. Leave one session running a migration or test suite, and ask another session to request a concise result rather than reopening the first transcript. A second pattern is parallel worktrees: a documentation session can tell the implementation session which API contract changed, while the implementation session reports when the change is ready for review.

For unattended workers, set the inbound behavior deliberately instead of relying on the default. accept can make a claude -p worker responsive without a human at the terminal, while hold or refuse is safer when messages could trigger costly or sensitive work. (Claude Code docs)

Bottom line

Cross-session messaging turns separate Claude Code terminals into a lightweight coordination network. On macOS and Linux, sessions can list peers and send plain-text handoffs over local sockets; through Remote Control, sessions on another machine or the web can reply but cannot start a new exchange. The permission boundary remains explicit: peer messages cannot approve actions or change configuration, and administrators can accept, hold, refuse, or isolate them. (Claude Code docs)

Sources

Keep building the workspace playbook

Frequently Asked Questions

What is Claude Code cross-session messaging?

It lets independent Claude Code sessions discover one another and exchange plain-text messages. A session can ask another session for status, hand off a finding, or coordinate work in separate worktrees.

Which systems support cross-session messaging?

The feature requires Claude Code 2.1.224 or later and is available on macOS and Linux, including Linux inside WSL 2. It is not available on native Windows or the listed cloud platforms.

Can Claude Code start a message to a session on another machine?

No. Across machines or with Claude Code on the web, a session can reply to an incoming message through Remote Control, but it cannot start a new exchange.

Can a message from another session approve a permission prompt?

No. Incoming messages are treated as peer-session text, not user consent. They cannot approve permissions, change configuration, or execute commands included in the message.

Get the weekly AI Catchup

Tools, practices, and what matters -- in your inbox every Monday.