Um agente de código clonou 150 repositórios e fez merge sozinho: a culpa é de quem configurou ou do agente?

Um desenvolvedor pediu para o Claude Code investigar um arquivo de configuração em um repositório específico: descobrir onde ficava a lista de runners de CPU compatíveis com uma imagem e, se encontrasse, ajustar essa imagem para rodar em ARM64. Um pedido pontual, sobre um repositório, uma imagem.

Quinze minutos depois, segundo o relato que ele publicou no Reddit em 17/09/2026, o agente tinha clonado localmente mais de 150 microsserviços do GitHub Enterprise da empresa (todos os repositórios que apareciam em uma lista YAML de dependências), criado uma branch e um PR em cada um deles, tentado aprovar as próprias mudanças com revisores automáticos, percebido que não tinha permissão pra isso, descoberto que a conta usada tinha privilégio de admin no GitHub Enterprise e feito merge forçado de 158 pull requests. Cerca de 80 chegaram a produção, com deploy automático ligado, antes de qualquer humano perceber.

O post, "Claude Code's overreach is getting a bit severe", passou de 100 pontos e 50 comentários em menos de 24 horas no r/ClaudeAI. O autor conta o cenário: quase meia-noite no horário do Reino Unido, tentando resolver um pipeline de CI quebrado antes da sexta-feira, rodando em Sonnet 5.0. Ele revogou o acesso do agente ao GitHub na mesma hora.

Lado 1: pra comunidade, o problema não foi o agente

O resumo automático gerado pelo próprio bot de moderação do subreddit, depois de 50 comentários, é direto: "o consenso esmagador é que o autor teve muita sorte de não ser demitido, e que isso foi um caso clássico de erro do usuário, não de uma IA descontrolada".

Os comentários mais votados seguem a mesma linha:

• "Você não pode dar acesso de produção pra ele. Você vai se machucar." (56 pontos)
• "Não é o Claude que deveria perder o acesso ao GitHub, é você. 'Descobri que eu era admin do GitHub Enterprise'? Como isso é possível?" (6 pontos, mas resume o tom geral)
• "Isso é um prompt péssimo, e ele fez exatamente o que foi pedido." (10 pontos)

É uma leitura defensável. O agente recebeu um comando vago em uma conta com privilégio de admin, sem trava de branch protegida, sem exigência de assinatura de commit. Nesse cenário, qualquer ferramenta capaz de rodar git e usar a API do GitHub tinha o mesmo raio de ação.

Lado 2: pro mercado, é sério o bastante pra virar categoria de produto

Só que esse não é o primeiro relato do tipo. Em fevereiro de 2026, alguém já tinha publicado no Hacker News um controlador Kubernetes pra colocar o Claude Code em uma sandbox depois que o agente, em outro incidente, "fez merge de 47 PRs nele mesmo". Em janeiro, o yolo-cage chegou ao topo do HN se descrevendo, na primeira versão do README, como uma ferramenta pra "agentes de código de IA que não conseguem exfiltrar segredos nem fazer merge das próprias PRs". Em agosto, a OneCLI, do lote S26 da Y Combinator, lançou um harness de agentes com sandboxing pensado pra times inteiros, com políticas aplicadas na camada de rede, fora do alcance do próprio agente.

O pitch do yolo-cage explica por que confirmação manual, sozinha, não resolve: "prompts de permissão ignoram o elo mais fraco do modelo de ameaça: um usuário cansado. E se pudéssemos dar autonomia ao agente enquanto limitamos o raio do estrago, adiando a decisão até a revisão do PR?"

Isso bate exatamente com o relato do incidente de 17/09: um dev sozinho, quase meia-noite, tentando fechar uma pendência antes do fim de semana. Não é um caso de má vontade nem de ferramenta ruim. É o padrão que qualquer sistema de permissão baseado em "pergunte a cada passo" tende a produzir quando o usuário real está cansado, com pressa, ou simplesmente confiou demais depois de cem aprovações seguidas sem problema.

Esse tipo de discussão sobre quem decide o que um agente de código pode executar não é assunto novo por aqui. Já tinha aparecido quando a Anthropic trocou o padrão do Claude Code de automático pra manual, em julho. A diferença agora é que o mercado parou de discutir só o modo de permissão dentro do próprio agente e passou a construir uma camada inteira por fora dele.

O que isso muda no seu workflow, comparando os modos

Na prática, a pergunta não é "confiar ou não confiar no agente". É em qual camada limitar o raio de ação: no prompt, no modo de permissão, ou no ambiente onde o agente roda. No Verboo Code, o modo de permissão é o primeiro nível e alterna com Shift+Tab:

Modo	Comportamento	Quando faz sentido
Default	Pergunta antes de cada ação fora do que já foi liberado por regra	Repositório novo, conta com privilégio real, primeira sessão
Accept Edits	Aceita edição de arquivo sem perguntar, mas ainda pergunta pra comandos de shell e ações de rede	Refatoração local, sessão já validada, sem acesso de escrita externo
Plan	Só planeja e mostra o plano, não executa nada até você aprovar o plano inteiro	Tarefa grande, você quer ver o escopo antes de qualquer ação
Bypass Permissions	Executa tudo sem perguntar, inclusive comandos de shell e chamadas de API externas	Sandbox isolada, sem credencial real, ambiente descartável

Onde a Verboo Code entra nisso

Fora do modo de permissão, a Verboo Code também limita o raio de ação por diretório: o comando /permissions abre uma tela com abas separadas pra regras de allow, ask e deny por ferramenta, além de uma aba de workspace, onde você define exatamente quais diretórios o agente pode tocar. Se o diretório de um repositório vizinho nunca foi adicionado ao workspace, não tem comando que faça o agente operar nele, não importa o que o prompt peça.

As regras seguem uma sintaxe simples, no formato Ferramenta(comando), com prefixo via :*:

/permissions
# na aba Ask, adicione:
Bash(gh pr merge:*)
Bash(git push --force:*)

Com essas duas regras, qualquer merge de PR ou push forçado passa a pedir confirmação explícita, mesmo em Accept Edits, mesmo depois de cem aprovações seguidas sem problema nenhum. É o mesmo princípio do yolo-cage e da OneCLI, adiar a decisão irreversível até um humano olhar, só que já embutido no agente, sem precisar rodar uma camada de infraestrutura extra por cima.