Your Claude Sessions Can Now Text Each Other. Here's What That Actually Means.

This piece breaks down:

• What the feature is

• How it works underneath

• What it can and cannot do

• The problems it fixes

• The new problems it creates

• The real questions readers asked when the announcement dropped

Here are some things you need to understand to follow this feature

You only need four words to follow the rest of this.

Session. One conversation with Claude Code. You open a terminal, type claude, and that is one session. Open a second terminal and run it again, and that is a second, completely separate session. It has its own memory, its own project folder, its own permissions. Before this feature, sessions were strangers.

Agent. In Claude Code's language, any Claude instance that can be addressed by name. Your sessions are agents. So are subagents (helpers a session spawns for a side task) and teammates (part of an experimental group feature). This matters because the same messaging tool serves all three.

Tool. A specific action Claude is allowed to take, like reading a file or running a command. Two new tools power this feature: ListAgents (find out who is reachable) and SendMessage (deliver text to one of them).

Socket. A private channel on your computer that two programs use to talk to each other directly. No internet involved. This is the pipe your sessions use.

What the feature actually does

When one session learns something another session needs, Claude writes a short note and delivers it. That is it.

A message is plain text. Nothing else crosses. Not your conversation history. Not your files. Not context. Just words that one Claude wrote for another Claude to read.

The documented example is a session that finished updating the database setup, telling another session what new piece of data it added and that it is now safe to catch up. Short. Factual. Actionable.

Claude can decide to send one on its own when it notices the need. You can also just ask, in plain English: tell the session working on the payments API what we just changed. You do not write the message. Claude does. You give it the intent and it phrases the note.

You never call the tools yourself. Claude finds the target session and addresses it.

Anthropic's @ClaudeDevs account announced it on August 7, 2026, framing it as a way to stop re-explaining yourself in a second session: Claude sends a summary rather than your history or files, and the receiving session picks it up mid-task. Full details are in the documentation.

How it works underneath

Every session that has this feature turned on registers itself in files on your disk and opens a private socket. That socket is locked to your operating system user account, so on a shared machine, another person's sessions cannot reach yours.

When Claude wants to message a session, it reads those registration files to see who exists, then writes to that session's socket.

The receiving side has three possible outcomes:

• Delivered. The message goes through to the other Claude.

• Held. The message is set aside and a notice appears. It only reaches Claude if you approve it or a setting changes.

• Refused. Dropped. Never delivered.

Timing matters. If the receiving session is mid-task, Claude reads the message between tool calls. A running command is never interrupted. If the session is sitting idle at the prompt, the message starts a new turn immediately.

Sessions are named. You set a name with /rename or the --name flag when launching. If you do not, Claude Code names it after the folder you are working in, something like myapp-3f. To see who is reachable, run /list-agents (also available as /peers).

Where it works and where it doesn't

Worth answering early, because the answer is more restrictive than it first appears.

Version: Claude Code v2.1.224 or later. Run claude --version to check.

Operating system: macOS and Linux. That includes Linux running inside WSL 2 on a Windows machine. Native Windows does not get it.

Provider: Not available if you run Claude Code through Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform, or Microsoft Foundry. This is an Anthropic API feature.

Some assumptions to debunk. It is not terminal only. Local sessions in the Claude Desktop app's Code tab get it too, on supported operating systems. And when they do, the desktop app can see and message terminal sessions, which its own built-in session tools cannot do.

Silent kill switch: If you have set any of CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, DISABLE_TELEMETRY, DO_NOT_TRACK, or DISABLE_GROWTHBOOK to turn off feature-flag checks, cross-session messaging stays off. Quietly. Plenty of privacy-conscious developers have one of these set and will spend an afternoon wondering why nothing works.

Quick diagnosis: if /list-agents is not recognized as a command, your session does not have the feature. If it runs but a message did not arrive, the feature is on and something narrower blocked it.

Real reception on availability (Aug 7 to 8): Multiple distinct users immediately flagged the native Windows gap. @windowsforum posted that cross-session teamwork arrives in v2.1.224 but stays macOS and Linux only. Others echoed the same point in Japanese and English threads under the announcement. Enterprise provider restrictions appear mainly in the docs rather than in widespread public complaints so far; the feature is only hours old. The four environment variables that silently disable it are documented, though early public reports of people tripping over them are sparse.

