Claude Code cloud sessions can run on your own hosts

Claude Code cloud sessions can be executed on infrastructure an organization operates itself, through runner processes that ship inside the standard claude binary from version 2.1.224. The path is set out in Claude's self-hosted environments quickstart, which covers creating an environment, starting one runner and routing a single test session to it.

At a glance

• An Owner has to switch on Allow self-hosted environments on the Cloud environments admin page before the New button appears, and the organization also needs a GitHub connection for repository selection.
• Runner hosts run Linux or macOS with Git 2.24 or newer and outbound HTTPS to api.anthropic.com, claude.ai and the git host; a clock off by more than five minutes breaks authentication.
• Guided setup creates the environment, starts a local runner and writes a cheat sheet to ./runner-setup/CHEAT-SHEET.md, but requires an Owner account signed in with claude auth login and refuses API keys and third-party model providers.

Self-hosting moves where session execution happens without moving the control plane: environments are still created, checked and routed from claude.ai, while the work runs on hosts the organization owns. That split appears aimed at teams whose repositories and internal systems are not reachable from Anthropic's infrastructure. The quickstart itself stops well short of that, and reads as a lab exercise rather than a deployment: one runner, one host, one session.

The runner is part of the standard claude binary from v2.1.224

The self-hosted-runner subcommand is not a separate download, and versions older than 2.1.224 do not recognise it. A ready host prints the runner's usage text, listing flags such as --environment-secret-file, while older builds print the general claude --help output instead and need an update.

Install channels differ in how quickly they carry a release. The native installer's default latest channel picks up each release as soon as it is published, while the stable channel, the Homebrew claude-code cask and the stable apt, dnf and apk repositories trail by about a week. Fleets that need an exact version are pointed to separate install instructions, and container users to a Dockerfile on the production deployment page.

Windows is not supported as a runner host

A runner host is a Linux or macOS machine or container with outbound HTTPS to api.anthropic.com, to claude.ai and the download hosts it redirects to during install, and to the git host used for clones. The full destination list sits in the network requirements table. Windows is excluded, with a Linux container given as the workaround.

Developer workstations are unaffected, since sessions start from claude.ai in a browser. The host clock has to be synchronised to real time, for example over NTP, because authentication fails once it drifts past five minutes. Git 2.24 is the floor, and some git options on the production page require newer versions.

The runner exits by design once its active sessions finish

Guided setup runs as an interactive Claude Code session and is unavailable with API keys or third-party model providers. Where the Owner role is missing, someone who holds it can create the environment and hand over its secret, since the runner and terminal steps require no claude.ai role at all. A manual sequence is documented for hosts where an interactive session is not possible.

The runner process stops when its active sessions complete, which the documentation describes as intended behaviour. Production deployments are therefore expected to run it under an orchestrator that restarts it on exit, with Kubernetes and Compose named on the deployment page.

Follow-up messages reach a running session from the claude CLI on any machine logged in with claude auth login, not only the one that started it. The command accepts a bare session_ or cse_ identifier or the session's claude.ai/code URL, and a successful send prints Sent to cloud session. together with the session ID and a view link.

Before real repositories connect the documentation directs operators to a separate production page covering the security posture, egress control, git credentials and fleet orchestration, alongside pages on wrapper scripts, lifecycle hooks, on-demand runners, MCP servers and permissions, and a CI smoke test that dispatches a session and reads Claude's replies. Pricing and plan availability for self-hosted environments are not stated in the quickstart.