Claude Code Sessions Can Now Message Each Other
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:
ListAgentsdiscovers reachable sessions.SendMessagesends 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 session | Transport | What is allowed |
|---|---|---|
| Same machine | Per-session socket; messages do not go through Anthropic servers | New messages and replies |
| Another machine | Anthropic servers through that machine's Remote Control connection | Replies only |
| Claude Code on the web | Anthropic servers to the cloud session | Replies 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:
| Setting | Behavior |
|---|---|
accept | Deliver each message to Claude |
hold | Show a notice and wait for approval before delivery |
refuse | Drop 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
- Claude Code documentation, “Message your other Claude Code sessions” (August 7, 2026): https://code.claude.com/docs/en/cross-session-messaging
- 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
Read next
Keep building the workspace playbookClaude Code 2.1.142: `claude agents` Gains Session Flags, Fast Mode Defaults to Opus 4.7, MCP Tool Timeout Honored
Anthropic shipped Claude Code 2.1.142 on May 14, 2026. The release adds eight session-configuration flags to `claude agents` (`--add-dir`, `--settings`, `--mcp-config`, `--plugin-dir`, `--permission-mode`, `--model`, `--effort`, `--dangerously-skip-permissions`), flips fast mode's default model from Opus 4.6 to Opus 4.7, and fixes `MCP_TOOL_TIMEOUT` not raising the per-request fetch timeout for remote HTTP/SSE MCP servers -- a regression that capped tool calls at 60 seconds regardless of configuration.
Claude Managed Agents Add Self-Hosted Sandboxes (Public Beta) and MCP Tunnels (Research Preview)
Anthropic says Claude Managed Agents can now run tool execution in a sandbox you control (public beta) and connect to private MCP servers via MCP tunnels (research preview). The update targets enterprise security requirements by keeping execution and private services within an organization's perimeter.
Claude Platform's 'ant' CLI Brings the Full Claude API to Your Terminal
Anthropic's Claude Platform documents 'ant', a command-line tool that exposes every Claude API resource as a subcommand. It sends Messages requests, browses responses, version-controls agents and environments, and runs a self-hosted Managed Agents worker, with Claude Code able to drive it natively.
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.