The problem it solves

Anyone running more than two Claude Code sessions knows this pain.

You have one session migrating a database. Another building the API that depends on it. A third writing tests against both. The migration session decides to rename a column. The API session has no idea. It keeps building against a name that no longer exists.

You find out twenty minutes later when something breaks.

Until yesterday, the fix was you. You read the first session's output, understood it, switched terminals, retyped the important part, and hit enter. You were a human message bus. Slow, lossy, and easy to forget when you are deep in something else.

This was an open feature request on Claude Code's issue tracker. Issue #36181, opened on March 19, 2026 and now closed, describes the problem in almost exactly these words: a library in Terminal A, a consuming app in Terminal B, and a human forced to manually relay updates between two agents that could coordinate directly. The filer called it agent-to-agent messaging at the CLI session level and noted it was common in monorepos and microservice architectures. A related request made the same case for orchestrator and worker workflows.

Anthropic's own framing is that the receiving session picks the message up mid-task, so the correction lands before you notice the problem.

The limits nobody is reading

The documentation is unusually honest about the boundaries. They are worth reading properly.

Plain text only. No structured data, no files, no attachments, no context transfer. If you need to move a whole conversation, you resume the session instead. Messaging is not a context-sharing mechanism and was never designed to be one.

A message is not consent. A message from another session can never approve a pending permission prompt on your behalf. This is the single most important safety line in the whole design. If session A has been denied permission to delete a directory, it cannot ask session B to do it instead. Claude is explicitly instructed to route that work back to you.

It cannot change your configuration. No editing permission settings, no rewriting CLAUDE.md, no changing anything about how the receiving session behaves.

Commands do not run. If a message contains something like /compact, it arrives as plain text. Claude Code will not execute it.

Permission prompts still fire. If acting on a message needs a permission the receiving session does not have, you get the same prompt you always would.

Loops are throttled by design. Claude Code rate-limits repeated messages from the same sender, drops identical repeats arriving close together, and caps waiting messages at 50 per session. Two sessions cannot talk each other into an infinite loop. It stops on its own.

Held messages expire. When a message gets held for your approval, a dialog opens. Leave it unanswered for five minutes (the default) and the message is dropped. Silently. At most 100 messages can sit in the held queue before the oldest start falling off.

The new problems it introduces

Every feature that removes friction adds something else. Here is what this one adds.

1. You did not write the message

This is the real one, and it is what a lot of the pushback is actually about even when people phrase it as something else.

When you copy-paste between terminals, you decide exactly what crosses. You are the filter. You drop the noise, keep the signal, and phrase the important part yourself.

Now Claude phrases it. The documentation is upfront that what gets sent varies. Two identical prompts can produce two different messages.

If the summary drops the one detail that mattered, the receiving session confidently proceeds on incomplete information. You will not see the message until after it has been read, collapsed into a one-line row in the transcript that you have to press Ctrl+O to expand.

Nobody is going to expand those rows. Be honest.

2. The waiting

Delivery is not instant in the way people expect. If the receiving session is running a long test suite, your message sits until the current tool call finishes. That is the correct engineering decision, but it means "I told the other session" and "the other session knows" are two different moments, and you cannot see the gap.

Worse: if the message got held rather than delivered, and you are not looking at that terminal, the five-minute expiry runs out and the message vanishes. You think you communicated. You did not.

3. The token bill is bigger than it looks

The obvious cost is the message itself. A few dozen tokens. Nothing.

That is not where the money goes.

A delivered message counts toward your usage exactly like a prompt you typed yourself. And a prompt does not cost you the length of the prompt. It costs you a full turn: the entire context window of the receiving session gets processed, plus whatever thinking and tool calls the message triggers.

So a 20-token message landing in a session that has 400,000 tokens of accumulated context and is running a high-effort model does not cost 20 tokens. It costs a full turn on a large context at a high effort level.

Now multiply that by five sessions coordinating during a refactor. This is the part that will show up on people's usage dashboards, and they will not immediately understand why.

