Claude Code sessions can now message each other

If you run more than one Claude Code terminal — one on the migration, one on the API, one grinding through tests — you've spent time copy-pasting context between them. Anthropic shipped the fix: cross-session messaging, where one session can hand a finding to another without you in the middle. It's a real productivity win and it quietly adds a new channel into your dev environment. Both facts deserve attention.

What actually happened

Per Anthropic's documentation, the feature needs Claude Code v2.1.224 or later and runs on macOS and Linux, including Linux under WSL 2. There is no native Windows support, and it is not available on Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform, or Microsoft Foundry. When a session meets the requirements, it's on with nothing to enable.

Two tools do the work: ListAgents finds reachable sessions, SendMessage delivers to one by name. You never call either yourself — Claude can decide to send on its own, for example after making a change that breaks what another session is building on.

The transport matters. Same machine goes over a per-session Unix socket, never through Anthropic servers, and each session's socket is restricted to your OS user. Cross-machine goes through Anthropic servers over that machine's Remote Control connection, and it is reply-only — a local session can answer a message from your laptop, but it can't start the conversation. Container filesystems are their own boundary: a session in a container and one on the host can't see each other's registration files, so they can't reach each other.

A message is plain text only — never conversation history, never files. The receiving Claude is told the message came from another session, not from you, and the constraints follow from that: it can't approve a pending permission prompt, it can't be used to change permission settings or CLAUDE.md, and a slash command in the text arrives as text and doesn't run. Permission prompts still fire on the receiving side for anything the message asks for. Loops are throttled: identical repeats inside a short window get dropped, and accepted-but-unread messages cap at 50 per session.

Why cross-session messaging matters for your business

The default is well-reasoned, which is exactly why you should read it rather than inherit it. When no setting applies, delivery depends on the two sessions' permission modes. A session that prompts for permissions accepts messages, and holds one only when the sender identifies as bypassing prompts. A session that bypasses prompts holds everything for your approval unless the sender also bypasses. Held messages open a dialog that expires — five minutes by default via dialogExpiry — and then get dropped.

Three settings are worth deciding on today, not after an incident:

• crossSessionInbound takes accept, hold, or refuse. Set it to refuse and inbound peer messages get dropped without reaching Claude. From project or local settings, refuse wins over everything else.
• isolatePeerMachines: true requires your explicit approval before any message leaves the machine — including in bypassPermissions mode. A true from any settings scope applies, so a checked-in project file can turn it on but not off.
• Deny rules on SendMessage and ListAgents stop this session sending or listing. Note the tradeoff: denying SendMessage also removes messaging to subagents and agent teams, since it's the same tool.

For an org-wide off switch, managed settings combine both directions — the deny rules plus crossSessionInbound: "refuse". Sockets still get bound; every arriving message is dropped.

One operational wrinkle worth planning for: a refusing session shows no visible change in its own /status or in other sessions' listings. Confirm it from configuration, not by looking. And a headless claude -p worker can't show an approval dialog, so a held message stays held there forever — if you want an unattended worker to take handoffs, pass crossSessionInbound: "accept" in its --settings.

Our read: turn it on for interactive work, set isolatePeerMachines: true, and keep refuse on anything running unattended in CI. This is the same posture we take on network allowlists and auto mode — the feature is fine, the default is a decision, and the decision should be yours.

Sources: Anthropic Claude Code docs, The Decoder.