Skip to content

Claude Code

Claude Code cloud sessions can run on your own hosts

4 min read

Written by an AI model from the linked sources and checked against them by a second model. How we work

All about: Claude Code versions and changes →
Image: code.claude.com

Anthropic has documented how to move Claude Code cloud sessions off its own machines and onto hardware your organization runs. Runner processes you deploy do the work, and the runner is part of the regular claude binary, so there is nothing separate to install. A September 3 quickstart in Claude’s documentation walks through the smallest setup that works: one runner on one host, running one test session.

By default a cloud session runs in an isolated VM that Anthropic manages. When you route a session to a self-hosted environment, it runs on your host instead.

The setup is split across two places. On claude.ai you create the environment, check its status and route a session to it. Everything the runner does happens in a terminal on the host. At the end you should see an environment on the Cloud environments admin page, a runner polling for work and a session running on your machine.

Permissions come first. The New button on the Cloud environments admin page stays hidden until an Owner turns on Allow self-hosted environments. The organization also needs a GitHub connection so developers can pick repositories when they start sessions. You don’t need an Owner role yourself. Someone who has one can create the environment and give you its secret, and the runner and terminal steps need no claude.ai role. Where a step tells you to check status in the admin UI, the runner’s own log lines tell you the same thing.

The host can be Linux or macOS, either a machine or a container. It needs outbound HTTPS to api.anthropic.com, to claude.ai and the download hosts it redirects to during install, and to your git host for the clone. Windows can’t be a runner host, and the docs suggest running the runner in a Linux container there. Developer workstations are not affected, because sessions start from claude.ai in a browser. The host clock has to be synced to real time, with NTP for example: if it is more than five minutes off, authentication fails.

You need Claude Code v2.1.224 or later and Git 2.24 or newer. Some git options on the production deployment page need newer Git, and the docs give the minimum version for each one. The native installer’s default latest channel gets each release as soon as it ships. The stable channel, the Homebrew claude-code cask and the stable apt, dnf and apk repositories lag by about a week. Versions older than 2.1.224 don’t recognize the self-hosted-runner subcommand.

On a host that’s ready, the runner subcommand prints its own usage text, which lists flags such as --environment-secret-file. On an older version you get the general claude --help output instead, and the fix is claude update or a reinstall from the latest channel. The guided setup command behaves differently on an old version: instead of the setup, it starts an ordinary Claude session with the words of the command as your prompt.

The guided setup is itself an interactive Claude Code session. It walks you through creating the environment in the admin UI, starts a local runner with the secret file you saved, confirms the runner has registered and writes a cheat sheet to ./runner-setup/CHEAT-SHEET.md. It has to run on a machine signed in with claude auth login using an Owner account, and it doesn’t work with API keys or third-party model providers. Where an interactive session isn’t possible, the docs give manual steps instead.

Once the runner’s active sessions finish, it exits by design. For production, the docs say to run it under an orchestrator that restarts it when it exits. The production guide covers Kubernetes and Compose, along with the security setup, egress control (limits on where the host can send traffic) and git credentials. Anthropic asks you to work through that guide before you connect real repositories or internal systems.

You can message a running session from the claude CLI on any machine signed in with claude auth login; it doesn’t have to be the machine that started the session. The command takes a bare session_... or cse_... ID, or the session’s claude.ai/code URL, and sends a single message. It works the same way against Anthropic-hosted sessions. The docs also cover wrapper scripts, lifecycle hooks, on-demand runners, MCP servers and permissions for customizing sessions, plus a CI smoke test that starts a session and reads Claude’s replies.

If the send works, the terminal prints Sent to cloud session. with the session ID and a link to view it.

No comments yet. Be the first.

Join the conversation

Sign in to leave a comment. It appears after moderation.