Suas sessões do Claude Code agora rodam na sua máquina: guia do self-hosted-runner (e o que ainda sai da Anthropic)
A Anthropic publicou hoje, 7 de agosto de 2026, o Claude Code 2.1.224, e o destaque do release é um único subcomando:
claude self-hosted-runnertransforma suas próprias máquinas ou containers em um lugar onde sessões de Claude Code web, mobile e desktop podem rodar, em planos Team e Enterprise
A ideia vem direto dos self-hosted runners de CI, e funciona igual. Você executa um processo em um host dentro da sua rede. Esse processo se registra contra um “environment” que você cria na configuração de administração do claude.ai, faz polling na Anthropic procurando trabalho na fila, clona o repo e levanta um processo filho do Claude Code no seu hardware. Quando um dev inicia uma cloud session — a partir do claude.ai, do app mobile ou desktop, de uma rotina agendada, ou do terminal com claude --cloud — o environment picker agora lista seu environment junto aos da Anthropic.
Antes de configurar qualquer coisa, convém ser preciso sobre o que se move e o que não, porque o nome convida a uma suposição equivocada.
O que se move e o que não
O que se move é a execução da sessão. Os checkouts do repositório, os build artifacts, os secrets e qualquer arquivo que a sessão crie ou edite vivem em máquinas que você provisiona. As sessões podem alcançar serviços internos, bancos de dados e registries de dentro da sua rede, sem expô-los à internet. Você controla a imagem, então compiladores, SDKs e CLIs internos vêm pré-instalados e cada sessão arranca pronta para buildear.
O modelo não se move. A documentação da Anthropic diz isso sem rodeios: “Session content still goes to api.anthropic.com for model inference” (O conteúdo da sessão ainda vai para api.anthropic.com para inferência do modelo). Os prompts, as respostas, os resultados das ferramentas — a conversa em si — saem da sua rede por HTTPS saliente, e o transcript da sessão fica armazenado pela Anthropic para que a sessão possa ser retomada de qualquer superfície. A inferência também não pode ser roteada pelo Bedrock, Google Cloud’s Agent Platform, Microsoft Foundry nem um LLM gateway em um environment self-hosted. O control plane, a fila e a interface do claude.ai também continuam hospedados pela Anthropic.
Ou seja: isso não é uma forma de baixar sua fatura de inferência, nem uma forma de rodar Claude Code sem dependência do cloud da Anthropic. O billing não muda: as sessões self-hosted consomem o uso de Claude Code da sua organização exatamente como as hospedadas pela Anthropic. O que você ganha é controle sobre onde vive seu código enquanto o agente trabalha nele, e sobre o que o agente pode alcançar enquanto faz isso.
Há algo mais que convém saber antes de planejar um rollout, e é o lado mais notório do release: os environments self-hosted não estão disponíveis para organizações com Zero Data Retention ativado. Os times cuja postura de compliance aponta mais obviamente para o self-hosting são, por enquanto, os que ficam excluídos.
Todas as conexões são salientes. A Anthropic nunca se conecta para dentro da sua rede.
Pré-requisitos
Do lado do claude.ai:
- Plano Team ou Enterprise. É um public beta e vem desativado por padrão: um Owner ou admin precisa ativar Allow self-hosted environments na página de administração Cloud environments, e Claude Code on the web precisa estar habilitado para a organização. O botão New não aparece até que esse toggle esteja ativado. Se você não tem o role, alguém que tem pode criar o environment e passar o secret para você — os passos do runner não precisam de nenhum role no claude.ai.
- Uma conexão do GitHub para sua organização, para que os devs possam escolher repositórios. As sessões fazem checkout a partir do GitHub.
Do lado do host:
- Linux ou macOS, com HTTPS saliente para
api.anthropic.come para seu git host. Windows não é suportado como runner host; execute em um container Linux. As workstations dos devs não são afetadas — as sessões arrancam do browser. - Um relógio sincronizado com a hora real. A autenticação falha com mais de cinco minutos de desfase, e é um caso comum o suficiente para ser o primeiro item da lista de troubleshooting.
- Claude Code 2.1.224 ou superior, e Git 2.24 ou superior.
Verifique a versão primeiro, porque o modo de falha é confuso:
claude self-hosted-runner --help
Um host pronto imprime o texto de uso do runner, com flags como --environment-secret-file. Em qualquer versão anterior a 2.1.224 imprime a saída genérica de claude --help. A mesma armadilha se aplica ao setup guiado mais abaixo: em uma versão antiga, claude self-hosted-runner setup arranca uma sessão normal do Claude usando essas palavras como prompt.
Tenha em mente que o canal de instalação latest traz cada release assim que é publicado, enquanto o canal stable, o cask do Homebrew e os repos estáveis do apt, dnf e apk vêm com mais ou menos uma semana de atraso. Hoje, isso importa.
O caminho rápido
Há um setup guiado que cria o environment, levanta um runner local, confirma que foi registrado e escreve um cheat sheet em ./runner-setup/CHEAT-SHEET.md:
claude self-hosted-runner setup
Execute em uma máquina onde você iniciou sessão com claude auth login sob uma conta com role de Owner ou admin. Não funciona com API keys nem com provedores de modelo de terceiros, e precisa de uma sessão interativa.
O caminho manual
Quatro passos.
1. Crie o environment. Na página de administração Cloud environments, sob Self-hosted environments, clique em New, dê um nome e Create. No segundo passo do wizard, Copy environment key. Esse é o environment secret, que é mostrado uma única vez e não pode ser recuperado depois; expira 365 dias após sua criação. O ID ccpool_... do environment fica visível em seu diálogo de detalhes.
2. Levante um runner. Escreva o secret em um arquivo sem que fique no histórico do shell:
mkdir -p /etc/claude
(umask 077 && cat > /etc/claude/environment-secret)
Cole o valor, Enter, Ctrl-D. O umask do subshell deixa o arquivo legível apenas por seu dono.
Depois crie um base directory que o usuário do runner realmente possa escrever, e levante o runner:
mkdir -p '<writable-dir>```
claude self-hosted-runner \
--environment-secret-file '/etc/claude/environment-secret' \
--base-dir '<writable-dir>'
Sem --base-dir o padrão é /workspace, que só funciona se já existir e for gravável, ou se o runner rodar como root. Isso é chato: o runner não verifica o diretório ao iniciar, então um base dir mal configurado aparece depois como sessões que falham assim que são atribuídas, com EACCES, e não como um erro de inicialização.
3. Verifique se foi registrado. O estado do environment muda de No runners deployed para Healthy em poucos segundos, e a aba Activity mostra o runner.
4. Roteie uma sessão. Inicie uma sessão em claude.ai/code e escolha seu environment. O runner clona com as credenciais de git que o host já tem, então para esta primeira execução escolha um repo público ou um que o host já possa clonar. O runner registra Picked up session <session-id> junto com sua contagem de sessões ativas e capacidade, então você pode confirmar pela saída do próprio host qual máquina assumiu o trabalho.
Para enviar um follow-up de qualquer máquina onde você esteja autenticado:
claude -p "your message" --cloud <session-id>
Três comportamentos que vão te surpreender
O runner sai de propósito. Por padrão (--drain-grace-sec 0) sai assim que suas sessões ativas terminam, sem continuar fazendo polling. Não é um crash — é assim mesmo para que seu orquestrador o reinicie com um disco limpo. No quickstart você o reinicia manualmente; em produção você o executa em Kubernetes ou equivalente.
Um runner atende um usuário por vez. A primeira sessão que um runner assume o bloqueia na conta desse usuário, e de lá executa apenas sessões dessa conta até o limite de --capacity. Isso é o que evita que o código verificado se misture entre usuários, e tem uma consequência direta de dimensionamento: o tamanho mínimo de sua frota é a quantidade de usuários que você espera ativos ao mesmo tempo. --capacity compra paralelismo dentro das sessões de um usuário, não entre usuários. Quando há sessões enfileiradas com runners online, essa costuma ser a razão.
O dispatch é em nível de organização. Qualquer membro de sua organização da Anthropic pode enviar uma sessão para qualquer um de seus environments — não há controle de acesso por environment no dispatch. Trate cada host runner como alcançável para execução de código por qualquer membro da organização, e não coloque dados ou credenciais em um que algum membro não deveria poder ler.
Antes de apontá-lo para algo real
O quickstart é deliberadamente o mínimo que funciona. A checklist de produção é outro documento, e vários de seus itens não são óbvios:
- Containers efêmeros por sessão,
--capacity 1, sem reutilizar filesystem entre contas. - Nenhuma credencial ampla na imagem — uma credencial inserida em uma imagem de runner compartilhada fica disponível para cada sessão que executa para cada membro da organização. Gere tokens de vida curta por sessão a partir de um script wrapper, ou use
--use-anthropic-git-proxy, que clona com o token de vida curta da própria sessão e não precisa de nenhuma credencial de git na imagem. - Egress padrão-deny na sua borda de rede. O código da sessão é direcionado pelo modelo e
Bashvem pré-aprovado por padrão, então a saída por shell executa sem pedir permissão. O produto não pode forçar isso para você. - Bloqueie o endpoint de metadata da nuvem (
169.254.169.254) de dentro do container da sessão — as políticas em nível de subnet não interceptam tráfego link-local. - Em uma frota fixa, o segredo do environment vive em cada host runner, onde o código de qualquer sessão pode lê-lo. Os runners sob demanda o mantêm em um host orquestrador que nunca executa código de usuário.
E uma limitação que pertence ao mesmo parágrafo que a pergunta de residência: o tráfego dos connectors sai de sua rede. GitHub, Slack, Linear e o resto dos connectors de claude.ai são chamados do lado da Anthropic, não do seu runner. Se o tráfego de ferramentas precisa ficar dentro de sua borda, execute os equivalentes como servidores MCP locais em sua imagem, ou filtre os connectors com allowedMcpServers / deniedMcpServers.
Vale a pena?
Se seu time não usa cloud sessions, não há nada aqui para você — as sessões de terminal e IDE sempre rodaram em sua própria máquina. Se o que você quer é ter uma máquina sempre ligada gerenciada de outros dispositivos, isso é Remote Control, e funciona também em Pro e Max.
O self-hosting é para times cujos requisitos de rede, tooling ou compliance tornam a localização de execução da sessão uma restrição real, e custa a você uma carga operacional concreta: você constrói a imagem, você executa a frota, você controla seu egress. O resumo honesto é que move seu código e seu build, não sua conversa.
E você? Executar o agente na sua própria infraestrutura mudaria a resposta para um repo que hoje você não colocaria em uma cloud session — ou o que realmente importa é que o prompt saia da rede?