Claude Code 2.1.224: Sessions Can Now Message Each Other

Claude Code 2.1.224 added cross-session messaging, self-hosted runners, and the removal of a 200-subagent-per-session spawn cap — three changes in one changelog entry dated August 7, 2026. Taken as three separate bullets they read like routine housekeeping. Taken together they change where Claude Code runs, who a running session can hear from, and how many agents one session is allowed to spawn. That is a different product shape than the one most teams have in their heads.

What makes the release worth more than a changelog skim is the second half of the same entry. Alongside the three capability changes sit two settings — crossSessionInbound and dialogExpiry — that exist for one reason: a message arriving into a session running with bypassed permissions is a real risk, not a hypothetical one. And a few lines further down, the same release fixed a sandbox filesystem deny rule that had been silently bypassable. Capability and counterweight, shipped on the same day.

This guide walks the release in order: what the changelog actually says and what it pointedly does not, how self-hosted environments are scoped, the mechanics of session-to-session messaging, the delivery matrix that decides whether a message is delivered, held, or refused, the one-day-later addendum in 2.1.225 that loosened cross-machine messaging, and the sandbox fix that should shape how you read the whole thing. Every version-specific claim below is anchored to the Claude Code changelog and the first-party docs.

Start with the primary text. The 2.1.224 entry describes self-hosted environments as: “Added self-hosted environments: claude self-hosted-runner turns your own machines or containers into a place Claude Code web, mobile, and desktop sessions can run, on Team and Enterprise plans.” Cross-session messaging: “Added cross-session SendMessage: Claude Code sessions can now message each other, on any of your machines, with ListAgents to discover them (macOS and Linux).” And the cap: “Removed the 200-subagent-per-session spawn cap; long-running sessions no longer refuse new agents (concurrency and depth limits still apply).”

Now the part changelog recaps routinely skip — what those lines do not say. They do not say self-hosted environments are generally available; the docs describe a public beta. They do not name any plan beyond Team and Enterprise, so Pro and Max are outside the entry. They do not mention Windows for messaging. And critically, the cap line states that concurrency and depth limits still apply without stating a single number for either. Anyone quoting a figure for the surviving limits is quoting something other than this changelog.

One dating note worth carrying through the rest of this piece. The announcement blog for self-hosted environments is dated August 6, 2026; the changelog entry that shipped the code is dated August 7; independent press coverage of cross-session messaging appeared August 8 — a one-day gap on either side. Nothing about the substance changes, but it means there is no single clean “ship date” for the three features as a group. Version-specific claims below are anchored to the changelog date.

Laid out that way, the release reads less like three features and more like one move: Claude Code acquiring the pieces a distributed system needs — execution targets, a discovery mechanism, a message channel, and a fan-out budget that no longer hard-stops. That framing is ours rather than Anthropic’s; the vendor shipped changelog bullets, not a manifesto. But they fit together too neatly to be coincidence.

The mental model that matters: self-hosted environments move execution, not inference. Repository checkouts, build artifacts, secrets, and any file a session creates or modifies stay on machines you provision. The conversation itself — prompts, responses, and tool results, which can include code Claude reads — is still sent to Anthropic for inference, and the transcript is stored so the session can be resumed from another surface. If your requirement is “no code ever reaches Anthropic,” this feature does not meet it.

The scoping is tight and worth reading before anyone builds a plan around it. Team and Enterprise plans only. Public beta. Off by default — an owner or admin has to turn on the self-hosted environments setting on the cloud environments admin page, which itself requires Claude Code on the web to be enabled for the org. Organisations using Zero Data Retention cannot use it. Repositories are checked out from GitHub only in the current beta. And model inference cannot be routed through Amazon Bedrock, Google Cloud’s Agent Platform, Microsoft Foundry, or an LLM gateway — sessions call the Anthropic API directly, authenticated with a session-scoped OAuth token the control plane issues.

Supported surfaces today are Claude Code on the web, the mobile app, the desktop app, scheduled routines, and the terminal via claude --cloud or a scripted --environment dispatch. Claude Tag, Claude Security, and Code Review sessions are not yet supported; the docs say support for those follows separately. That is a meaningful gap if your CI story runs through code review.

The isolation mechanism is worth stating precisely, because it is not what most people assume. A runner locks to one user’s account on its first claimed session and serves only that account until it drains. That is how two developers’ checked-out code is kept from mixing on shared infrastructure — account affinity, not a per-session container wipe. If your threat model assumed a fresh container per session, check that assumption against the runner lifecycle section of the docs before you design around it.

