Message your other Claude Code sessions

What happened

Here is the finished piece:

---

The technical detail

Message your other Claude Code sessions

Anthropic has shipped cross-session messaging in Claude Code, a feature that lets one running Claude instance discover and write to another on the same machine — or, in a limited form, across machines and web sessions. The capability lands in Claude Code v2.1.224 and later and is active by default on macOS and Linux wherever the version requirement is met. No configuration is required to turn it on between two ordinary interactive sessions. The feature is absent from native Windows and unavailable when Claude Code runs through Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform, or Microsoft Foundry.

Why it matters for builders

The mechanics rest on two tools Claude calls internally: ListAgents to enumerate reachable sessions, and SendMessage to address and deliver a message to one of them by name. Neither tool is exposed to the user; Claude finds targets and writes messages itself. Each session registers itself in files on disk and binds a Unix domain socket — its inbox — restricted to the operating-system user who owns it. Same-machine delivery travels over that socket and never touches Anthropic servers. Cross-machine delivery, supported only as replies to an inbound message rather than as newly initiated exchanges, routes through Anthropic's infrastructure and arrives over a Remote Control connection on the destination machine. A message is always plain text, never conversation history, never files, and it caps at 50 messages queued per session before older ones are dropped. Message loops between two sessions are throttled automatically, with identical repeated messages within a short window discarded.

For engineers running parallel workstreams — a common pattern when using worktrees, running a long migration in one terminal while developing in another, or supervising a background test suite alongside active work — the feature solves a concrete friction point. Previously, learning that session A finished a schema change and that session B should rebase required the developer to act as the courier: copy output, switch terminals, paste context. Now Claude in session A can write to Claude in session B directly, and the receiving Claude reads the message between tool calls without interrupting any tool that is currently running. When the receiving session is idle, Claude Code starts a new turn with the message rather than silently buffering it.

Market and competitive context

The permission and trust model is worth examining carefully. Incoming messages do not carry the user's authority. A message from another session cannot answer a pending permission prompt, cannot change CLAUDE.md or any configuration, and cannot cause a slash command to execute — slash command text arrives as plain text only. Permission prompts still fire on the receiving side exactly as they would for any user-issued instruction. The inbound side is controlled by a crossSessionInbound setting that accepts three values — accept, hold, or refuse — and when no explicit setting applies, Claude Code falls back to a rules-based default that groups sessions by whether they bypass permission prompts. A session running in bypass mode holds messages from standard sessions and vice versa; two bypass-mode sessions deliver to each other freely. Held messages expire after five minutes by default, configurable via the dialogExpiry setting. Administrators managing an organization can lock both directions off via managed settings, denying the ListAgents and SendMessage tools while setting crossSessionInbound to refuse.

In the current landscape of AI coding tools, the coordination problem this addresses is not unique. GitHub Copilot Workspace deals with multi-file, multi-step tasks but within a single orchestrated session rather than across independent ones. OpenAI's Codex CLI and similar tools have no concept of inter-session communication at all — parallelism is left entirely to the developer's own workflow. Anthropic is pushing in a different direction, building coordination primitives into the tool itself rather than expecting developers to script it externally. The session-naming system, the /list-agents and /peers slash commands, and the inbox socket architecture suggest this is infrastructure meant to be built on top of, not just a convenience feature.

What to watch next

Watch the inbox socket path specifically — exposed as the CLAUDE_CODE_MESSAGING_SOCKET environment variable and available before any hook runs including SessionStart — because that is where third-party integrations will attach. A hook or a Bash command can post directly to a session's socket, which Claude Code treats under the same inbound rules as a peer message, with an exception for verifiable own-child processes. On Linux including WSL 2, Claude Code can verify a posting process is a direct child even after it exits; on macOS this works only while the posting process is still running; in containers where Claude Code runs as PID 1, verification is impossible and the message is treated as unverified. Those edge cases will matter to anyone building automation on top of the socket.

The open question is what happens when sessions develop their own communication patterns that the user did not initiate or anticipate. Anthropic has rate-limiting and loop detection in place, and the 50-message queue cap is a hard backstop, but the feature also creates a new surface where one session can influence another's behavior in ways the user may not immediately notice — particularly in bypass-permission environments where the two sessions deliver to each other without any approval step. The permission model is deliberately conservative, and the documentation is explicit that a message can never substitute for user consent. Whether that boundary holds under the pressure of real multi-session workflows, where one Claude instance has strong reasons to ask another to act rather than just inform, is the thing worth watching as usage matures.