Implantar ambientes auto-hospedados em produção

​

Endurecimento de sua implantação

• Contêineres efêmeros por sessão: execute cada processo runner em um contêiner ou VM fresco que é destruído quando o processo sai, com --capacity 1 e o padrão --drain-grace-sec 0 para que cada contêiner sirva exatamente uma sessão. Em uma capacidade mais alta, ou com uma graça de drenagem positiva, um contêiner serve múltiplas sessões do mesmo owner bloqueado; consulte Ciclo de vida do Runner. Não reutilize um sistema de arquivos entre reinicializações do runner, exceto na configuração deliberada de checkout pré-aquecido, e nunca entre owners.
• Sem credenciais amplas na imagem: não inclua chaves SSH de longa duração, credenciais de provedor de nuvem ou tokens de acesso pessoal que concedem mais do que uma sessão precisa. Crie credenciais usadas durante uma sessão, como tokens de push ou API, por sessão a partir de seu script wrapper. Para o clone inicial, que acontece antes do wrapper ser executado, use um hook de ciclo de vida checkout ou --use-anthropic-git-proxy; consulte Configurar git.
• Mantenha o segredo do ambiente fora dos hosts que executam sessões: o segredo do ambiente pode registrar runners e pegar qualquer sessão enfileirada no ambiente. Em uma frota fixa, ele vive em cada host runner, onde o código de qualquer sessão pode ler o arquivo secreto. Prefira runners sob demanda, onde o segredo fica no host do orquestrador, que nunca executa código do usuário, e cada runner recebe uma ordem de trabalho de uso único que registra exatamente um runner. Em uma frota fixa, trate o arquivo environment-secret como legível por cada sessão e gire o segredo após qualquer suspeita de comprometimento de sessão.
• Saída de rede padrão-negar: restrinja o tráfego de saída do contêiner runner e sessão no seu próprio limite de rede em cada ambiente; Saída padrão-negar cobre o que permitir e por quê.
• IAM de host com privilégio mínimo: a identidade de computação anexada ao host runner, como um perfil de instância ou conta de serviço de nó, deve conceder apenas o que o próprio runner precisa. As sessões devem obter suas próprias credenciais através de seu script wrapper em vez de herdar a do host.
• Bloqueie o endpoint de metadados da nuvem das sessões: manter as sessões fora da identidade do host requer bloquear seu acesso ao endpoint de metadados, e as políticas de saída no nível de sub-rede não interceptam o tráfego de metadados link-local, então bloqueie-o no próprio contêiner:
  • IMDSv2 com um limite de salto de um
  • GKE Workload Identity com ocultação de metadados
  • Uma negação explícita para 169.254.169.254 no namespace de rede do contêiner da sessão
  O bloqueio se aplica ao seu script wrapper e hooks de ciclo de vida também, já que compartilham o contêiner. Autentique qualquer troca de token com o JWT da sessão contra seu próprio serviço de token sobre saída na lista de permissões, ou use uma identidade web baseada em arquivo, como IAM Roles for Service Accounts (IRSA) no Amazon EKS.
