Claude Code Sessions Can Now Message Each Other

Claude Code sessions can 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. Since launch, Anthropic has extended it from replies-only across machines to full two-way messaging, added native Windows, and opened same-machine messaging to every provider. (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.

Claude calls both tools itself; you never call them directly. The same message tool reaches subagents, agent-team teammates, and 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 with a prompt such as “Ask the session running in my other terminal whether the migration finished.” Since Claude Code 2.1.232 you can name the target yourself: type @ and the first letters of the session's name and pick it from the typeahead, the same way you mention a subagent. (Claude Code docs)

On the receiving side, Claude reads an arriving message between tool calls during an active turn, so a running tool is never interrupted; when the session is idle, Claude Code starts a new turn with the message. A delivered message counts toward usage like a prompt you type. (Claude Code docs)

Where messages can travel

Starting a conversation with a session on another machine requires Claude Code 2.1.225 or later and a target that appears in the listing. A session shown as offline in the listing, one whose Remote Control connection has dropped, can still be messaged; the message arrives after that machine reconnects. If the sending session is not itself connected to Remote Control, a message to a session beyond the machine still goes through but carries no reply address, so the receiving Claude cannot answer it. (Claude Code docs)

A session inside a container and a session on the host cannot reach each other, though two sessions inside the same container can. A WSL 2 session and a native Windows session on the same computer cannot reach each other either. (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. Permission boundaries also stay per-session on the sending side: Claude is instructed never to ask another session for an action that was denied or blocked in its own session. (Claude Code docs)

Delivery can be accepted, held, or refused

The crossSessionInbound setting controls incoming messages:

When no explicit value applies, Claude Code decides per message from the two sessions' permission modes, grouping sessions that bypass permission prompts into one class and every other session into the other. A receiving session that prompts for permissions delivers each message and holds one only when the sender identifies itself as bypassing prompts. A receiving session that bypasses prompts holds each message and delivers one only when the sender is also bypassing. (Claude Code docs)

A held message opens an approval dialog in the receiving session. Approve delivers that one message; Deny or dismissing drops it; left unanswered past the dialogExpiry deadline, five minutes by default, Claude Code closes the dialog and drops the message. While no terminal is attached to a background session, the dialog stays open past the deadline. Claude Code holds at most 100 messages and past that drops the oldest. (Claude Code docs)

Since Claude Code 2.1.232 the value can also be picked in the /config row "Messages from your other sessions", which writes to user settings. Precedence is spelled out in the settings reference: Claude Code reads managed settings first, then the --settings flag, then user settings, and applies the first value found; a project or local value applies only when it is stricter, on the ladder that runs accept, then hold, then refuse. (Settings reference)

You can separately deny ListAgents and SendMessage with permission rules. Denying SendMessage also removes messaging to subagents and agent-team teammates, because the same tool serves all three. (Claude Code docs)

Cross-machine isolation

The isolatePeerMachines setting requires your explicit approval before any SendMessage reaches a session beyond the current machine. Anthropic says this applies even in bypassPermissions mode, which skips ordinary permission prompts. A true from any settings scope applies, so a checked-in project file can turn the requirement on but not off. Messages between sessions on the same machine never prompt. (Claude Code docs)

The session's inbox socket

On macOS and Linux, Claude Code binds a per-session Unix domain socket restricted to the operating-system user; on native Windows the inbox is a named pipe, and each connection must authenticate first with a key only your operating-system user can read. The session's peer address appears in /status, and the socket is exposed to hooks and Bash commands as CLAUDE_CODE_MESSAGING_SOCKET, alongside a per-session CLAUDE_CODE_MESSAGING_TOKEN. A script posting to its own session's socket can send the token as an auth line; on macOS and Linux the line is optional, on native Windows it is required. (Claude Code docs)

When the default socket directory cannot be accepted, for example because another user owns it, Claude Code uses a private /tmp/cc-socks-<uid> directory instead. When no directory can be accepted, the session runs without an inbox and /status shows unavailable with the reason. A connection that sends no complete line within 30 seconds is closed, so a script should capture its output first and then connect. (Claude Code docs)

Get a notice when another session goes idle

Since Claude Code 2.1.236, Claude can ask one of your sessions on the same machine to send back one notice when that session next goes idle or exits. It subscribes with the notify_when_idle input on SendMessage, either attached to a message or on its own; on its own, it spends no tokens in the watched session. If no notice arrives within 12 hours, Claude Code drops the subscription. Only the Claude in your main conversation can subscribe, and only to sessions on this machine; a request aimed at a teammate, a subagent, or a session beyond the machine is refused whole. (Claude Code docs)

Non-interactive sessions and limits

Long-running claude -p sessions bind an inbox and receive messages, but they cannot show an approval dialog. A message the inbound default holds there is kept for the dialogExpiry deadline and delivered only if a mode or settings change allows it before the deadline passes; past it, the message is dropped and reported as expired to a sender the session can reach. dialogExpiry: "never" keeps default-held messages until the session ends, and a message held by an explicit hold setting never expires. To let a worker take messages unattended, the docs recommend crossSessionInbound: "accept" in its --settings value. 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. A same-machine message is refused in the sending session once its serialized form passes about a million characters, and a rapid burst to one session is refused at the sender once it reaches what that session's inbox accepts. Those constraints keep a pair of sessions from creating an unbounded feedback loop. (Claude Code docs)

Version and platform requirements

Cross-session messaging requires Claude Code 2.1.224 or later on macOS, Linux, and WSL 2, and 2.1.234 or later on native Windows. Same-machine messaging is available on every provider, including Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform, and Microsoft Foundry, and in sessions that run with feature-flag fetching off; on those providers, and with flag fetching off, it requires 2.1.248 or later. (Claude Code docs)

Sessions beyond the machine, on other machines or on Claude Code on the web, are found from a session connected to Remote Control, which needs a claude.ai sign-in as the session's active authentication. Claude cannot find those sessions with an API key or on Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform, or Microsoft Foundry. Remote Control's requirements page says CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC and DISABLE_GROWTHBOOK make it unavailable, while DISABLE_TELEMETRY and DO_NOT_TRACK leave it available on Claude Code 2.1.283 or later unless the organization requires Trusted Devices. (Claude Code docs; Remote Control requirements)

Who can use it

The four questions a reader needs answered, from Anthropic's documentation as of September 30, 2026:

Sources: https://code.claude.com/docs/en/cross-session-messaging#availability; https://code.claude.com/docs/en/remote-control#requirements; https://code.claude.com/docs/en/desktop#work-across-sessions.

How to check a session

Run /list-agents, also available as /peers. If the command is not recognized, the session does not have cross-session messaging, and the docs say to start with claude --version. If it works but a send did not arrive, something narrower applies: a deny rule, the receiver's inbound controls, a cloud or other-machine session that appears only while this session is connected to Remote Control, or an older session that fell past the bounded number of list pages Claude Code reads. /status shows a Peer address row with the session's own inbox address. An arriving message shows as a one-line preview, Message from @<sender>: <first line>, and Ctrl+O expands it. (Claude Code docs)

While a session is connected to Remote Control, the /list-agents output withholds each local session's working directory and any session name it cannot attribute to a person, and ends with a note saying details were withheld. (Claude Code docs)

What changed after launch

Rows are from Anthropic's Claude Code changelog and the messaging page, checked September 30, 2026. The changelog is not dated per version; the docs page attaches the version numbers.

Sources: https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md; https://code.claude.com/docs/en/cross-session-messaging.

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, or ask for one notice when it goes idle. 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 the same machine, sessions list peers and send plain-text handoffs over local sockets on any provider; through Remote Control, a session can start a conversation with, and reply to, sessions on another machine or on the web. 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

• Claude Code documentation, “Message your other Claude Code sessions” (launched in Week 32, August 3-7, 2026, per the What's new digest; re-read September 30, 2026): https://code.claude.com/docs/en/cross-session-messaging
• Claude Code settings reference, crossSessionInbound, isolatePeerMachines, dialogExpiry: https://code.claude.com/docs/en/settings-reference
• Claude Code Remote Control requirements: https://code.claude.com/docs/en/remote-control#requirements
• Claude Code Desktop, working across sessions: https://code.claude.com/docs/en/desktop#work-across-sessions
• Claude Code changelog on GitHub: https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md
• Claude Code "What's new" digest, Week 32 (August 3-7, 2026), which dates the launch to v2.1.224: https://code.claude.com/docs/en/whats-new/2026-w32
• Internet Archive capture of the messaging page on August 8, 2026, which records the launch-day rules (replies only across machines; macOS and Linux only): https://web.archive.org/web/20260808003023/https://code.claude.com/docs/en/cross-session-messaging
• ClaudeDevs on X, the announcement post (August 7, 2026): https://x.com/ClaudeDevs/status/2085817074816070014
• ClaudeDevs on X, the follow-up post on asking another session a question (August 7, 2026): https://x.com/ClaudeDevs/status/2085817075923296444

Verification status (September 30, 2026). Every factual claim on this page is grounded on the documentation and changelog above. The two X posts are cited for the announcement only: each returns HTTP 200 with a JavaScript shell that contains none of the post text, so their descriptions stand as recorded on August 8, 2026 and cannot be re-checked by this site's tools.