Claude Code 2.1.224 self-hosted environments: verify the trust boundary before rollout
Quick answer
Claude Code 2.1.224, released August 7, 2026, adds self-hosted environments for Team and Enterprise organizations. A new claude self-hosted-runner process can execute Claude Code cloud sessions on machines or containers your organization operates, including sessions started from the web, mobile, desktop, scheduled routines, or the CLI.
This is not a fully self-hosted Claude stack. Repository checkouts, build artifacts, files, and injected secrets stay on your infrastructure, but session prompts, responses, tool results, queueing, transcripts, and model inference still use Anthropic's control plane and api.anthropic.com. Anthropic makes no inbound connection to your network; runners and sessions initiate outbound connections.
Before connecting a real repository, pass seven gates: eligibility, trust-boundary acceptance, one-session runner isolation, default-deny egress, per-session credentials, verified session identity, and an end-to-end recovery test. If your goal is local inference, Zero Data Retention, Bedrock/Vertex/Foundry routing, or support for non-GitHub repositories, this public beta does not meet it today.
Who this is for
This guide is for platform teams that need cloud sessions to reach private systems or custom toolchains without moving the checkout to an Anthropic-hosted machine. Terminal and IDE sessions already run locally; Pro or Max users operating one always-on computer should evaluate Remote Control instead.
Map the hybrid trust boundary first
The most important decision is not “Can we start the runner?” but “Does this split satisfy our data and control requirements?”
| Boundary | Runs or stays on your infrastructure | Still handled by Anthropic |
|---|---|---|
| Execution | Repository checkout, commands, build artifacts, generated files, injected credentials | Session dispatch and queue control |
| Network | Access to allowlisted internal services and your git host | Outbound session stream, feature control, and model inference through api.anthropic.com
|
| Conversation | Local command side effects and files | Prompts, responses, tool results, and the resumable transcript |
| Fleet | Runner image, host IAM, filesystem, capacity, lifecycle, and monitoring | Environment registration and session leases |
| Identity | Your service decides which derived capability to grant | Anthropic signs the session JWT and identifies the creator |
Do not describe the feature as on-prem inference or a no-data-egress mode. It moves execution into your network, not the model or control plane.
A seven-gate production rollout
1. Confirm the product fits
Require Claude Code 2.1.224 or later on Linux or macOS; Windows needs a Linux container. An admin must enable the feature and Claude Code on the web. The beta excludes Zero Data Retention organizations, non-GitHub repositories, Claude Security, Code Review, Claude Tag, and inference through Bedrock, Google Cloud, Microsoft Foundry, or an LLM gateway.
2. Separate the environment secret from session code
The environment secret can register runners and claim organization work. Keep it on an orchestrator that never executes user code, then give each on-demand runner a single-use work order. If a fixed runner is exposed, rotate the secret; never bake it or broad credentials into the image.
Dispatch is organization-wide: any member can target any environment, with no per-environment ACL. Do not expose a service or credential through a runner unless every organization member may reach it.
3. Use one ephemeral runner per session
A runner locks to its first user's account, but capacity above one is not session-level isolation. Use capacity one with an ephemeral container or on-demand runner. Give it a private workspace, mount hooks and configuration read-only, and block the cloud metadata endpoint so session code cannot inherit host IAM.
4. Default-deny egress outside the product
Product permissions do not enforce network isolation for model-directed Bash. At the network layer, allow only documented Anthropic endpoints, your git host, and task-specific internal services. Keep the network allowlist and untrusted-repository sandbox checks; self-hosting changes where commands run, not whether they are safe.
5. Mint narrow credentials per session
Use Anthropic's git proxy or a checkout hook for the initial clone. Then exchange session identity for credentials scoped to one repository and required service, bound to the session ID and an expiry no later than its token. Structured secrets still need masking and injection gates.
6. Verify identity, not just possession
For CLAUDE_CODE_SESSION_ACCESS_TOKEN, verify the self-hosted prefix, ES256 signature against Anthropic's rotating JWKS, issuer ccr, environment ID in aud, role session_worker, and expiry. The token proves issuance, not which process presents it: session code can read it. Mint a smaller capability instead of granting the user's full authority.
7. Test dispatch, follow-up, failure, and resume
In a dedicated test environment, prove dispatch, the expected tool, a sentinel reply, follow-up delivery, and attribution. Stop the runner during a read-only turn and verify requeue and resume. Test unpushed-work loss explicitly. If you enable outcome push, protect claude/* refs; it preserves committed work, not a dirty working tree.
Copyable acceptance record
Environment ID and plan:
Allowed dispatch population:
Runner image digest and Claude version:
Capacity / ephemeral lifecycle:
Environment secret location and rotation owner:
Host IAM and metadata-endpoint block:
Allowed egress destinations:
Git clone and push credential path:
JWT checks and derived capability scope:
Test repository and sentinel task:
Runner-loss / resume result:
Unpushed-work behavior:
Metrics, logs, and rollback owner:
Decision: reject / test-only / limited rollout / production
Promote only when every line has runtime evidence. A configuration file is intent; runner logs, network denies, token-verification results, and a successful recovery canary are evidence.
Common mistakes
Calling it fully self-hosted. Execution is local to your infrastructure, but inference, session content, transcripts, and orchestration still cross the Anthropic boundary.
Using capacity four as isolation. Same-account concurrency does not isolate files or credentials. Use capacity one or on-demand runners.
Keeping the environment secret beside the workspace. A session compromise can become fleet registration authority; keep it on the orchestrator.
Testing only the happy path. Recovery, unpushed-work loss, and branch provenance belong in initial acceptance.
FAQ
Does this keep source code out of Anthropic infrastructure?
Checkouts and artifacts stay on the runner. Prompts, tool results, and source placed in model context still go to Anthropic.
Can a small Pro or Max account use self-hosted environments?
No. It is a Team and Enterprise public beta; Remote Control is closer for an individual always-on machine.
Can we route model calls through Bedrock or our LLM gateway?
No. These sessions use Anthropic API inference and do not support Bedrock, Google Cloud, Microsoft Foundry, or LLM gateway routing.
Top comments (0)