Contents
Anthropic shipped Claude Code v2.1.224 this week, and it quietly resolves two constraints that anyone running agents at team scale has hit: where the session actually runs, and whether separate sessions can coordinate at all. Self-hosted environments let Team and Enterprise plans move Claude Code’s web, mobile, and desktop sessions off Anthropic’s infrastructure and onto compute the organization already controls. Cross-session messaging lets one running session discover and message another, on the same machine or a different one. Anthropic also quietly removed the 200-subagent-per-session spawn cap it had only just added a few releases earlier.
None of these are flashy model announcements, but they matter more to anyone building on Claude Code than another benchmark score would, because they change what a fleet of agents is allowed to look like in a real organization.
Three changes, one underlying shift
Self-hosted environments. The new claude self-hosted-runner command turns a machine you control into a place Claude Code sessions can execute, with access to your internal network, internal tooling, and whatever compliance boundary your infrastructure team already enforces. It is off by default and scoped to Team and Enterprise plans, which tells you who it is for: regulated shops and larger engineering orgs that were fine with Claude Code’s capability but not with cloud sessions reaching services behind a VPN. Anthropic stays the control plane; you own the execution plane.
Cross-session messaging. Sessions can now find each other with a ListAgents call and exchange messages with SendMessage, across machines, on macOS and Linux. A session running with bypassed permissions holds inbound messages for manual approval rather than auto-executing them, and the new crossSessionInbound and dialogExpiry settings control how long a pending message waits before it expires. This is the piece that turns “several Claude Code sessions happen to be running” into “several Claude Code sessions can coordinate,” which is the actual bottleneck in most hand-rolled multi-agent setups I have built or reviewed. I hit this exact gap building Chi, my autoresearch harness for LLM coding agents. Chi’s fleet coordination runs through an external SQLite-backed store because there was no first-party channel for one running agent to reach another. That gap is now smaller.
The spawn cap, gone as fast as it came. Claude Code had shipped a 200-subagent-per-session cap only a couple of releases prior. It is now removed for long-running sessions, though concurrency and depth limits (nested subagents still default to depth 3) still apply. Read charitably, this looks like Anthropic shipping a conservative safety rail first, watching how real fleets actually behaved, and loosening it once the failure mode did not materialize at scale.
Try session discovery yourself
Below is a minimal simulation of what ListAgents and SendMessage return when two Claude Code sessions are running side by side. It does not call a real session; everything runs in your browser.
About the demo
This simulates the tool call shapes from the changelog, not a live connection to any session.Click "List agents" to call ListAgents().
Waiting for step 1…
Where this leaves fleet builders
If you are running more than one Claude Code session on purpose, today’s release closes a gap you have almost certainly been papering over with an external message bus, a shared file, or a human relaying updates between terminals. My own next step is smaller than a rebuild: audit where Chi’s coordination layer duplicates something SendMessage and ListAgents now do natively, and keep the parts that do more, like the durable, replayable event log Chi’s store gives you, that a point-to-point message channel deliberately does not try to solve. If your organization has been holding off on Claude Code because sessions had to run in Anthropic’s cloud, that objection is gone too, and it is worth re-opening the conversation with whoever owns that policy.