Anthropic has launched a cross-session messaging experimental feature for Claude Code, enabling direct message exchange between different sessions. This feature does not transmit full context, but rather only task results and dependency information, implemented through two internal tools: ListAgents and SendMessage. Each local session registers on disk and binds to an Inbox Socket; messages within the same machine are transmitted directly via Socket, while cross-machine messages are routed through Anthropic’s server. Messages trigger a new turn when the session is idle, and are read between tool calls during an active turn. The receiving end distinguishes cross-session messages from user messages; they cannot substitute user authorization and support three inbound control modes: accept, hold, and refuse. This feature integrates with existing capabilities such as Resume Session, Agent Teams, and Worktree, providing a coordination layer between Claude Code sessions.

Article author and source: Leifeng.com

In recent days, Anthropic has added a new experimental feature to Claude Code: cross-session messaging.

Simply put, it allows multiple Claude Code Sessions running simultaneously to send messages directly to each other.

For example, you open three Claude Code sessions: one for the database, one for the backend API, and one for testing. Previously, although these three sessions could work in parallel, they were unaware of each other’s progress. After the database session modifies the schema, the developer typically had to switch to another terminal and manually inform the backend session of the changes.

After integrating cross-session messaging, this step can be completed directly by Claude. The database session can notify the backend session which fields have changed, and if a test session detects interface regression issues, it can also send the results to the session currently modifying the relevant code. Claude can autonomously determine when to notify other sessions, or it can contact specified sessions as requested by developers.

To understand exactly what it does, follow the complete path of a message: what it passes, how it finds the target, when the message enters Claude, and why the recipient cannot simply act on it directly.

01 Not Context, it's a message

Cross-session messaging does not alter the original session isolation of Claude Code.

When Session A sends a message to Session B, it does not transmit its Conversation History, read files, or the entire Context Window. According to official guidelines, only text is passed between sessions. To migrate the full conversation and context to another device, you should Resume the original Session, rather than using cross-session messaging.

This determines how multiple Claude models collaborate.

For the database session to complete the migration, it read dozens of files and tested several approaches before determining that a specific field needed to be modified. The backend session doesn’t need to know the entire preceding analysis—it only needs to receive the final changes and how those changes will affect its API.

Therefore, cross-session messaging transmits task results and dependency information, not full working memory.

The benefit of this approach is that local information generated by different tasks does not continuously flood other sessions. Database-related details can remain within the database session, testing procedures can stay within the testing session, and information only crosses session boundaries when a change begins to affect other tasks.

It represents a different approach from “all agents share a single large context.” Cross-session messaging opts to keep sessions independent and explicitly synchronize necessary state only when tasks depend on each other.

Since a clear message is being transmitted, the next question is: How does Session A find Session B?

02 You must first find another session

Claude Code added its own communication endpoint to sessions that support cross-session messaging.

Each local session registers relevant information to disk and binds an Inbox Socket. Claude can use ListAgents to find currently reachable sessions, then use SendMessage to send messages to the specified target.

Users do not need to operate these internal tools themselves; they simply need to tell Claude which session to contact, or let it proactively notify the other party when a task has dependencies.

The session name is now also used for addressing. Claude can locate targets by name; if names are duplicated, the system appends a short identifier to distinguish them, while displaying the Working Directory to help users identify which project or directory each session is handling.

After the target is found, local messages are transmitted directly through the Socket of the corresponding Session, without passing through the Anthropic Server. Sessions on another machine or on Claude Code Web communicate with Remote Control-related connections via the Anthropic Server.

This discovery mechanism also defines the boundaries of local communication.

Claude Code needs to read registration information written to disk by other sessions, so even if two Claude instances are physically running on the same computer, they may not detect each other if their file systems are isolated. A typical scenario is a Host and a standalone Container; if both sessions are running within the same Container, they can communicate normally.

Inbox Socket is also subject to operating system user permissions, so other OS users on the shared server cannot directly access your session.

So here, what is referred to as "local communication" actually depends on whether the registration information is visible, whether the socket is accessible, and whether the operating system permits access.

The message has now successfully reached its destination and been delivered to the Inbox; next, it’s up to Claude Code’s Runtime to decide when to pass this message to the model.

03 After the message is delivered

Assume the backend session is currently modifying a file, when the test session sends a message indicating it has just detected an interface regression issue.

Claude Code will not immediately interrupt a running Tool.