Network posture is the reassuring part. All traffic is outbound from your network; Anthropic never connects in. The runner polls the Anthropic API for work, and that poll doubles as its heartbeat. Control plane, git, and inference connections are all outbound HTTPS or SSE from the runner and its session processes, with no inbound path. For a platform team that has to justify this to a security review, that is a much easier conversation than a listening port.

Anthropic’s own framing is unusually candid about who this is for, and it is not the default recommendation. The announcement says most enterprises should prefer the hosted offering for operational simplicity with no infrastructure to run or maintain, positions self-hosted environments for teams whose network, tooling, or compliance requirements call for keeping agent execution on infrastructure they control, and adds that teams going that route should plan to staff engineering to own setup and ongoing maintenance. Read that as a staffing line item, not a footnote. If you have already looked at running Claude in your own perimeter, our earlier write-up of production patterns for self-hosted Claude sandboxes covers the operational side in more depth.

The single most important sentence in the cross-session messaging docs is the narrowest one: “A message is a piece of text one Claude writes to another, never conversation history or files.” To move a whole conversation or its context, you resume the session instead. Independent press coverage read the docs the same way — only text passes between sessions, not conversation history, files, or permissions.

That constraint is what keeps the feature comprehensible. ListAgents discovers sessions; SendMessage sends text to one. It is the same SendMessage tool Claude already uses for subagents and for agent-team teammates inside a single session — cross-session messaging is a new use of an existing tool, not a new tool. Which makes the disambiguation worth stating plainly: this article is about messaging between independent sessions you start and steer yourself, not about Claude-spawned agent teams or in-session subagents. If your interest is coordinating parallel workers rather than parallel humans, the producer-consumer patterns for coordinating parallel agents are the better starting point.

That instruction is a model-level behaviour rather than an enforcement boundary, and it is worth reading as such — it stops the obvious pattern of one session asking another to do the thing its own permission settings forbid, which is exactly the escalation path you would probe first. The hard boundaries live in the delivery logic below, not in the instruction.

Delivery has three outcomes rather than two. Delivered means the message is passed to Claude. Held means it is set aside until you approve it, or until a settings or mode change allows it. Refused means it is dropped with no delivery. Which one applies depends first on the receiving session’s crossSessionInbound setting, and — when no explicit value applies — on the permission mode class of both sender and receiver. Bypass-permissions sessions form one class; everything else, including auto mode, forms the other.

The docs state the bypass case explicitly: “The receiving session bypasses permission prompts: Claude Code holds each message for your approval. It delivers one only when the sending session identifies itself as also bypassing.” The changelog puts the same logic more tersely — messages into a bypassed session are held for your approval, and messages to other sessions auto-deliver. Cross-multiplied into the four sender and receiver combinations a team running parallel sessions will actually hit, it looks like this.

The docs describe this logic in prose across two sections plus a smaller settings table; cross-multiplying it into the four combinations is our synthesis, not a table Anthropic publishes. The useful read is the asymmetry. The gate is on the receiving side, and it is the receiver bypassing permissions — not the sender — that triggers the hold. A carefully-sandboxed sender talking to a bypassing receiver is the dangerous direction, and it is precisely the one the default catches.

The docs frame those caps explicitly as throttling — the mechanism that stops a message loop between two sessions from running away on its own. That is a candid admission about the failure mode of any agent-to-agent channel: two enthusiastic agents will ping-pong forever unless something stops them, and it is better for that something to be a documented cap than an emergent one. There is one further control worth knowing: isolatePeerMachines forces your explicit approval before any reply leaves the machine, and it holds even in bypassPermissions mode, which otherwise skips ordinary permission prompts entirely. Cross-session messaging safeguards are among the short list of checks that bypassing does not remove.

If you need the feature gone entirely, an org admin can combine a managed-settings permission deny rule for SendMessage and ListAgents with crossSessionInbound: "refuse". One caveat the docs raise themselves: this leaves no visible trace in the session’s own /status or in other sessions’ listings, so an admin has to check the setting directly to confirm it is active. A control you cannot observe from the client is a control you will eventually wonder about.

Anyone who read only the 2.1.224 entry has an incomplete picture, and the gap is exactly one day wide. As shipped in 2.1.224, cross-machine messaging was reply-only. The docs put it flatly: “Across machines, Claude can only reply. It can’t start the exchange.” A session could answer a message that arrived from one of your sessions on another machine or from Claude Code on the web, but it could not open the conversation.

