Claude Code Sessions Can Now Message Each Other

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

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)

Update (August 28, 2026): Since Claude Code v2.1.225, Claude can start a conversation with a session on another of your machines or on Claude Code on the web, as long as the target appears in the listing; the reply-only rule applied only before v2.1.225. If the sending session is not connected to Remote Control, the message still goes through but carries no reply address, so the receiving session cannot answer it. (https://code.claude.com/docs/en/cross-session-messaging)

Update (September 4, 2026): The same-machine row now covers native Windows too: the docs describe "a per-session socket on macOS and Linux, or a per-session named pipe on native Windows, never through Anthropic servers." Same-machine discovery works through registration files on disk, so two sessions can reach each other only when they see the same files. A session inside a container cannot reach one on the host, and a WSL 2 session and a native Windows session on the same computer cannot reach each other either, because they register under different home directories and listen on different socket types. (https://code.claude.com/docs/en/cross-session-messaging)

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:

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)

Update (September 4, 2026): Since Claude Code v2.1.232 the value can also be picked in the /config row "Messages from your other sessions", which writes to user settings. Precedence is now spelled out in the settings reference: a project or local value applies only when it is stricter than the managed, --settings, or user value, on the ladder that runs accept, then hold, then refuse. Held messages are capped at 100, separately from the delivery queue, and past that the oldest is dropped. Denying SendMessage also removes messaging to subagents and agent-team teammates, because the same tool serves all three. (https://code.claude.com/docs/en/cross-session-messaging; https://code.claude.com/docs/en/settings-reference#crosssessioninbound)

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)

Update (September 4, 2026): 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. Claude Code now also exports a per-session CLAUDE_CODE_MESSAGING_TOKEN; on macOS and Linux the auth line is optional, on native Windows it is required. When the default socket directory cannot be accepted, Claude Code falls back to a private /tmp/cc-socks-<uid> directory, and 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 scripts should capture output first and then connect. (https://code.claude.com/docs/en/cross-session-messaging)

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)

Update (August 28, 2026): The docs now list native Windows as supported from Claude Code v2.1.234, and same-machine messaging as available on every provider, including Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform, and Microsoft Foundry, and in sessions with feature-flag fetching off, from v2.1.248. Sessions beyond the machine, on other machines or Claude Code on the web, still require a claude.ai sign-in through Remote Control and remain unreachable with an API key or on those providers. (https://code.claude.com/docs/en/cross-session-messaging)

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)

Update (September 4, 2026): That dependency now applies only beyond the machine. Since v2.1.248, same-machine messaging works "in sessions that run with feature-flag fetching off." Reaching sessions on other machines or on the web still goes through Remote Control, whose requirements page lists the same four variables as disabling it. (https://code.claude.com/docs/en/cross-session-messaging#availability; https://code.claude.com/docs/en/remote-control#requirements)

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)

Update (September 4, 2026): The no-deadline rule was the launch behaviour. The docs now say that "before v2.1.225, no deadline applied in a -p session." Since then a message the inbound default holds in a -p session is kept for the dialogExpiry deadline, five minutes by default, then 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. (https://code.claude.com/docs/en/cross-session-messaging#non-interactive-sessions)

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)

Update (September 4, 2026): Two more limits are documented. A same-machine message is refused in the sending session once its serialized form passes about a million characters, and since v2.1.236 a rapid burst to one session is refused at the sender once it reaches what that session's inbox accepts; before that version the sends were reported as sent while the receiver dropped them. (https://code.claude.com/docs/en/cross-session-messaging#limitations)

Who can use it

The four questions a reader needs answered, from Anthropic's documentation as of September 4, 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; since v2.1.232 you can name a target yourself by typing @ and picking the session from the typeahead. (Claude Code docs)

What changed after launch

Rows are from Anthropic's Claude Code changelog and the messaging page, checked September 4, 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. 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)

Update (August 28, 2026): Since v2.1.225, sessions can also start conversations with sessions on other machines or Claude Code on the web, and native Windows is supported from v2.1.234. (https://code.claude.com/docs/en/cross-session-messaging)

Sources

• Claude Code documentation, “Message your other Claude Code sessions” (August 7, 2026; re-read September 4, 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
• ClaudeDevs on X, “New in Claude Code: your sessions can now message each other” (August 7, 2026): https://x.com/ClaudeDevs/status/2085817074816070014
• ClaudeDevs on X, “It goes both ways: you can also ask another session a question” (August 7, 2026): https://x.com/ClaudeDevs/status/2085817075923296444

Verification status (September 4, 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 now returns HTTP 200 with a JavaScript shell of about 214 KB that contains none of the post text, so their titles stand as recorded on August 8, 2026 and cannot be re-checked by this site's tools.