• Isolamento de sistema de arquivos por runner: cada processo runner obtém seu próprio diretório de trabalho que nenhum outro processo no host pode ler ou escrever. Faça --hooks-dir, o script wrapper, e o ~/.claude/ do host somente leitura para a sessão, seja construído na imagem ou montado como somente leitura.
• Dispatch não tem controle de acesso por ambiente: qualquer membro de sua organização Anthropic pode enviar uma sessão para qualquer um de seus ambientes. Se um Owner rotear canais Claude Tag para o ambiente, qualquer pessoa que a configuração de acesso Claude Tag admita pode iniciar sessões de canal que são executadas lá. Por padrão, isso é qualquer pessoa no workspace Slack conectado, com ou sem uma conta Claude. Trate cada host runner como alcançável para execução de código por todos que podem enviar para ele, e coloque no host runner apenas dados e credenciais que todas essas pessoas têm permissão para ler. --lock-to-account limita qual conta as sessões de um determinado host executam, mas não reduz quem pode enviar para o ambiente. Para tornar ambientes auto-hospedados a única opção de seletor, um Owner pode ocultar ambientes hospedados pela Anthropic para toda a organização na página Cloud environments.
• Enforce the repo-settings guard: escolha o modo de guard com --confine-repo-settings. O padrão warn registra uma violação e ainda assim gera a sessão, enforce recusa a sessão, e off desabilita a varredura. O runner verifica as configurações confirmadas de cada repositório para:
  • Uma concessão que se resolve fora do workspace da própria sessão: uma entrada additionalDirectories, uma regra Edit, Write, ou NotebookEdit em permissions.allow, ou uma entrada sandbox.filesystem.allowWrite ou allowRead
  • Um bloco env não vazio
  • Uma substituição de postura do operador, como sandbox.enabled: false
  O guard é executado independentemente de --trust-workspace, e não cobre hooks de repositório, .mcp.json, ou regras Bash; consulte Permissões e aprovação de ferramentas para onde essas concessões pertencem.

​

Requisitos de rede

​

Saída padrão-negar

​

Autenticar em um proxy de saída

​

Escolha de onde o valor Proxy-Authorization vem

• --proxy-authorization-command <command>: escolha isso para um token que você gera sob demanda. O runner executa o comando shell e usa sua stdout aparada como o valor do cabeçalho, por exemplo Bearer <token>.
• --proxy-authorization-file <path>: escolha isso para um token que outro processo gira no lugar. O runner lê o arquivo e usa seu conteúdo aparado como o valor do cabeçalho.

​

Configurações que o runner se recusa a iniciar com

• Ambos os sinalizadores definidos: um sinalizador mais a variável de ambiente do outro sinalizador conta como definir ambos.
• Nenhuma URL de proxy: nem HTTPS_PROXY nem HTTP_PROXY contém uma URL http:// ou https://. O runner lê ambas as variáveis em maiúsculas ou minúsculas, e não consulta ALL_PROXY.
• Qualquer sinalizador passado para o subcomando orquestrador: self-hosted-runner orchestrator não aceita os sinalizadores ou suas variáveis de ambiente. Passe o sinalizador para cada runner que o orquestrador inicia em vez disso.

​

O que o runner muda enquanto um sinalizador de autorização de proxy está definido

• Listener: o listener é um proxy direto em 127.0.0.1. O runner inicia o listener antes de se registrar no plano de controle, e sai na inicialização se o listener não puder iniciar.
• Variáveis de proxy: o runner reescreve qual de HTTPS_PROXY e HTTP_PROXY você definiu para que aponte para o listener. Esse valor reescrito alcança o próprio runner, seus hooks de ciclo de vida, e cada sessão que ele executa.
• Rotação de token: um token girado entra em vigor sem uma reinicialização. Para cada conexão que o listener abre para seu proxy, o runner executa seu comando ou lê seu arquivo novamente e adiciona o resultado como o cabeçalho.
• Ambiente da sessão: uma sessão alcança seu proxy apenas através do listener. No ambiente de cada sessão, o runner remove ALL_PROXY, remove qualquer grafia de HTTPS_PROXY ou HTTP_PROXY que você não definiu, e fixa NO_PROXY ao próprio valor do runner.
• Logs: o runner nunca registra o valor do cabeçalho.

​

Configurar git

• Deixe o runner configurar git: inicie o runner com --configure-git para que ele escreva a mesma identidade e configuração de assinatura de commit que as sessões hospedadas pela Anthropic usam
• Envie configuração git em sua imagem: defina identidade e credenciais de push você mesmo, por exemplo para fazer commit sob sua própria identidade de bot

​

Deixe o runner configurar git

