Claude Code Self-Hosted Runner — Not a True On-Prem

Anthropic shipped two enterprise-facing features this week. Claude Code v2.1.224 brought a self-hosted runner in public beta on August 7, and a parallel Compliance API expansion now covers Cowork and Claude Code sessions. Security teams at regulated shops will read “self-hosted” and assume they finally have on-prem Claude. They are wrong — and that misread will generate audit findings before Q4.

TL;DR

• What: Claude Code’s self-hosted runner executes code on your infrastructure, but prompts, responses, tool results, and session transcripts still route to Anthropic for inference and retention
• Compliance API: Now covers Cowork (desktop, web, mobile) and Claude Code (CLI, desktop app) — but only for Claude Enterprise beta, and ZDR orgs are excluded
• Gap: Claude Code on the web, Claude Code via Claude Platform, and sessions on Bedrock, Vertex AI, and Microsoft Foundry are not covered
• Action: Do not present self-hosted runner to auditors as an on-prem deployment — it is not one

Self-Hosted Runner — What Happened

The claude self-hosted-runner command, available on Team and Enterprise plans, moves code execution onto machines you control. Your repo checkouts, secrets, and build artifacts never leave your network. Two modes ship out of the gate: fixed mode maintains a set number of runners with sessions distributed across them, and on-demand mode watches for queued sessions, spins up a runner when work arrives, and shuts it down when the queue empties.

The feature is off by default. An administrator must explicitly enable it. This is a reasonable gate — but it also signals that Anthropic knows the operational burden is real and does not want support tickets from teams who flipped a switch without understanding what they signed up for.

Self-hosted environments are not available for organizations using zero data retention (ZDR). The exact compliance posture most regulated enterprises adopt is the one that cannot use this feature.

Here is the part that matters: “self-hosted” describes where your code runs, not where your conversations go. Every prompt, every model response, every tool result that may contain code read by Claude, and every session transcript still routes to api.anthropic.com for inference and is retained by Anthropic. Session transcripts are stored so work can be resumed from different supported devices and applications. Your build artifacts stay home. Your intellectual context does not.

Why This Matters

The naming is technically accurate and practically misleading. When a CISO at a bank hears “self-hosted,” they picture an air-gapped deployment where nothing leaves the perimeter. What Anthropic delivered is a split architecture: execution is local, inference is cloud. That is a legitimate design — but it solves a different problem than the one “self-hosted” implies to a compliance audience.

This creates a specific audit risk. A team presents the self-hosted runner to their InfoSec review board as the solution that keeps sensitive data off third-party infrastructure. The board approves. Six months later, an auditor discovers that prompts containing proprietary source code, architectural decisions, and internal API schemas have been transiting to and stored on Anthropic’s servers the entire time. The finding is not that the tool is insecure — it is that the team misrepresented the data flow. That is a credibility problem, and credibility problems in compliance are harder to fix than technical ones.

The ZDR exclusion compounds this. Organizations that have negotiated zero data retention with Anthropic — the posture that SOC 2 Type II auditors and FedRAMP assessors expect from vendors handling sensitive data — cannot use self-hosted environments at all. The feature is available to teams that already accept Anthropic’s standard retention, meaning the teams who need the strongest data residency guarantees are precisely the ones locked out.

Before presenting self-hosted runner to an audit committee, map the full data flow: what stays on your infrastructure (code checkout, secrets, build artifacts) versus what transits to Anthropic (prompts, responses, tool results, session transcripts). Present both halves or present neither.

The operational cost is also worth flagging. Anthropic explicitly tells customers to plan on staffing engineering to own setup and ongoing maintenance — building and maintaining the runner image, updating runners, running the orchestrator for on-demand mode, handling vulnerability management, credential rotation, and capacity planning. This is not a managed service. It is infrastructure you own, with all the toil that implies. For organizations already stretched thin on platform engineering, the self-hosted runner trades one compliance concern (code leaving the network) for another (an under-maintained runner fleet with stale images and unrotated credentials).

The Compliance API expansion is the quieter but more practically useful announcement. Coverage now includes Cowork across desktop, web, and mobile, plus Claude Code in the CLI and desktop app. The new session endpoints return a consolidated, server-hosted transcript for each session — prompts, responses, tool calls, skills, and artifact content come back together in a single record. Previously, each surface was fragmented or uncovered entirely, making eDiscovery across Claude usage surfaces somewhere between painful and impossible.

But coverage has explicit holes. The beta does not include Claude Code on the web, Claude Code accessed through the Claude Platform, or sessions run on Amazon Bedrock, Google Cloud’s Vertex AI, or Microsoft Foundry. If your regulated deployment spans multiple cloud providers — and in financial services and healthcare, it almost certainly does — you still have blind spots that no amount of Compliance API calls will close.

Two halves of a compliance story, and neither half is complete. The self-hosted runner solves code residency but not data residency. The Compliance API solves audit visibility but not across all surfaces or deployment models. Together, they move the needle for Enterprise customers willing to accept the constraints. Separately, each one creates a false sense of coverage that an auditor will eventually puncture.

The Take

I want to be clear: the self-hosted runner is a genuine unlock. Financial services, healthcare, and defense teams that could not route code execution through Anthropic’s cloud now have an option. That matters. But Anthropic is playing a naming game that will cost compliance teams credibility with their InfoSec colleagues.

The responsible move for any team evaluating this feature is to build the data flow diagram before the procurement conversation. Show where code stays, show where prompts go, show what Anthropic retains and for how long. If your organization requires ZDR, stop — this feature is not for you yet, and pretending otherwise is how audit findings happen.

The Compliance API expansion deserves more attention than it will get. Unified session transcripts across Cowork and Claude Code are table stakes for eDiscovery, and the fact that they were missing until now was the real blocker for regulated adoption. The remaining gaps — web Claude Code, Platform access, and multi-cloud sessions — need to close before any enterprise can call their Claude compliance story complete.

Watch both features. Adopt neither as your compliance answer until the ZDR exclusion lifts and the Compliance API covers every surface your organization uses. Half a compliance story is not compliance — it is a liability with better marketing.

Related

• Anthropic Compliance API for Claude Platform — The first Compliance API launch and what it covered
• Anthropic Inference Hooks and the Enterprise DLP Gap — Why inference-layer data loss prevention remains unsolved
• Claude Cowork Sandbox Escape via Shared Root — The security surface these compliance features are trying to govern