If the target session is in Idle state, the message can trigger a new turn; if Claude is already in an Active Turn, the message will be queued and read between two Tool Calls.

This approach is related to how the Coding Agent executes tasks. Claude may be writing files, running tests, performing migrations, or handling other time-consuming tasks. If external messages could forcibly alter the current action at any time, it would be easy for tools to execute only part of a task while the Agent begins re-planning based on new information.

So the message affects Claude’s next decision, rather than directly interrupting an ongoing action.

This also means that Cross-session messaging has been integrated into Claude Code’s Agentic Loop as an asynchronous input source, and this entry point is not limited to other Claude sessions.

Claude Code exposes the current session's messaging socket to child processes launched by Hook and Bash. After a long-running background task completes, it can actively send the result back to the current session without requiring Claude to continuously poll for completion.

This channel itself is not a reliable message queue. Duplicate messages are rate-limited, and identical content within a short time may be discarded; for messages already accepted but not yet read by Claude, up to 50 per session are retained in Hold status, while messages in Hold status use a separate buffer with a maximum capacity of 100.

Therefore, it is better suited for sending status changes, task results, and collaboration notifications. Facts that must be preserved long-term should still be recorded in Git, files, databases, or other persistent systems.

After the message enters the Runtime, it still cannot be directly executed as an action, because the recipient must first determine the level of authority of the content received from the other Claude.

04 How are permissions inherited?

Claude Code clearly distinguishes between User Message and Peer Session Message.

Content from another session will not be considered as user authorization, so it cannot approve Permission Prompts on behalf of the user, nor can it request the recipient to modify Permission Settings, CLAUDE.md, or other configurations. Even if the message contains a Claude Code Command, it will be treated as plain text only.

If Session A requests Session B to delete a file, and this action requires user authorization in Session B, the original Permission Prompt will still appear.

Claude Code also restricts another method of permission bypass: if an operation has already been denied by the Permission System in the current session, Claude should not instead request another session to perform it on its behalf.

Otherwise, if the permissions of just a few sessions differ, a low-permission session could continuously delegate operations it cannot perform to a high-permission session, rendering the original permission boundaries ineffective.

Beyond permissions, the message itself has an additional Inbound Control layer. The receiver can set cross-session messages to accept,hold, orrefuse: forward it directly to Claude, hold it temporarily for further confirmation, or discard it outright.

If the user has not explicitly configured rules, Claude Code will also refer to the current Permission Mode of the sender and recipient. A Session that can bypass the standard Permission Prompt is not considered identical to a regular Session as a message source; when the recipient has higher inherent permissions, external messages may still be placed on hold.

There are actually two checks: first, determining whether the message can enter Claude, and second, determining whether Claude has permission to execute the action it prepares based on that message.

At this point, the complete path of a Cross-session message has been traversed: from message generation, target discovery, and delivery completion, to the Runtime reading the message, followed by the recipient’s own permission controls.

Coordination layer between sessions 05

Placing this pathway back into Claude Code’s current capabilities makes the position of cross-session messaging clearer.

Resume Session continues the original conversation and context, Agent Teams creates and manages a group of collaborative agents, Worktree isolates code changes across different sessions, and Remote Control addresses the issue of continuing session control from other devices.

Cross-session messaging handles a different scenario: how to pass necessary information between several sessions that were originally running independently but have developed dependencies during their tasks.

Previously, opening multiple Claude Code Sessions primarily addressed parallelization issues, but developers still had to monitor the progress of each terminal and repeatedly relay task statuses between themselves and the sessions. Now, information such as interface changes, test results, and completed migrations can be sent directly to the affected sessions.

Cross-session messaging does not combine multiple Claudes into a single agent; instead, it adds a layer of communication capability beyond the original context, working directory, and permission boundaries.

Viewed within a larger engineering context, this design offers another multi-Agent approach: different Agents can collaborate through well-defined communication interfaces without needing to share an increasingly large context. Once tasks, states, and permissions are separated, the system becomes easier to scale.

As the number of agents continues to grow, the question will gradually shift from "What can a single agent accomplish?" to "Can these agents reliably exchange state, manage dependencies, and complete handoffs?"

Although cross-session messaging only addresses one piece of the puzzle, it has already given Claude Code’s multi-session workflow a more complete engineering structure. Perhaps in the future, this local network-based cross-session mechanism will evolve into an Agent-to-Agent communication protocol spanning machines and ecosystems—today’s brief exchange between these two Claude instances could be a crucial step toward the formation of a highly automated software factory.