• user.name = Claude e user.email = noreply@anthropic.com, correspondendo às sessões hospedadas pela Anthropic
• Assinatura de commit e tag em formato SSH, roteada através de um shim gerenciado pelo runner que assina cada commit através do serviço de assinatura da Anthropic usando as credenciais da própria sessão. As assinaturas são verificáveis no GitHub contra a chave de assinatura SSH publicada da Anthropic.

​

Envie configuração git em sua imagem

RUN git config --system user.name "Claude" && \
    git config --system user.email "noreply@anthropic.com"

• Uma chave de implantação SSH limitada a um repositório com uma reescrita url.<base>.insteadOf
• Um credential.helper que retorna um token minimamente escopo
• GIT_SSH_COMMAND apontando para uma chave estreitamente escopo

• O runner define GIT_TERMINAL_PROMPT=0, para que git não peça um nome de usuário ou senha.
• O runner executa SSH com BatchMode=yes, anexado ao seu GIT_SSH_COMMAND se você definir um, para que SSH não peça uma frase-passe ou confirmação de host.
• O runner define GCM_INTERACTIVE=never, para que Git Credential Manager não abra um diálogo de login.
• O runner limpa core.askPass, então se você usar um helper askpass, defina-o através da variável de ambiente GIT_ASKPASS em vez disso.

RUN git config --system --add safe.directory '*'

​

Use o proxy git da Anthropic

​

Reescrever URLs git para redes privadas

• --git-host-rewrite <from>=<to>: para DNS de horizonte dividido, onde a Anthropic alcança seu host git através de um nome do host externo, mas runners devem usar um interno
• --git-ssh-rewrite <host>: para hosts git que apenas aceitam SSH, reescrevendo https://<host>/owner/repo para git@<host>:owner/repo

​

Construir a imagem do runner