The mitigation is boring but real: message sparingly, keep target sessions lean, and do not build workflows where sessions chat continuously.

Early reception on usage and delivery (Aug 7 to 8): Hard public numbers are still scarce because the feature is brand new. One user reported running 12 experiments across 5 sessions and sending 54 cross-session messages, noting that success means queued rather than delivered, that back-to-back duplicates collapse silently, and that receivers cannot see messages held from them. Other posts flag held and expired messages, and the permission-mode pairing rules: matched modes deliver more readily, while bypass sessions often hold inbound messages. No widespread usage-limit screenshots yet, but the full-turn cost structure is inherent to how Claude sessions work.

4. The model mismatch nobody has mentioned yet

Covered fully below, because it needs its own section.

"Can two different projects talk to each other?"

Yes. And this is one of the more useful things about it.

People assume the boundary is the project or the repository. It is not.

The boundary is the filesystem. Sessions find each other by reading registration files on disk. If two sessions can see the same files, they can reach each other. That means:

• Project A in one folder and Project B in a completely different folder, on the same machine? They can message each other.

• A frontend repo and a separate backend repo? Yes.

• A session inside a Docker container and a session on the host machine? No. A container has its own filesystem. They are invisible to each other.

• Two sessions both inside the same container? Yes, including on self-hosted runners.

/list-agents shows each local session's working directory precisely because sessions in different projects can end up with the same auto-generated name, and you need the folder to tell them apart.

Practical takeaway for anyone running a monorepo or a microservices setup: this works across your whole local development environment, not just within one repo.

Cross-machine is different. Sessions on your other computers, and Claude Code sessions running on the web, are reachable only through Remote Control, and only in one direction. Claude on this machine can reply to a message that arrived from one of those sessions. It cannot start the conversation. Those messages travel through Anthropic's servers, unlike same-machine messages, which never leave your computer.

If you want approval before anything leaves your machine, set isolatePeerMachines to true.

"So this is basically a group chat for Claude agents?"

A framing worth taking seriously, because the answer is instructive.

It is not a group chat. It is deliberately the opposite of one.

There is no broadcast. SendMessage delivers to one named agent. To reach three sessions, Claude sends three separate messages. Anthropic's agent teams documentation says this explicitly: to reach everyone, send one message per recipient.

There is no shared thread. Each session sees only what was sent to it. Session B does not know that session A also messaged session C.

There is no shared history. The receiving session gets the text and the sender's name. Nothing else.

And the loop throttling exists specifically to stop it becoming a chatroom. Repeated messages get rate-limited. Identical repeats get dropped. A conversation between two Claudes cannot run away from you.

A better mental model: this is a tap on the shoulder in a hallway, not a Slack channel. One person, one message, one point.

If you actually want the group-chat shape, that is a different feature. Agent teams gives you a lead session that spawns teammates who share a task list and message each other directly. It is experimental, off by default, and lives inside one session. Cross-session messaging is for independent sessions you started yourself.

"We were already doing this with markdown files and custom skills"

An objection worth addressing, and it is completely true. It is also comparing two different things.

There is a whole ecosystem of handoff tooling. Skills that compress a session into a structured markdown file for the next session to pick up. SESSION_LOG.md conventions. Context-transfer commands that write a file and hand you a one-line prompt to paste into a fresh session. Some of it is genuinely excellent.

But look at what those solve: sequential continuity. Session ends. New session starts. The file carries the context forward.

Cross-session messaging solves concurrent coordination. Both sessions are alive right now. Both are mid-task. One needs to tell the other something before it finishes.

Different problem. The documentation actually draws this line itself: if you want to move a whole conversation or its context, resume the session instead. Messaging is not for that.

Where the objection is fair: people who built live messaging systems themselves were absolutely there first. Several third-party projects shipped this before Anthropic did. claude-code-inter-session connects sessions over a local WebSocket bus. agmsg uses a shared SQLite database and works across vendors, letting Claude Code, Codex, Gemini CLI and Copilot CLI message each other. claude-sessions implements file-based mailboxes with wake-on-message behavior.

So the honest framing is: the community built this first, in several incompatible ways, and Anthropic has now made one version official with permission boundaries and loop protection baked in.

