Claude Code 2.1.224: Self-Hosted Runner Creates a Third Execution Tier — What Operators Must Decide Now

Claude Code 2.1.224 ships self-hosted runner, cross-session messaging, subagent cap removal, and sandbox credential masking. Each one changes a different part of your operator architecture.

TheRouter Newsroomvia Anthropic Claude Code
Abstract diagram of a three-tier compute routing architecture with self-hosted runner as the new middle path

Claude Code 2.1.224 landed with more operator-facing surface area than any single release in recent months. The headline feature — claude self-hosted-runner — is not just a deployment option. It establishes a third compute tier that sits between Anthropic-hosted cloud execution and fully self-managed API-only deployments, and that tiering decision has downstream effects on routing, cost, credential isolation, and governance that teams need to work through before rolling out.

What changed

Self-hosted runner. claude self-hosted-runner turns any machine or container into a target for Claude Code web, mobile, and desktop cloud sessions on Team and Enterprise plans. The model still calls home to Anthropic for the inference, but the execution — file access, shell, MCP tools, network policy — runs on your compute. The official docs have a quickstart and a reference.

Cross-session messaging. Sessions can now send messages to other Claude Code sessions — on any of your machines — via SendMessage, with ListAgents to discover active sessions. A new pair of managed settings controls the permission model: crossSessionInbound determines how messages sent to a session running with bypassed permissions are handled (they are held for approval), and dialogExpiry sets the auto-delivery window for sessions without bypassed permissions.

Subagent cap removed. The 200-subagent-per-session spawn cap is gone. Concurrency and depth limits still apply, but long-running sessions no longer hit a hard ceiling and start refusing new agents.

Sandbox credential masking. Three new extraction modes for credential masking in sandbox environments: extract/onExtractNoMatch for structured env values, decode: "jwt" with maskClaims for JWT-aware masking, and awsPairs/sigv4 for AWS SigV4 re-signing. These are only honored from user, managed, or --settings settings and require network.tlsTerminate.

ANTHROPIC_BEDROCK_REGION_PREFIX controls which cross-region inference profile Bedrock picks, overriding the AWS_REGION-derived default. Previously there was no operator-level knob for this without changing the env region.

Archive plugin source. Plugins can now be installed from a zip over HTTPS with optional SHA-256 pinning — no git remote, no npm registry required. This matters for air-gapped or locked-down environments.

The three-tier execution decision

Before 2.1.224, Claude Code enterprise deployments fell into two buckets: Anthropic-hosted cloud sessions (fast setup, less control) or API-only with Bedrock, Vertex AI, or Azure Foundry (full infra control, no Anthropic-managed session features). Self-hosted runner creates a middle path: Anthropic-managed session UX — web, mobile, and desktop remote control — but with execution on your own machines.

The decision tree for operators:

Execution tierCompute ownerSession featuresCredential exposurePlan requirement
Anthropic cloudAnthropicFullAnthropic-hostedTeam / Enterprise
Self-hosted runnerYouFullYour infraTeam / Enterprise
Bedrock / Vertex / FoundryCloud providerAPI onlyProvider-managedEnterprise (API-level)

For teams that need session-level features — remote control, mobile approval flows, cross-session messaging — but cannot let execution leave their VPC, self-hosted runner is now the path. For teams already on Bedrock for compliance reasons, it is worth asking whether session features matter enough to add a runner deployment.

Cross-session messaging and the agent mesh topology

SendMessage + ListAgents is a distributed agent mesh in embryonic form. One Claude Code session can now discover and message another session on any connected machine. The crossSessionInbound + dialogExpiry settings are the operator governance controls for this surface.

The risk surface: a session running with allowedTools: ["*"] or bypassed permissions could receive a cross-session message that triggers tool calls. The new behavior holds such messages for explicit approval when crossSessionInbound is configured. Operators building multi-agent pipelines on Claude Code need to audit their managed settings to understand how inbound messages interact with their current permission configuration.

Subagent cap removal: what changes for cost modeling

The previous 200-subagent ceiling was a soft backstop for runaway sessions. Its removal means long-running batch pipelines no longer fail at the count boundary — but concurrency and depth limits remain, so the actual throughput ceiling has not changed. What has changed is predictability: cost models that assumed a hard termination at 200 subagents need updating. Sessions that were previously capped and retried may now run to completion, incurring more tokens.

Sandbox credential masking for gateway operators

The SigV4 re-signing capability (awsPairs/sigv4) is particularly relevant for teams running Claude Code sessions through an AI gateway that terminates TLS. It allows the sandbox to re-sign AWS API calls with controlled credentials rather than exposing raw AWS keys to the session environment. The requirement for network.tlsTerminate in the settings chain means this only activates on the intended path.

What to watch

  • Self-hosted runner docs are at code.claude.com/docs/en/self-hosted-environments* — review the reference page for the full --runner-url and runner process parameters before deploying.
  • Cross-session messaging (SendMessage / ListAgents) is macOS and Linux only in this release.
  • The archive plugin source with SHA-256 pinning (archive:// scheme) enables plugin distribution in environments without git or npm access.
  • ANTHROPIC_BEDROCK_REGION_PREFIX is the new knob for teams that need to pin Bedrock cross-region inference profiles without changing AWS_REGION.
Help & contact