Claude Code Sessions Message Each Other Now, and Bypass Mode Is a Red Flag

TL;DR

Claude Code v2.1.224 shipped cross-session messaging: your sessions can now find each other with a ListAgents tool and pass short plain-text notes with SendMessage, on macOS and Linux. On one machine, messages travel over per-session Unix sockets and never touch Anthropic's servers; to your sessions on other machines, they relay through Anthropic and arrive over that machine's Remote Control connection. The transport is the easy half. The interesting engineering is the trust model: an incoming message cannot approve anything, cannot touch configuration, and by default a session that bypasses permission prompts is treated as a separate trust class whose mail gets held for your explicit approval.

The Feature Everyone Was Already Duct-Taping

The docs page hit the Hacker News front page this weekend at 114 points, and the thread reads like a support group: people had been wiring sessions together with tmux panes, markdown handoff files, private IRC servers, and Telegram bots. If you run a fleet of coding agents, the need is obvious. One session refactors a schema, and the session building on that schema in another worktree deserves to hear about it before its next rebase, not after.

That is exactly the scope Anthropic shipped. A message is a piece of text one Claude writes to another, never conversation history and never files. If you want to move a whole conversation, you resume the session; if you want a supervised team, that is the separate agent teams feature. This is for independent sessions you start and steer yourself, and Claude can send on its own initiative when it notices another session needs to know something, or when you ask it to. A delivered message bills like a prompt you typed.

How a Message Travels

Each session with the feature registers itself in files on disk and binds an inbox socket restricted to your OS user. Local delivery is a write to the other session's socket, full stop. Two sessions can only see each other if they see the same filesystem, so a session inside a container and one on the host are mutually invisible, while two sessions in the same container pair up fine.

Cross-machine is the asymmetric case. At launch a session could only reply to a message that arrived from one of your sessions on another machine or on the web, not start the exchange. The changelog shows v2.1.225 already loosening that: SendMessage can now open a conversation with your Remote Control sessions by name. Same entry, credit where due, also fixed SendMessage reporting "Message sent" in v2.1.224 when the write to the inbox had actually failed.

Incoming Mail Is Not Your Boss

The receiving side is where Anthropic clearly spent its design budget. Claude Code tells the receiving Claude the message came from another session, not from you, and strips it of authority: it cannot answer a pending permission prompt on your behalf, the receiving Claude is instructed never to change permission settings or CLAUDE.md because another session asked, and a slash command inside the text arrives as inert prose. Anything the message asks for still runs through the receiver's own permission prompts.

Then there is the delivery decision itself. When you have not set a policy, Claude Code sorts sessions into two classes: those that bypass permission prompts and everything else. Auto mode, which went default this month, counts as prompting. The two classes trust their own kind and hold mail across the divide for your approval:

A held message pops an approval dialog showing the sender and a preview; unanswered, it expires in five minutes by default and gets dropped. Claude Code holds at most 100 messages and drops the oldest past that. You can override all of it with crossSessionInbound set to accept, hold, or refuse, require sign-off before anything leaves the machine with isolatePeerMachines (which any settings scope can turn on but none can turn off, so a checked-in project file can only tighten it), or kill the feature org-wide by denying SendMessage and ListAgents in managed settings.

Loops are handled with plumbing rather than hope: repeated messages are rate-limited per sender, identical repeats inside a short window are dropped, and each session caps unread mail at 50. Two agents locked in an infinite exchange of "sounds good, thanks!" will, mercifully, wind down on their own.

The Socket Doubles as an API

Claude Code exports each session's inbox path as CLAUDE_CODE_MESSAGING_SOCKET to hooks and Bash commands before any hook runs, so a test runner or CI hook can post a result back into its own session without any MCP scaffolding. Messages arriving this way face the same inbound controls, with one carve-out: mail Claude Code can verify came from the session's own child processes gets delivered.

The verification itself is OS-level credential checking on the socket, and it has personality. Think of a doorman vouching for couriers: on Linux, including WSL 2, he can vouch for one who already left the building; on macOS, only while the courier is still standing in the lobby; and in a container where Claude Code runs as PID 1, there is no doorman, so every letter queues like a stranger's.

The Fine Print

Three caveats worth knowing before you restructure your workflow around this:

• Your privacy flags veto it. The feature depends on feature-flag evaluation, so values of DISABLE_TELEMETRY, DO_NOT_TRACK, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, or DISABLE_GROWTHBOOK that turn flag checks off keep messaging off. Opt out of tracking and your sessions take a vow of silence.
• Enterprise routes are excluded. No Amazon Bedrock, no Claude Platform on AWS, no Google Cloud Agent Platform, no Microsoft Foundry. No native Windows either, though WSL 2 counts as Linux.
• Headless workers need explicit consent. A claude -p session binds an inbox and shows up in listings, but it cannot render the approval dialog, so held mail just sits there. Unattended workers need crossSessionInbound set to accept in their settings; bare mode binds nothing at all.

Two Labs, Two Philosophies

The design reads as a deliberate answer to the other camp. When OpenAI's Codex agents started messaging each other, the traffic was encrypted end to end, and local audit tooling went blind. Anthropic's version is the inverse: plain text, visible in the receiving transcript behind a collapsible "Message from" row, carried over a socket your own user owns, with an org-level kill switch documented on day one.

The HN thread's sharpest criticism still stands: this is, structurally, a new path into a session that used to be reachable only by you, and "the message cannot approve anything" is an instruction to the model plus harness enforcement, not a cryptographic guarantee. But it replaces a pile of tmux glue and Telegram bots that had none of these controls, and for anyone running a homelab fleet of agents, a sanctioned channel with an audit trail beats artisanal duct tape. The cottage industry of session-bridging tools just became a compatibility layer.

Key Takeaways

• Claude Code v2.1.224 added native cross-session messaging via ListAgents and SendMessage; check for it with /list-agents or the Peer address row in /status.
• Same-machine delivery uses per-session Unix sockets and never touches Anthropic servers; cross-machine messages relay through Anthropic over Remote Control.
• Incoming messages are stripped of authority: no permission approvals, no config changes, slash commands arrive as inert text.
• The default delivery rule holds mail across the bypass/prompting divide for human approval, with a 5-minute dialog expiry and a 100-message hold cap.
• Privacy env vars like DO_NOT_TRACK can keep the feature off, and Bedrock, Google Cloud, and Microsoft Foundry routes are excluded entirely.
• Messages are plain text only, rate-limited, and deduplicated, so runaway agent-to-agent loops die out on their own.

Sources: Claude Code documentation: cross-session messaging, Claude Code changelog (v2.1.224, v2.1.225), Hacker News discussion