For everyone who maintained a custom setup, this is a relief. It is also, for a few of them, the sound of their side project being absorbed.

Specific tools and reactions (Aug 7 to 8):

• @contentonist replied under the announcement to say they had built a version of this in June, that theirs runs on Windows too and lets sessions claim files rather than just message about them, and that the one idea worth stealing was throttling message loops plus preventing an incoming message from approving or reconfiguring anything.

• @fujibee, creator of agmsg, wrote a comparison piece the same day, then later noted mixed personal feelings: the official Claude-only version is useful, but real development still needs cross-vendor coordination, so agmsg remains relevant.

• Other mentions include worktree-agent-coordination and similar file and socket relays. Reactions range from "finally official, I can delete my hack" to "still keeping mine because it works across vendors and on Windows."

"Codex already had this"

This claim gets made, and it is mostly wrong, though not entirely unreasonable.

Here is the actual record as of now.

OpenAI Codex has real multi-agent capability: subagents that run inside one session on separate threads, /agent to switch between them, worktree isolation so parallel agents do not collide, and a mode where the CLI runs as an MCP server exposing tools to start and continue sessions programmatically. There is also Symphony, an open-source orchestrator that turns a project board into a control plane for Codex agents.

What Codex does not have is peer messaging between two independently started sessions. Open two terminals, run codex in each, and those two sessions know nothing about each other. Coordination happens through a parent that spawns children, or through a script you write, or through a shared workspace. Not through the sessions themselves finding and addressing each other.

Cursor CLI has Cloud Handoff, where prefixing a message with & pushes the conversation to a cloud agent you can resume elsewhere. That is a handoff, not peer messaging.

So the accurate statement is: the pattern predates this announcement, but it lived in community tools rather than in a competitor's first-party product. I could not find a major coding CLI that shipped session-to-session peer messaging as a built-in before this one.

One genuinely interesting wrinkle: Anthropic partly beat itself to it. The Claude Desktop app already had its own session-messaging tool. Issue #78706, filed on July 18, 2026 against Claude Code desktop app 2.1.209, describes a user running a coordinator session relaying findings between roughly ten concurrent local sessions, and having to click approve on every single relay. The filer explicitly acknowledged why that confirmation existed, describing it as a prompt-injection firewall: without it, a compromised session could silently puppet the others. The same issue notes that the native SendMessage tool could not address independent desktop sessions at the time, only teammates and subagents.

That tension between safety and friction is the whole design story of this feature.

Claims and corrections on X: Posts claiming Codex already had this generally get corrected in replies toward the distinction between parent and child subagents, which Codex has, and independent peer sessions that discover and message each other, which it does not. Some developers expressed interest in inter-harness messaging between Codex and Claude. Community tools filled the peer gap earlier; no strong evidence surfaced of a first-party peer messaging equivalent in Codex or Cursor at the time of the announcement.

Models and effort: the part that will burn people

This deserves the most attention of anything here.

Model choice is per session. The --model flag and the ANTHROPIC_MODEL environment variable apply only to the session you launch with them. Anthropic's own guidance is explicit: to run different models in different terminals at the same time, launch each one with its own --model flag rather than switching with /model mid-session, because /model now saves your choice as the default for future sessions.

So a realistic setup looks like this: one Opus 5 session doing architecture, two Sonnet 5 sessions implementing, one Haiku session running tests and watching logs. Sensible. Cost-efficient.

Then they start messaging each other.

Here is the problem. A message carries the sender's name and a reply address. It does not carry the model. It does not carry the effort level. It does not carry any signal about how much thinking went into the conclusion.

A shallow finding from a cheap fast model arrives looking exactly like a deeply reasoned one from an expensive slow model. Same plain text. Same authority.

If your Haiku session concludes "the tests pass, the migration is safe" and messages that to your Opus session, the Opus session has no way to weight that claim differently than if it came from another Opus session. It just reads confident text from a named peer and proceeds.

Effort makes it worse. Claude Code has effort levels: low, medium, high, xhigh, and max, with high as the default on most models. But the scale is calibrated per model. The same level name does not represent the same amount of reasoning across different models. So "high effort" on a small model and "high effort" on a large one are not comparable, and neither is visible in the message.