2.1.225, dated August 8, 2026, partially lifted that. The entry: “SendMessage can now start a conversation with your Remote Control sessions on other machines by name (ListAgents shows them as name [ref]), instead of only replying after they message you first.” Note the scoping — Remote Control sessions specifically, addressed by name, discovered through ListAgents. It is a real loosening of the reply-only constraint, not a blanket removal of it.

One more 2.1.224 fix belongs in the same paragraph, because it affects whether you can trust what a session tells you: SendMessage had been reporting “Message sent” in cases where the write to a teammate’s inbox had actually failed. Failed deliveries are now reported as errors.

The entry is one sentence and every clause matters: “Removed the 200-subagent-per-session spawn cap; long-running sessions no longer refuse new agents (concurrency and depth limits still apply).” The problem it solves is specific — a session that runs long enough to spawn two hundred agents was hitting a wall and refusing to start new work, which is a poor failure mode for exactly the long-horizon autonomous runs the product is being pushed toward.

What the entry does not do is tell you what replaced it. The parenthetical confirms concurrency and depth limits survive; it names neither. That is an unusual amount of restraint for a changelog, and it is the single most likely place for a confident wrong number to enter circulation. We are not going to supply one. Claude Code’s concurrency and depth caps have moved more than once — we covered an earlier round of them when Claude Code put guardrails on its own agent fleets — so treat any figure you see quoted for the post-2.1.224 limits as unsourced until a changelog or docs page states it.

Buried in the same release is the line that should shape how you read everything above: “Fixed sandbox filesystem deny entries written with a trailing slash (e.g. denyRead: "~/.aws/") being silently bypassable on Linux and macOS.” Past tense. This was fixed in 2.1.224 and is not a live issue — but the shape of the bug is the lesson.

The sandbox’s filesystem layer defaults to allowing reads everywhere except explicitly denied paths, which includes credential files like ~/.aws/credentials and ~/.ssh/ unless you add them to denyRead or the dedicated credentials block. So a deny entry that silently failed to match did not produce an error, a warning, or a broken build. It produced a file that stayed readable while your config said it was denied. The failure was invisible from the side that mattered.

That is the argument for testing sandbox configuration rather than declaring it. Write the rule, then have something attempt the read and confirm it is refused. Every team that had a denyRead line with a trailing slash believed they were covered, and the config file agreed with them. We have written before about how sandbox escapes via worktrees and symlinks defeat rules that look airtight on paper, and the broader sandboxing and isolation patterns for coding agents piece covers the verification habit in more detail.

One scope boundary before anyone treats the sandbox as the answer to distributed execution: sandboxing isolates Bash subprocesses only. Read, Edit, and Write use the permission system directly, and computer use runs on the actual desktop. The docs themselves say sandboxing reduces risk but is not a complete isolation boundary. macOS uses Apple’s Seatbelt; Linux and WSL2 use bubblewrap; native Windows is not supported, which is the same platform line that constrains cross-session messaging.

“Agents can talk to each other” is a headline that invites a comparison to Google’s Agent2Agent protocol, and the comparison is worth making precisely because the two are different kinds of thing. The juxtaposition below is our framing — neither vendor draws it — but both halves are separately documented.

The honest conclusion is that Claude Code did not ship a competitor to A2A and does not appear to have tried. It shipped a same-account primitive that solves a smaller, more immediate problem: you have four sessions open across two machines and you want one to tell another something. No capability negotiation is needed because you already know what your own sessions can do. The interesting question is whether the narrow primitive stays narrow — a discovery mechanism plus a message channel plus an identity notion is most of what a protocol needs, and the 2.1.225 addressing-by-name change is a step in that direction rather than away from it.

The release lands a week before Claude Code’s permission defaults change, which is not a coincidence a team should ignore: from August 14, new sessions on Pro, Max and Team run in auto mode by default, which we cover in Claude Code’s permission-model default flip. Auto mode sits in the non-bypassing class for delivery purposes, so it does not change the hold behaviour — but a fleet whose default posture is shifting is a fleet worth auditing before you add a message channel to it. The parallel-execution story is also moving: the worktree-isolation pattern every agent CLI converged on is the other half of running several agents at once without them standing on each other.

Looking forward, the thing to watch is not whether more sessions can talk to each other — that direction is now obvious. It is whether the observability catches up. A distributed system with an unpublished concurrency limit and a control that leaves no trace in /status is a system that will be operationally hard to reason about at scale. The safeguards Anthropic shipped are thoughtful; what is thin so far is the instrumentation that would let a platform team prove any of them are working. If you are formalising how agent fleets get governed inside your organisation, that gap is where the policy work goes, and it is the starting point for most of our AI and digital transformation engagements.