Claude Code agora roda sessões na infraestrutura da empresa
Dante Testa
10/08/2026 · 11 min de leitura · 61 visualizações
O que mudou em 6 de agosto
O Claude Code self-hosted entrou em beta público em 6 de agosto de 2026 para organizações nos planos Team e Enterprise. A novidade permite executar sessões remotas do agente em máquinas ou contêineres administrados pela própria empresa, dentro de sua rede e perto de registries, bancos de dados e ferramentas internas. O modelo continua sendo executado pela Anthropic: o lançamento muda o local de execução das ferramentas e dos arquivos, não transforma o Claude em um modelo instalado localmente.
Essa distinção é a parte mais importante do anúncio. A expressão “self-hosted” costuma sugerir que todos os dados e toda a computação permanecem dentro da empresa. No caso do Claude Code, checkouts do repositório, artefatos de compilação, segredos disponíveis ao processo e arquivos criados ou modificados ficam na infraestrutura provisionada pela organização. A conversa da sessão — prompts, respostas e resultados de ferramentas, que podem conter código lido pelo agente — segue para a Anthropic para inferência. O transcript também é armazenado para permitir que a mesma sessão seja retomada em outra superfície.
Em termos práticos, o beta atende uma dor específica: executar agentes próximos de serviços que não deveriam ser expostos à internet pública, com uma imagem de execução preparada pela equipe e controles de rede já conhecidos. Ele não elimina a necessidade de classificar dados, restringir credenciais nem revisar mudanças antes de levá-las a produção.
Como a arquitetura self-hosted funciona
A documentação divide o sistema em três peças. Um ambiente é o destino lógico que aparece para o usuário ao iniciar uma sessão. Cada ambiente agrupa um conjunto de runners, processos de longa duração implantados em hosts controlados pela empresa. Uma sessão é uma tarefa do Claude Code iniciada pelo desenvolvedor.
Quando alguém escolhe o ambiente self-hosted, o plano de controle da Anthropic coloca a sessão em uma fila. Um runner com capacidade disponível reivindica o trabalho, clona o repositório selecionado e abre um processo filho do Claude Code. A execução acontece no host da organização, mas o processo mantém conexões de saída para api.anthropic.com: consulta a fila, transmite os eventos da sessão e pede inferência ao modelo.
A Anthropic afirma que não inicia conexão para dentro da rede do cliente. Isso simplifica a abertura de firewall, mas não significa ausência de tráfego sensível para fora. O conteúdo enviado ao modelo deve continuar sujeito a política de dados, revisão jurídica e controles de egress.
Ilustração editorial baseada apenas nas relações técnicas descritas na documentação oficial; a composição não reproduz o diagrama da Anthropic.
Runners fixos e sob demanda
Há dois modos de operação. No modo fixo, a equipe mantém uma quantidade definida de runners ativa e distribui sessões entre eles. É simples de entender e oferece capacidade previsível, mas pode deixar máquinas ociosas ou formar fila em horários de pico.
No modo sob demanda, um orquestrador observa a fila, inicia runners quando chegam sessões e encerra a capacidade depois do trabalho. Esse desenho se aproxima do que times de plataforma já fazem com executores efêmeros de integração contínua. Ele reduz ociosidade, mas acrescenta componentes: imagem do runner, escalonamento, política de desligamento, observabilidade e tratamento de falhas.
Um runner atende apenas um usuário por vez. Depois de reivindicar a primeira sessão, ele fica vinculado àquela conta, embora possa executar mais de uma sessão desse usuário até o limite de capacidade configurado. A regra evita misturar checkouts de pessoas diferentes no mesmo espaço de execução. Na prática, a capacidade mínima precisa considerar quantos usuários estarão ativos ao mesmo tempo, não apenas o total de tarefas.
Se o runner deixar de consultar a fila por cerca de 60 segundos, a sessão é reenfileirada. Isso ajuda na recuperação, porém não dispensa armazenamento descartável, logs centralizados e uma estratégia para comandos que estavam em andamento quando o host caiu.
O que fica na empresa — e o que não fica
O ganho de controle aparece em quatro áreas.
Primeiro, o checkout nasce dentro da rede. O agente pode acessar um GitHub autorizado, compilar o projeto e escrever no diretório de trabalho sem transportar o repositório para uma máquina de execução hospedada pela Anthropic. Segundo, artefatos de build e arquivos intermediários permanecem no host. Terceiro, a empresa decide quais compiladores, SDKs e CLIs entram na imagem. Quarto, o runner pode alcançar APIs, registries e serviços internos por rotas privadas.
Há, porém, uma fronteira que não deve ser escondida no rodapé. A inferência continua na Anthropic. Trechos lidos pelo Claude, saídas de ferramentas incorporadas ao contexto, prompts e respostas atravessam a conexão de saída. Portanto, “o código permanece na nossa rede” é uma frase incompleta: o checkout permanece, mas conteúdo do código pode fazer parte das mensagens enviadas ao modelo.
Também há uma incompatibilidade expressa com organizações que usam Zero Data Retention. O beta não está disponível nesse cenário. A inferência não pode ser roteada por Amazon Bedrock, Google Cloud Agent Platform, Microsoft Foundry ou um gateway próprio de LLM. Para quem depende dessas rotas por contrato ou residência de dados, esse limite pode encerrar a avaliação antes mesmo de um piloto técnico.
Quem realmente ganha com a novidade
Self-hosting faz sentido quando o bloqueio principal está no ambiente de execução. É o caso de um monorepo que depende de pacotes em registry privado; de uma aplicação que só compila com SDK interno; de testes de integração que precisam alcançar um banco efêmero dentro da VPC; ou de uma organização que exige que artefatos não sejam produzidos fora de sua infraestrutura.
O recurso também pode reduzir a tentação de abrir serviços internos para agentes hospedados. Em vez de publicar uma API administrativa ou criar um túnel amplo, a equipe posiciona o runner onde já existem controles de rede, identidade de máquina e trilhas de auditoria.
Para a maioria das empresas, a própria Anthropic recomenda continuar na oferta hospedada. Essa recomendação é coerente: se o repositório é acessível, os testes não dependem de rede privada e não há requisito regulatório específico, assumir uma frota de runners troca simplicidade por manutenção sem entregar um benefício claro.
O critério correto não é “queremos mais controle”, frase ampla demais para orientar arquitetura. A pergunta é: qual dado, serviço ou etapa do build precisa permanecer em uma fronteira que o ambiente hospedado não atende? Se ninguém consegue nomear esse item e a exigência que o sustenta, o beta provavelmente não é prioridade.
O custo operacional que passa para o seu time
A empresa precisa construir e manter a imagem do runner. Isso inclui sistema operacional, versão do Claude Code, compiladores, ferramentas internas, certificados e agentes de observabilidade. Uma imagem velha pode carregar vulnerabilidades ou comportamento incompatível; uma atualização sem testes pode quebrar todas as sessões de uma vez.
Também é necessário definir capacidade. Runners fixos pedem dimensionamento por pico e monitoramento de fila. Runners sob demanda pedem um orquestrador confiável e regras de drenagem. Hosts interrompíveis podem reduzir custo, mas precisam encerrar sessões de forma previsível. O limite de concorrência não deve ser escolhido apenas por CPU: builds podem disputar memória, I/O, licença de ferramentas e conexões a serviços internos.
Credenciais merecem um desenho separado. O runner precisa clonar repositórios e pode acessar dependências privadas. Entregar um token amplo na imagem transforma cada sessão em um caminho de alto privilégio. Prefira credenciais de curta duração, escopo mínimo, identidade por workload e restrições de repositório. Segredos não devem sobreviver no disco depois que o runner termina.
Finalmente, o time assume observabilidade. Métricas mínimas incluem tempo de fila, tempo de preparação, duração da sessão, falha de clone, falha de inferência, uso de CPU e memória, reinícios e quantidade de sessões reenfileiradas. Logs técnicos devem ajudar a investigar incidentes sem registrar prompts ou segredos indiscriminadamente.
Um roteiro de piloto sem salto para produção
O beta pede um piloto deliberadamente pequeno. Um caminho seguro pode seguir estas etapas:
- Defina uma hipótese verificável. Exemplo: “o runner dentro da VPC permite executar a suíte de integração sem tornar o banco acessível externamente”. Evite começar com “vamos adotar agentes em toda a engenharia”.
- Escolha um repositório de baixo impacto. Use código sem dados reais de clientes, pipeline reversível e equipe que conheça os testes. Não comece por infraestrutura central ou plugin WordPress que publica diretamente em produção.
- Monte uma imagem mínima. Instale apenas ferramentas exigidas pelo projeto. Fixe versões, gere inventário de componentes e aplique a mesma revisão usada em imagens de CI.
- Restrinja rede e identidade. Libere somente os destinos necessários, mantenha saída para os endpoints documentados da Anthropic e bloqueie movimentos laterais. Separe o token de Git da identidade usada para serviços internos.
- Mantenha o merge humano. O agente pode abrir uma branch e produzir um pull request, mas proteção de branch, testes obrigatórios e aprovação continuam fora do alcance da sessão.
- Teste falhas. Interrompa um runner, expire uma credencial, provoque fila e simule um build que excede memória. O objetivo é descobrir se a sessão falha de modo compreensível e recuperável.
- Meça o benefício. Compare tempo de preparação, taxa de sucesso e carga operacional com o ambiente hospedado. Self-hosting só vence se resolver a restrição original sem criar risco desproporcional.
O impacto para Vibe Coding e WordPress com IA
Em fluxos de Vibe Coding, o ganho imediato é contexto operacional. O agente pode trabalhar no mesmo tipo de ambiente em que o software é compilado e testado, com versões controladas e dependências reais. Isso reduz diferenças entre um sandbox genérico e o pipeline da empresa. Não elimina a necessidade de especificar a tarefa, revisar o diff e validar o resultado.
Para equipes WordPress, um runner pode receber PHP, Composer, WP-CLI, Node.js e uma instalação descartável do CMS. Assim, o Claude Code pode testar migrações, executar PHPCS, validar hooks e montar um pacote sem tocar no servidor ao vivo. O desenho saudável mantém banco de produção, wp-config.php real e credenciais do painel fora do ambiente. Quando precisar de dados parecidos com produção, use amostras sanitizadas e instâncias efêmeras.
A proximidade da rede é uma vantagem e um risco ao mesmo tempo. Um agente que alcança registry interno talvez também enxergue serviços que não precisa usar. Segmentação, egress explícito e identidades diferentes por projeto são mais importantes em um runner self-hosted do que em uma estação manual, porque sessões podem durar mais e executar muitas ferramentas em sequência.
Limites que devem aparecer na decisão
O beta atende Team e Enterprise e vem desligado por padrão. Um proprietário ou administrador precisa habilitá-lo, com Claude Code na web também ativo. Sessões iniciadas pelo Claude Tag, Claude Security e Code Review ainda não usam esses ambientes. Os repositórios são obtidos do GitHub. A cobrança de uso do Claude Code permanece igual à das sessões hospedadas; a infraestrutura própria é um custo adicional da organização.
Esses limites podem mudar depois do beta, mas são as condições documentadas em 8 de agosto de 2026. Uma aprovação de arquitetura deve registrar a data da consulta e revisar novamente a documentação antes de ampliar o piloto.
O lançamento torna o Claude Code mais adaptável a empresas com redes e toolchains complexos. Seu valor não está em prometer IA “dentro de casa”. Está em colocar a execução das ferramentas onde a equipe já controla máquinas, pacotes e rotas, mantendo explícito que a inferência continua externa. Quem preservar essa fronteira conceitual conseguirá avaliar o beta com expectativas honestas.