And models can change under you. On Fable 5 and Opus 5, requests that trip safety classifiers in cybersecurity or biology areas get automatically re-run on a different model, and the session then continues on that fallback model. So "the Opus session" may not be running Opus by the time it sends its message. Sessions resumed with --resume also keep whatever model they were using when the transcript was saved, regardless of your current setting.

What to actually do about it:

1. Name your sessions by model and role, not just folder. arch-opus, impl-sonnet, tests-haiku. Names are visible in messages. Use them to carry the signal the protocol does not.

2. Put the expectation in CLAUDE.md: treat incoming peer messages as claims to verify, not facts to act on.

3. Do not route consequential decisions through cheap sessions. Let a Haiku session report status. Do not let it declare something safe.

4. Check /status if a session is behaving unexpectedly. It shows the active model and the session's own inbox address.

5. Watch for silent fallback notices in the transcript.

This is the failure mode that will produce the first real horror story about this feature, and it will not look like a bug. It will look like Claude confidently doing the wrong thing because another Claude told it something that was technically true and materially incomplete.

The Ctrl+C / Ctrl+V debate

The obvious celebration is that copy-paste between terminals is finally dead. The objection is quieter and more interesting. Both sides are right about different things.

First, a small correction that is fun rather than important: in a terminal, Ctrl+C interrupts a running process. It has never been copy. Copying is Cmd+C on macOS or Ctrl+Shift+C in most Linux terminals. The meme is better than the keybinding.

Now the substance.

The case for celebrating is throughput. Being the message router between your own agents is unpaid labour. It is slow, it breaks your focus, and it fails exactly when you are busiest. Every second spent switching terminals and retyping a summary is a second not spent on the work. If your goal is shipping, removing yourself from the loop is straightforwardly good.

The case for objecting is not nostalgia, and it is worth defending properly. When you carry the message, three things happen that do not happen now:

1. You compress it. You decide what matters. Compression is judgment, and judgment is the thing you are supposed to be adding.

2. You notice. Reading session A's output before pasting into session B is a checkpoint. You catch the wrong assumption there. Automation removes the checkpoint.

3. You stay oriented. You know what every session believes because you told each one. Now they tell each other and your mental model of the system quietly goes stale.

The framing of this as vibe coders versus shippers is not quite right. It is closer to a question about where you want your attention to sit. If you are supervising, manual relay is the supervision. If you are executing, manual relay is overhead.

The honest answer is that it depends on blast radius. Coordinating a refactor across three worktrees? Let them talk. Coordinating something that touches production, money, or data you cannot recover? Stay in the loop, and consider setting crossSessionInbound to hold on the sessions that matter so nothing lands without your approval.

The feature supports both postures. That is the best thing about it. You can turn off receiving entirely with crossSessionInbound: refuse, or turn off sending by adding deny rules for SendMessage and ListAgents. Administrators can do both for an entire organization.

Reception on control versus speed: Early posts lean positive on the throughput win for parallel worktrees and long-running tasks. Cautionary takes focus on the risk of an incomplete or overconfident summary becoming the framing for later work. The strongest automation arguments emphasize removing the human as message bus. The strongest control arguments emphasize verification, judgment, and staying oriented on high-stakes changes. Blast-radius and prompt-injection angles appear in a minority of careful replies.

"Give us this in Claude chat, not just the terminal"

A request that came up, and it is built on a premise that needs correcting before it can be answered.

The correction first. This feature is not terminal-only. Local sessions in the Claude Desktop app's Code tab get it on macOS and Linux. And here is the detail that makes it interesting: the Desktop app already had its own way for Claude to list, read and message your other sessions. But that surface only sees sessions the desktop app itself runs. It cannot see your terminal sessions, your VS Code sessions, or your cloud sessions. Anthropic's desktop documentation illustrates the gap with an example of someone running nine terminal worktrees and two desktop sessions, where the desktop Claude reports exactly one other session.

Cross-session messaging is the layer that bridges that. It is the thing that makes desktop and terminal sessions visible to each other.