FROM debian:bookworm-slim
ARG CLAUDE_CODE_VERSION
RUN apt-get update && apt-get install -y --no-install-recommends git curl ca-certificates openssh-client \
 && rm -rf /var/lib/apt/lists/*
RUN curl -fsSL "https://downloads.claude.ai/claude-code-releases/${CLAUDE_CODE_VERSION:?set with --build-arg CLAUDE_CODE_VERSION}/linux-x64/claude" \
      -o /usr/local/bin/claude && chmod +x /usr/local/bin/claude
RUN git config --system user.name "Claude" \
 && git config --system user.email "noreply@anthropic.com" \
 && git config --system --add safe.directory '*'
ENTRYPOINT ["claude"]

docker build --build-arg CLAUDE_CODE_VERSION=2.1.224 -t <your-registry>/claude-runner:latest .

​

Dimensionar CPU e memória para sessões

• Memória: uma requisição e um limite de 4 GiB cada, que atende ao mínimo de 4 GB nos requisitos do sistema do Claude Code. Mantenha os dois iguais para que o agendador contabilize a memória completa do contêiner. Quando o contêiner atinge seu limite de memória, o kernel mata processos dentro dele, o que pode encerrar uma sessão no meio da tarefa.
• CPU: uma requisição de 2 CPUs e um limite de 4 CPUs, para que uma sessão possa explodir acima da requisição durante builds. O kernel limita um contêiner em seu limite de CPU em vez de matar processos nele, então sessões no limite são executadas mais lentamente, mas continuam sendo executadas.

resources:
  requests:
    cpu: "2"
    memory: 4Gi
  limits:
    cpu: "4"
    memory: 4Gi

• Uma sessão por runner: dê a cada contêiner os valores de uma sessão. Use este dimensionamento em --capacity 1, que a seção de endurecimento recomenda, e para runners sob demanda, onde você define os valores na carga de trabalho que seu hook spawn-runner submete, como um modelo de pod de um Kubernetes Job.
• Várias sessões por runner: em um --capacity acima de um, multiplique os valores de uma sessão pela capacidade, porque até muitas sessões podem ser executadas no contêiner ao mesmo tempo. As receitas Kubernetes e Docker Compose executam --capacity 4 sem limites de CPU ou memória, então adicione limites dimensionados para a capacidade que você executa.

​

Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: claude-runner
  namespace: claude-runners
spec:
  replicas: 3
  selector:
    matchLabels:
      app: claude-runner
  template:
    metadata:
      labels:
        app: claude-runner
        app.kubernetes.io/part-of: claude-code-self-hosted-runner
    spec:
      terminationGracePeriodSeconds: 90
      containers:
        - name: runner
          image: <your-registry>/claude-runner:latest
          args:
            - self-hosted-runner
            - --environment-secret-file
            - /etc/claude/environment-secret
            - --capacity
            - "4"
          volumeMounts:
            - name: environment-secret
              mountPath: /etc/claude
              readOnly: true
          ports:
            - name: health
              containerPort: 8080
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 30
            periodSeconds: 30
      volumes:
        - name: environment-secret
          secret:
            secretName: claude-runner-environment-secret

kubectl create namespace claude-runners

kubectl create secret generic claude-runner-environment-secret -n claude-runners --from-file=environment-secret=./environment-secret

​

Docker Compose

services:
  claude-runner:
    image: <your-registry>/claude-runner:latest
    command:
      - self-hosted-runner
      - --environment-secret-file
      - /run/secrets/environment-secret
      - --capacity
      - "4"
    secrets:
      - environment-secret
    restart: always
    stop_grace_period: 90s

secrets:
  environment-secret:
    file: ./environment-secret

​

Tempo de encerramento

• Com um período de carência SIGTERM: defina terminationGracePeriodSeconds no Kubernetes, stop_grace_period no Docker Compose, ou o equivalente do seu orquestrador para pelo menos esse total. O padrão do Kubernetes de 30 segundos é mais curto que o caminho de drenagem do runner, portanto o Kubernetes para o pod antes do runner terminar a drenagem.
• Com --retire-at: dimensione a margem entre o tempo de aposentadoria e o tempo de parada do host para cobrir turnos típicos, mais a retenção de tarefa de fundo que Ciclo de vida do Runner descreve, mais esse mesmo total. Calcule o tempo de aposentadoria em cada inicialização, por exemplo date +%s mais o tempo de vida pretendido do runner.
• Com --defer-shutdown-max-min: adicione duas partes adicionais ao total do caminho de drenagem. A primeira é os minutos que você configura. A segunda é a carência pós-lançamento que Adiar a drenagem após o primeiro sinal descreve, 75 segundos nos padrões. Com a flag definida, o runner também imprime a figura combinada na inicialização, após o total do caminho de drenagem.

​

Adiar a drenagem após o primeiro sinal

​

O que acontece com as sessões que o runner mantém após o primeiro sinal

• Pelos primeiros n minutos: o runner serve suas sessões normalmente e continua aplicando --startup-timeout-min e --kill-session-after-min. Se você também definir --release-idle-session-min, o runner libera qualquer sessão cujo usuário tenha estado ocioso por esse tempo; sem isso, o runner não libera nenhuma sessão antecipadamente, exceto por um tempo limite de inicialização.
• Quando os n minutos se esgotam: o runner libera todas as sessões que ainda mantém, ociosas ou não. O runner aguarda o término do turno de uma sessão no meio do turno e até 60 segundos adicionais para as tarefas de fundo de um turno, antes de liberar essa sessão.
• Quando a carência pós-lançamento se esgota: o runner drena todas as sessões que ainda mantém, e o plano de controle recoloca cada sessão drenada na fila para outro runner imediatamente. A carência pós-lançamento começa quando os n minutos se esgotam e é 75 segundos nos padrões. Se você definir --drain-wait-sec acima de 60 segundos, a carência pós-lançamento será --drain-wait-sec mais 15 segundos.

​

Dimensionar o tempo limite de parada

​

O que atinge um hook post-session em execução

• Um SIGTERM enquanto o runner já está drenando: força a saída do runner imediatamente, pulando o que resta do caminho de drenagem. Sem --defer-shutdown-max-min, esse é o segundo SIGTERM que o runner recebe. Nada sinaliza um hook post-session em execução no meio, portanto em um host simples onde um processo init adota órfãos, ele termina por conta própria, mas sem supervisão: seu orçamento de tempo limite não se aplica mais, e uma escrita no pipe de log fechado pode matá-lo com SIGPIPE, portanto um hook que precisa sobreviver a uma saída forçada lá deve redirecionar sua própria saída para um arquivo. Nas receitas de contêiner nesta página, o runner é o PID 1 do contêiner e sua saída encerra o contêiner, e sob o padrão KillMode=control-group do systemd, a morte em nível de cgroup atinge o hook também, conforme a entrada Cgroup-wide kills descreve; em ambos, trate uma saída forçada como fatal para o hook e confie no período de carência.
• Sinais em nível de grupo de processos, como kill -- -<pid> em um script wrapper, controle de trabalho de shell ou um watchdog em nível de grupo: alcançam o runner e um subprocesso de hook checkout no meio, que permanece anexado ao grupo deliberadamente, mas não um hook post-session em execução no meio ou o filho da sessão.
• Mortes em nível de cgroup, como o padrão KillMode=control-group do systemd ou o SIGKILL que o Kubernetes entrega para todo o contêiner quando terminationGracePeriodSeconds expira: alcançam tudo, incluindo o hook. O isolamento de grupo de processos não protege contra esses, razão pela qual o período de carência deve cobrir o caminho de drenagem completo.
• O tempo limite próprio do hook: quando um hook excede --post-session-hook-timeout-sec, o runner envia SIGTERM para todo o grupo de processos do hook, depois SIGKILL dois segundos depois, portanto um worker que o hook bifurcou, como tar, rsync ou git, termina com o shell wrapper em vez de sobreviver como um órfão. A supervisão do runner termina uma vez que o stdio do hook fecha: um worker que redirecionou sua própria saída para um arquivo e sobrevive ao estágio SIGTERM está além do alcance do runner.

​

Mantenha o diretório base e a capacidade idênticos entre runners

​

Reuse a pre-warmed checkout

• Clone na imagem: construa o clone em sua imagem de runner naquele caminho. Cada contêiner fresco então começa com o clone quente sem reutilizar um disco.
• Clone em um volume persistente: em runners que você pré-bloqueia para a conta de um usuário com --lock-to-account, aponte --base-dir para um volume persistente, para que o disco apenas sirva essa conta. Um runner pré-bloqueado nunca pega sessões de canal Claude Tag, então essa opção não se aplica a runners que as servem.

• Qualquer forma de clone funciona: um clone completo, raso, ou de um único branch no caminho é usado como está. O runner nunca passa --depth ao buscar em um clone existente, então um pré-aquecimento completo mantém seu histórico completo e um raso permanece raso. CLAUDE_RUNNER_FETCH_DEPTH (full, 0, ou um número; padrão 50) controla apenas o clone frio que o runner faz quando nenhum clone existe ainda.
• Mudanças rastreadas redefinem, arquivos não rastreados persistem: cada sessão começa a partir de uma redefinição dura que limpa as modificações rastreadas da sessão anterior, mas o runner nunca executa git clean, então arquivos não rastreados das sessões anteriores do owner bloqueado permanecem na árvore.
• Com o proxy git, a redefinição se torna um checkout: com --use-anthropic-git-proxy, o runner sanitiza o .git/ do clone antes de cada sessão, mantendo o armazenamento de objetos, refs, e estado raso, mas deletando o índice, então cada sessão paga um checkout de árvore de trabalho completo em vez de uma redefinição quase instantânea; ainda nunca re-clona. Pré-aquecimentos de submódulo não são suportados sob o proxy.
• Clones longos não precisam de workaround: o runner limita cada operação git com um watchdog de 120 segundos sem progresso e um limite duro de 30 minutos, não um tempo limite fixo, então um clone frio lento que continua relatando progresso é concluído.

​

Pin the version

• Para manter uma frota em uma versão: construa a imagem com uma versão fixada, ou em um host nu instale uma versão específica e desabilite auto-updates
• Para atualizar: instale a versão mais recente ou reconstrua a imagem, depois reinicie os runners
• Plugins: marketplaces de plugin também não auto-atualizam; defina FORCE_AUTOUPDATE_PLUGINS=1 no ambiente do runner para deixar plugins auto-atualizarem enquanto o binário permanece fixado

​

Scale the fleet

• Frota fixa: execute um conjunto estático de réplicas de runner e dimensione nas métricas Prometheus que cada runner serve
• Runners sob demanda: execute o subcomando claude self-hosted-runner orchestrator, que faz polling na Anthropic para sessões que estão enfileiradas sem runner disponível e invoca seu hook spawn-runner para iniciar um por sessão. Consulte Runners sob demanda.

​

Problemas conhecidos e limitações

​

Tráfego de conector sai de sua rede

• https://api.anthropic.com/v2/ccr-sessions/*
• https://api.anthropic.com/v1/code/sessions/*
• https://api.anthropic.com/v1/code/mcp/*

​

Algumas sessões não contam como ociosas

​

Limitações adicionais

• Sessões retomadas perdem trabalho não enviado: quando uma sessão é liberada, no timeout ocioso ou na reinicialização do runner, e o usuário envia outra mensagem, a sessão retoma em um runner fresco que clona o repositório novamente de seu branch inicial, então o trabalho que a sessão não tinha enviado se foi. Defina --push-outcome-on-release para que o runner faça um push de melhor esforço dos branches de resultado da sessão antes de liberá-la, para que a sessão retomada comece a partir desses commits em vez disso; isso preserva trabalho confirmado, não uma árvore de trabalho suja. Antes de habilitá-lo, restrinja quem pode fazer push para refs claude/* no remoto de origem, por exemplo com um ruleset de branch: na retomada, o runner busca o branch previamente enviado sem verificar quem o enviou, então qualquer pessoa com acesso de push para essas refs pode colocar conteúdo no workspace retomado. O runner também descarta configuração por sessão na retomada, significando o diretório de configuração Claude da sessão e qualquer estado de shell que a sessão escreveu; --push-outcome-on-release não cobre esses.
• Repositórios privados não podem ser adicionados no meio da sessão: um repositório adicionado a uma sessão após ela ter iniciado não é clonado com credenciais em um runner auto-hospedado, então a adição falha. Selecione cada repositório que a sessão precisa quando você a cria.
• Alguns conectores não aparecem em sessões auto-hospedadas: um conector que você ainda não conectou nas Configurações do claude.ai não está listado em uma sessão auto-hospedada, e a sessão não o solicitará para conectar. Conecte-o nas Configurações primeiro, depois inicie uma sessão fresca. Adicionar um conector a uma sessão já em execução também não torna suas ferramentas disponíveis para Claude; inicie uma sessão fresca para pegar um conector recém-adicionado.

​

Relatar um problema

​

Troubleshooting

claude self-hosted-runner doctor

• Runner não aparece no ambiente: confirme que o host pode alcançar api.anthropic.com via HTTPS, o segredo do ambiente está atual e o relógio do host está dentro de cinco minutos da hora real; desvios maiores causam falha na autenticação. O runner registra [runner:fatal] com o motivo da rejeição em caso de falha de autenticação.
• Runner sai na inicialização com cannot create or write to base directory: o runner não consegue criar ou escrever em --base-dir, que padrão é /workspace. Corrija a propriedade do diretório ou aponte --base-dir para um caminho gravável, conforme descrito em Keep the base directory and capacity identical across runners. Se o runner registrar [runner:fatal] dizendo que a verificação do diretório base expirou, o diretório está em uma montagem NFS ou CSI travada. Verifique a saúde da montagem em vez de permissões. O runner imprime ambas essas falhas de inicialização para stderr antes de abrir --log-file, então procure por elas no terminal ou nos logs do contêiner da sua plataforma em vez do arquivo de log. Antes da v2.1.225, o runner não verificava o diretório base na inicialização, e essa configuração incorreta falhava nas sessões após a coleta.
• Sessions stay queued: cada runner online pode estar bloqueado para um proprietário diferente. Verifique a métrica claude_code_self_hosted_runner_locked_account metric de cada runner ou o campo locked_account de sua linha de log [runner:health] para ver quem a mantém. Ambos mostram o email do proprietário apenas depois que o runner recebeu um token de sessão com uma reivindicação act.email, que as sessões de um agente Claude Tag nunca fazem. Sem a reivindicação, o runner não emite nenhuma série locked_account e registra locked_account=yes, o que informa que o runner está bloqueado, mas não para qual proprietário. Adicione réplicas ou aguarde um runner existente drenar e reiniciar. Se o ambiente usar runners sob demanda, verifique o orquestrador; consulte On-demand runners.
• Sessions fail immediately after pickup: abra a sessão em claude.ai/code para ver o erro. As causas mais comuns são git credentials ausentes na imagem do runner e ferramentas de compilação que não estão instaladas. Um diretório base não gravável interrompe o runner na inicialização em vez de falhar nas sessões. Consulte a entrada Runner sai na inicialização com cannot create or write to base directory nesta lista.
• Sessions can’t reach the network through an authenticating egress proxy: quando a fonte que você definiu com --proxy-authorization-command ou --proxy-authorization-file falha, expira após 30 segundos ou produz um valor vazio, o runner responde essa conexão com 502 Bad Gateway e registra o motivo. O runner redige o stderr do comando nesse log e nunca registra o valor do cabeçalho. Com --proxy-authorization-command, execute o comando você mesmo no host para confirmar que ele imprime o valor do cabeçalho inteiro em stdout. Se o runner sair na inicialização com could not start the proxy-authorization listener, ele não conseguiu abrir seu listener de loopback.
• Runner logs Poll failed lines containing rejecting the malformed poll response: o runner recebeu uma resposta de work-poll cujo corpo não é o JSON esperado da fila, na maioria das vezes porque algo entre o runner e api.anthropic.com, como um proxy interceptador ou um portal cativo, respondeu com sua própria página. O runner rejeita a resposta, a conta sob o tipo transport da métrica claude_code_self_hosted_runner_poll_errors_total metric, e tenta novamente no cronograma de falha de pesquisa descrito em Session lifecycle. O runner continua servindo suas sessões ativas. Configure o proxy para passar respostas de api.anthropic.com inalteradas. Antes da v2.1.246, o runner lia tal resposta como uma fila de trabalho vazia, o que poderia encerrar suas sessões ativas ou fazer com que saísse.
• A session’s branch no longer exists on the remote: para uma fonte git que a sessão apenas lê, o runner pula essa fonte e continua nas restantes. Para a fonte para a qual a sessão envia resultados, uma ramificação excluída, normalmente porque foi mesclada e auto-excluída, falha na sessão com um erro nomeando o repositório e a ramificação e pedindo que você restaure a ramificação e tente novamente. O runner falha na sessão com o mesmo erro quando pular deixaria sem nenhum repositório. Antes da v2.1.228, tal sessão começava em um diretório vazio.
• Sessions take minutes to start: o clone inicial geralmente domina. Observe a métrica claude_code_self_hosted_runner_session_init_duration_seconds metric para confirmar e corte o clone com um pre-warmed checkout ou um CLAUDE_RUNNER_FETCH_DEPTH menor.
• Pod is killed mid-drain: aumente terminationGracePeriodSeconds para pelo menos o valor que o runner registra na inicialização. Consulte Shutdown timing.

​

O que vem a seguir

• Customize sessions: wrapper scripts, lifecycle hooks, on-demand runners, MCP servers, and permissions
• Test end to end: verify a new runner image from CI before promoting it
• Reference: every CLI flag, environment variable, and metric