Message your other Claude Code sessions

What happened

Here is the piece, plain prose only:

---

The technical detail

Anthropic has shipped cross-session messaging for Claude Code, a feature that lets one running Claude Code session send a text message to another session on the same machine, and lets sessions reply across machines through Remote Control. The feature requires Claude Code v2.1.224 or later and runs on macOS and Linux, including Linux inside WSL 2. It is not available on Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry, or native Windows. On a supported platform, messaging is on by default — there is nothing to enable.

The mechanics are straightforward. Claude Code gives each session two tools: ListAgents, which enumerates the sessions reachable from the current one, and SendMessage, which delivers a plain text string to a named session. Claude decides when to call these tools; the user never invokes them directly. Each session registers itself on disk and binds a Unix domain socket called its inbox socket. When another session on the same machine targets it, the message travels over that socket, never through Anthropic servers. Cross-machine messaging works differently: Claude can only reply to a message that first arrived from another machine's session via Remote Control, and those replies do travel through Anthropic's servers. The payload is always plain text — no conversation history, no files, no structured protocol messages.

Why it matters for builders

For engineers running parallel workstreams, the feature closes a coordination gap that previously required copy-pasting between terminals or stopping to update a second session manually. If a schema migration running in one session finishes and changes a column name, Claude in that session can message the session working on the API layer before the engineer notices the conflict. The same mechanism works for coordinating sessions running in separate git worktrees of the same repository, or for getting a status update from a long-running headless worker session started with claude -p. Importantly, a non-interactive -p session can receive messages and appears in the agent listing, though it cannot show an approval dialog, which means held messages stay held until a settings change releases them.

The inbound control model is worth understanding precisely. When a message arrives, Claude Code checks it against the receiving session's crossSessionInbound setting, which can be set to accept, hold, or refuse. When no explicit setting applies, Claude Code falls back on a permission-class comparison between sender and receiver. Sessions that bypass permission prompts form one class; everything else forms another. A prompting session accepts messages from other prompting sessions automatically but holds messages from bypassing sessions for manual approval. A bypassing session holds all messages from prompting sessions. The hold queue caps at 100 messages, and an unanswered approval dialog drops after five minutes by default, configurable via dialogExpiry. The cap on messages waiting to be read per session is 50, and repeated identical messages within a short window are deduplicated and dropped.

Market and competitive context

Competitively, this positions Claude Code closer to purpose-built multi-agent orchestration systems, but through a lighter mechanism than full orchestration. Dedicated frameworks like LangGraph or AutoGen handle agent-to-agent communication through structured graphs or message-passing architectures with explicit roles. Claude Code's approach is deliberately thinner: two tools, plain text, and per-session inbox sockets. That matches how developers actually use Claude Code in practice — multiple independent terminals, each steered by a human, occasionally needing to share a discovery. Anthropic is clearly hedging between agentic automation and developer-as-pilot workflows, building coordination primitives that work for both without forcing either model.

The practical configuration question for teams is where to set crossSessionInbound. At the user level, the setting applies to every session that user runs, which is probably fine for solo developers. For organizations running Claude Code in CI or on shared runners, administrators can apply managed settings that combine a deny rule on SendMessage and ListAgents with crossSessionInbound set to refuse, which effectively disables the feature at the org level. The isolatePeerMachines flag is the right choice for developers who want local session coordination but want explicit approval before any message routes through Anthropic's servers to another machine. That flag overrides even bypassPermissions mode, which is a meaningful safety boundary for teams that have automation in one environment talking to sessions in another.

What to watch next

Several constraints are worth watching. The feature is blocked by any of four environment variables that disable feature-flag evaluation — CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, DISABLE_TELEMETRY, DO_NOT_TRACK, and DISABLE_GROWTHBOOK — which means organizations with strict telemetry policies may find it silently disabled even on otherwise supported configurations. Container isolation also bites here: a session inside a container and a session on the host cannot reach each other because they do not share a filesystem. Two sessions inside the same container can still communicate, which opens up certain CI runner patterns but rules out the most common Docker-based dev environment setup. The reply-only restriction for cross-machine messaging also means the feature cannot bootstrap agent-to-agent conversations across machines — a session on machine B cannot initiate contact with machine A, it can only respond to something machine A started first, which limits the spontaneous coordination use case to same-machine deployments for now.