So the request is already half-granted. What people usually mean by "Claude chat" is the Chat tab, which is a different product entirely. Chat does not run agentic coding sessions, does not touch your files, and has no sessions to message. Asking for cross-session messaging there is a bit like asking your email client for keyboard shortcuts from your IDE.

Now, the take.

The instinct that power users live in the terminal is directionally right for this feature specifically, but the honest position is that nobody has the numbers. Anthropic has not published a surface-by-surface usage split for Claude Code. Anyone quoting one is guessing.

What we do have is structural evidence, and it points the same way:

• Feature gaps favour the CLI. Agent teams are CLI-only and not in Desktop. So is the dontAsk permission mode. So is scripting via --print and the Agent SDK, which Anthropic states plainly is not available in Desktop because Desktop is interactive only. Third-party provider routing is CLI-first too.

• The engineering shape is terminal-native. This feature is built on Unix domain sockets and on-disk session registration. That is why native Windows does not get it. If Desktop were the primary target, Windows would have been a hard requirement, since Desktop ships there.

• The original feature request was written in terminal language. Issue #36181 describes Terminal A and Terminal B, monorepos, and microservices.

• The community tools that solved it first were all CLI tools. Every one.

• Anthropic's own documentation example imagines nine terminal sessions and two desktop ones. That ratio is a tell about who they picture running many sessions at once.

But here is where I would push back on the simple version of the take. Anthropic is clearly not betting on the terminal exclusively. They shipped a Desktop-native session-messaging surface before this one. Desktop gets automatic worktree isolation per session, which the CLI makes you request with a flag. Desktop is where Dispatch, the iOS simulator pane, and visual diff review live.

The real read is that Anthropic is building for two different users and letting them meet in the middle. The terminal is where people run many sessions. The desktop is where people manage many sessions. Cross-session messaging is one of the first features that treats both as the same fleet.

If you want an actionable version: run whichever surface you like, but if you are coordinating more than three sessions at once, the terminal currently gives you more control over model selection per session, more scripting escape hatches, and access to agent teams if you outgrow simple messaging.

Surface requests on X: A number of replies asked for the feature in "Claude chat," Desktop, or the web product. Many of those posts conflate the Chat tab, which is non-agentic, with the Desktop Code tab, which does get the feature on supported operating systems. Clarifying replies and the docs themselves point people back to the Code tab and terminal bridge. Exact counts are noisy because the announcement thread is large, but the request is common enough that Anthropic's own docs address the desktop and terminal visibility gap.

Who should turn this on

Turn it on and use it if you:

• Regularly run three or more Claude Code sessions at once

• Work in a monorepo, or across a library and the apps that consume it

• Use git worktrees to run parallel sessions on the same repository

• Run long migrations or test suites in one session while working in another

• Currently maintain a homegrown handoff setup you would rather delete

Be careful if you:

• Run sessions in bypassPermissions mode. The default inbound rules already treat these specially, holding messages for your approval, and that is not paranoia.

• Route sessions through different models. Read the models section above twice.

• Work on anything where an incomplete summary has real consequences.

Consider turning it off if you:

• Work on a machine handling sensitive systems where any automated cross-talk needs an audit trail

• Are in an organization that has not decided its policy yet. Administrators can disable both directions centrally.

Leave it alone if you:

• Run one session at a time. This does nothing for you, costs nothing, and can be ignored entirely.

The one-paragraph version

Claude Code sessions on the same machine can now send each other short plain-text notes, so you stop being the person carrying updates between terminals. It works on macOS and Linux, in the terminal and the desktop Code tab, across different projects on the same filesystem, and only in reply-mode across machines. It cannot approve permissions, change settings, run commands, or transfer context. It is not a group chat and it is not a replacement for handoff files. The real cost is not the message but the turn it triggers in a session with a large context. The real risk is that a message from a small fast model looks identical to one from a large careful one. Name your sessions well, message sparingly, and do not let a cheap session declare anything safe.

Glossary

The feature is real, useful for concurrent multi-session work, carefully bounded on safety, and still early enough that the sharpest failure modes (model mismatch, summary quality, token cost of full turns, Windows exclusion) are only just starting to surface in public discussion. Use it deliberately.