skip to content
All posts
5 min read

Written by AI agents, curated and verified by me.

Claude Code on your own compute: execution moves back inside, the transcript does not

  • Coding Agents
  • Agentic Engineering
  • Verification
  • Claude

On 6 August, Anthropic announced self-hosted environments for Claude Code, in public beta. A session you start from the web, mobile, desktop, or a routine no longer runs on Anthropic-hosted infrastructure. It runs inside your network, next to your internal services, toolchains, and security controls. My thesis: execution moves back behind your network boundary, the conversation does not. If you read this announcement as a data protection solution, you skipped the section on data handling.

What are self-hosted environments?

They let you run Claude Code sessions on compute you provision yourself instead of on infrastructure Anthropic operates. You still start the session from whichever surface you prefer. What sits on your side afterwards is the process that reads files, runs commands, and writes changes.

Anthropic names three reasons organisations in the preview programme adopted it. Network access: sessions run inside your network and can reach internal services, databases, and registries without exposing them to the public internet. Customisability: you pre-install compilers, SDKs, and internal CLIs so every session starts ready to build. Compliance: source code and build artifacts stay on infrastructure you control.

What stays with you and what goes to Anthropic?

Staying with you: repository checkouts, build artifacts, secrets, and any file a session creates or modifies. Going to Anthropic: the conversation itself, meaning prompts, responses, and tool results, and Anthropic states explicitly that tool results can include code Claude reads. Inference happens there, and the session transcript is stored so a session can be picked up from any surface.

That split is stated cleanly, and it is the actual core of the announcement. What moves back in-house is data at rest and access to internal systems. What still leaves the house is what the model actually saw. For a compliance assessment those are two different questions, and self-hosting answers only the first. The fact that storing the transcript is a feature here, namely continuity across devices, does not make it smaller. I made the same point about the Global Workspace: the transcript is not the whole run, but it is the part that leaves your network.

How does it work?

You deploy a set of runners. These are long-lived processes that pick up sessions and start a Claude Code process for each one. Two modes are on offer. Fixed: you keep a set number running and sessions are distributed across them. On-demand: an orchestrator watches for queued sessions, starts a runner as sessions arrive, and stops them when the work finishes.

A runner can serve more than one session, but each session runs in its own checkout, so work stays isolated between developers and accounts. Sessions from every supported surface route into the same environment, so you set it up once.

Anthropic draws an explicit line to Remote Control. There, developers continue a session running on their own machine from a phone or browser. That session ends when the machine stops running it, and it is tied to the user who ran claude. Self-hosted environments run on shared infrastructure operated by a platform team and can be used by any user. That is the difference between a laptop left running and a service somebody owns.

Who is it for?

Notably direct: Anthropic still strongly recommends the hosted offering for most enterprises, for operational simplicity, with no infrastructure to run or maintain. Self-hosted environments are for teams whose network, tooling, or compliance requirements call for keeping agent execution on infrastructure they control. Take that route, and you should plan to staff engineering for it.

The announcement is concrete about what that means: a platform, developer experience, or developer productivity team owns setup and ongoing operation, including building and maintaining the runner image, updating runners, and running the orchestrator if you use on-demand mode. This is not a configuration toggle. It is a system service with an on-call rotation behind it.

The public beta is available to organisations on Claude Team and Enterprise plans. It is off by default, and it is not available for organisations using zero data retention. That last restriction is the most instructive sentence in the announcement. If your compliance requirement is that nothing gets stored, then your own compute does not meet it, because the transcript is still stored.

One customer appears in the announcement. George Jacob, Senior Engineering Manager, describes the setup like this: Claude generates PRs, helps fix CI issues, and responds to developer workflow events, with compute that scales based on demand. That is a precise use case, and it is also where I would look twice. An agent that reacts to workflow events does work at moments when nobody just started it.

What does this mean for your work?

First, the benefit is the access, and the access is the risk. An agent that reaches internal services, databases, and registries without those being exposed to the public internet is useful for exactly that reason. It also reaches them on a run that goes wrong. If you roll this out, scoped credentials per environment, a narrow network segment, and a clear blast radius belong in the rollout, not in a later phase.

Second, read the data statement for what it says. You gain control over checkouts, artifacts, and secrets. You do not gain control over which code ends up in the conversation as a tool result. When you take this to your privacy or security people, that is the distinction to get right before anyone switches the beta on.

Third, the direction is worth noting. With managed agents execution moved to the vendor; here it moves to the customer. Both take it off the developer’s laptop, and neither changes the question of who checks the result. That is the line in agentic engineering: reliability lives in the architecture, not in the location of execution. A runner in your data centre is one piece of that architecture. Reviewing the diff stays with the person who is answerable for it.

Sources