Claude Code Auto Mode vira padrão dia 14: o que muda e como desativar

Dia 14 de agosto o Claude Code para de te perguntar.

Não é um modo novo. O auto existe desde março. O que muda dia 14 é que o Auto Mode do Claude Code vira o padrão: quem está em Pro, Max ou Team vai abrir o terminal e encontrar a sessão já rodando com um classificador decidindo, no seu lugar, quais comandos podem executar. Você não precisa fazer nada para isso acontecer. Precisa fazer alguma coisa para que não aconteça.

A Anthropic justificou a mudança com um número desconfortável: num teste com mais de mil devs profissionais, o classificador barrou 89% dos comandos perigosos. Os humanos aprovando na mão barraram 14%. Este post é sobre o que esse número quer dizer, o que exatamente o modo automático libera sem perguntar — tem coisa nessa lista que provavelmente vai te surpreender — e como colocar o freio de volta sem abrir mão do modo.

TL;DR

• O que é: o modo de permissão auto do Claude Code vira o padrão. Um modelo classificador separado avalia cada chamada de ferramenta antes de executar, no lugar do prompt de aprovação.
• Quando e pra quem: 14 de agosto, em Pro, Max e Team. Enterprise, API, Bedrock, Google Cloud Agent Platform e Microsoft Foundry continuam opt-in, com virada prevista ao longo do mês seguinte.
• Custo: os tokens extras do classificador deixaram de contar no limite de uso de Pro, Max e Team.
• Como escapar: Shift+Tab na sessão, defaultMode nas configurações de usuário, ou disableAutoMode nas configurações gerenciadas se você é admin.
• Link útil: Escolha um modo de permissão e Configurar modo automático — a documentação em português é a referência real, não os posts de notícia.

O que muda quando o Auto Mode vira padrão no Claude Code

Hoje, no modo Manual (o valor default na configuração), o Claude para em toda escrita de arquivo e todo comando de shell e espera você apertar sim ou não. A partir do dia 14, o padrão passa a ser auto: a pausa some para o trabalho rotineiro e cada ação passa por um modelo classificador que roda antes da execução.

A primeira coisa a entender é que auto não é bypassPermissions. São coisas opostas, e vale fixar a diferença:

bypassPermissions é o --dangerously-skip-permissions: não existe checagem, é pra container isolado. auto troca a sua aprovação por uma aprovação automatizada — que pode dizer não. A própria documentação é honesta sobre o limite disso: "o modo automático reduz prompts de permissão, mas não garante segurança".

O classificador roda num modelo definido pelo servidor, independente do que você escolheu em /model. Ele enxerga suas mensagens, as chamadas de ferramenta e o conteúdo do seu CLAUDE.md. E enxerga de propósito uma coisa a menos: os resultados das ferramentas são removidos antes de chegar nele, para que conteúdo hostil dentro de um arquivo ou de uma página web não consiga manipulá-lo direto. Uma sonda separada, do lado do servidor, é quem inspeciona esses resultados antes do Claude ler.

Acompanhar cada uma dessas viradas sozinho é o que cansa: o padrão de uma ferramenta que você usa todo dia muda numa quinta-feira e você descobre depois, em produção. No Clã Beer and Code a gente abre a configuração e discute o que muda na mesma semana em que muda — é assinatura paga, sem eufemismo, e é o tipo de ambiente que mudança silenciosa de padrão exige.

Os números da Anthropic — e o 11% que a imprensa trocou de lugar

O argumento central da mudança é um estudo com 1.053 testadores profissionais pagos. O resultado:

A Anthropic acrescenta que, analisando sessões reais, a aprovação manual foi mais que duas vezes mais provável de terminar em ação prejudicial que o usuário não tinha pedido explicitamente. Em ataques simulados, a taxa de falha caiu de 12% para 7%. E uma avaliação independente da Trajectory Labs não conseguiu emplacar nenhum dos 720 ataques de prompt injection testados. A leitura da imprensa especializada foi de ceticismo educado: o The New Stack resumiu a decisão como "porque não dá pra confiar nos humanos".

Aqui vale um aviso sobre o que você leu em outro lugar nos últimos dias. Circulou bastante a frase "a IA pega 89% e os humanos pegam 11%". Esse 11% não é a taxa humana — é 100 - 89, ou seja, o que o classificador deixa passar. A taxa humana é 13,6%. Dois números diferentes, com significados opostos, viraram um só em várias manchetes.

Por que isso importa na prática: os 11% que o classificador erra são o seu risco residual real. Não são o desempenho de ninguém. Se você fizer a leitura errada, vai achar que o modo automático é um upgrade de segurança absoluto, quando o que ele é de fato é uma troca — você deixa de ser o gargalo e passa a ser a auditoria.

E tem o dado que quase ninguém mencionou: a Anthropic parou de cobrar os tokens extras que o classificador consome em Pro, Max e Team, com intenção de fazer o mesmo nas outras plataformas. Repare que a documentação ainda afirma que "as chamadas do classificador contam para seu uso de token" — nesse ponto ela está atrasada em relação ao comunicado. Se você tinha evitado o modo automático por medo de queimar cota, esse motivo caiu. (Sobre onde sua cota realmente vai, o assunto é outro: prompt caching.)

O que o modo automático libera por padrão

Esta é a seção que vale a leitura do post inteiro. Permitido sem perguntar:

• Operações de arquivo local no seu diretório de trabalho.
• Instalação de dependências declaradas nos seus lockfiles e manifestos.
• Leitura do .env e envio das credenciais para a API correspondente.
• Requisições HTTP somente leitura.
• Push para a branch em que você começou, ou uma que o Claude criou.
• Push rotineiro para a branch padrão do repositório.

Leia as duas em negrito de novo.

O push direto na branch padrão passou a ser permitido a partir da v2.1.203 — antes, qualquer push na default era bloqueado. Hoje o classificador só barra quando o push carrega risco: force push, conteúdo sensível como segredos ou dados pessoais, mudanças escondidas ou mal descritas em relação ao que você pediu, conteúdo trazido de fora do repositório, ou um push que contorna uma revisão que você mesmo configurou. Um push comum na main passa.

Se o seu fluxo depende de "ninguém commita direto na main", a proteção de branch do remote continua valendo — o classificador é uma camada, não a única. Mas se você contava com o prompt do Claude Code como checkpoint, ele não vai mais estar lá.

O que ele bloqueia

A lista de bloqueio é longa e cresceu bastante nas últimas versões. Os destaques:

• Baixar e executar código, tipo curl | bash.
• Enviar dados sensíveis para endpoints externos.
• Deploy e migration de produção.
• Exclusão em massa em storage de nuvem.
• Conceder permissão de IAM ou de repositório.
• Force push; git reset --hard, git checkout -- ., git clean -fd, git stash drop.
• git commit --amend quando o commit no HEAD não foi criado nesta sessão, ou já foi enviado.
• terraform destroy, pulumi destroy, cdk destroy.
• Fazer merge de PR que nenhum humano aprovou, ou o Claude aprovar o próprio PR, ou desabilitar checks de CI.
• Ligar, desligar ou fazer ramp de feature flag de produção.
• Imprimir credencial ou token vivo na transcrição ou em arquivo.
• Rodar comando com flag que desliga proteção, tipo --insecure.
• Escrever nas próprias transcrições de sessão em ~/.claude/projects/.
• Mandar keystroke para o próprio painel tmux do Claude Code — que o classificador trata como o Claude mexendo na própria supervisão.

Duas coisas nem chegam ao classificador: rm -rf / e rm -rf ~ vão direto pro prompt de aprovação, inclusive quando aparecem dentro de $(...), crase ou <(...).

E existe um mecanismo que quase ninguém conhece: o limite que você declara conversando também bloqueia. Se você escrever "não faz push até eu revisar", o classificador passa a barrar as ações correspondentes mesmo que as regras padrão permitissem. O problema é que isso não vira regra armazenada — ele relê a transcrição a cada verificação. Se a compactação de contexto comer a mensagem onde você declarou o limite, o limite evapora junto. Para garantia dura, é regra em arquivo.

Como desativar o Auto Mode (ou só colocar o checkpoint humano de volta)

Tem quatro níveis, do mais cirúrgico ao mais bruto.

1. Manter o modo automático, mas exigir aprovação em ações específicas

O mecanismo é permissions.ask. Regras ask com escopo de conteúdo são avaliadas antes do classificador e sempre forçam o prompt, mesmo em modo automático. É a receita para quem quer o ganho de fluidez sem soltar push e PR:

{
  "permissions": {
    "ask": [
      "Bash(git push *)",
      "Bash(gh pr create *)"
    ]
  }
}

Se a ação nunca deve rodar, sob nenhuma hipótese, é permissions.deny — que bloqueia antes do classificador ser consultado e não pode ser sobreposto nem pela sua intenção declarada.

2. Dizer ao classificador qual é a sua infraestrutura

Por padrão o classificador confia só no diretório de trabalho e nos remotes que já estavam configurados quando a sessão começou. Todo o resto é externo — e alvo potencial de exfiltração. É por isso que ele bloqueia push para a org da empresa ou escrita num bucket do time até você declarar:

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Source control: github.example.com/acme-corp e todos os repos abaixo",
      "Trusted cloud buckets: s3://acme-build-artifacts",
      "Trusted internal domains: *.corp.example.com",
      "Key internal services: Jenkins em ci.example.com"
    ]
  }
}

As entradas são prosa, não regex. O classificador lê como regra em linguagem natural — escreva como você explicaria sua infra para alguém que entrou ontem no time.

A pegadinha que vai pegar muita gente: o classificador não lê autoMode de .claude/settings.json nem de .claude/settings.local.json. Esses arquivos moram dentro do repositório, então um repo clonado poderia injetar as próprias regras de permissão. autoMode só vale em ~/.claude/settings.json ou nas configurações gerenciadas. Se você colocar no lugar errado, ele é ignorado em silêncio e você vai achar que configurou.

Vale o mesmo alerta para o "$defaults": definir environment, allow, soft_deny ou hard_deny sem essa string literal descarta a lista embutida inteira daquela seção. Sem $defaults em soft_deny, você acabou de desligar os bloqueios de force push, curl | bash e deploy de produção sem perceber.

3. Mandar todo comando de shell pro classificador

Regras estreitas como Bash(npm test) continuam valendo em modo automático e resolvem antes do classificador. O problema é que uma regra estreita ainda deixa passar um argumento destrutivo que o prefixo não antecipou — um caminho de script, uma flag inesperada.

{
  "autoMode": {
    "classifyAllShell": true
  }
}

Isso suspende todas as regras Bash e PowerShell enquanto o modo automático está ativo. Troca latência por cobertura: cada comando de shell passa a esperar uma decisão.

4. Simplesmente não usar

Na sessão, Shift+Tab alterna os modos — auto aparece por último no ciclo. Para valer sempre:

{
  "permissions": {
    "defaultMode": "manual"
  }
}

Detalhe: defaultMode: "auto" é ignorado quando vem de configuração de projeto ou local, justamente para um repositório não conseguir se autoconceder o modo automático. Já manual funciona nos escopos normais.

Se você é Owner de Team ou Enterprise, o controle organizacional é permissions.disableAutoMode com valor "disable" nas configurações gerenciadas. Isso tira o auto do ciclo do Shift+Tab e faz o --permission-mode auto ser rejeitado na inicialização.

E três comandos para conferir o que você realmente configurou, em vez de torcer:

claude auto-mode defaults    # imprime as regras embutidas
claude auto-mode config      # imprime a config efetiva, com $defaults expandido
claude auto-mode critique    # pede uma revisão das suas regras customizadas

Rode o config depois de salvar. É o único jeito de saber se aquele bloco autoMode está sendo lido de verdade.

Limitações e pontos de atenção

Os 7% continuam lá. Em ataques simulados a falha caiu de 12% para 7% — caiu, não zerou. E os 11% de comandos perigosos que o classificador não pega existem. Modo automático é bom para trabalho em que você confia na direção geral, não substituto de revisão em operação sensível.

O classificador é cego para resultado de ferramenta. Isso é uma escolha de design que protege contra prompt injection, mas tem custo: ele julga com base na conversa, não na saída dos comandos. É por isso que um rm -rf "$VAR" cujo valor veio só de output anterior é bloqueado em vez de avaliado — ele não tem como resolver o alvo. Se você quer entender o modelo de ameaça por trás disso, vale o post sobre prompt injection e os principais ataques de 2026.

Ele desiste sozinho. Se o classificador bloquear uma ação 3 vezes seguidas ou 20 vezes no total, o modo automático pausa e o prompt de permissão volta. Os limites não são configuráveis. Em modo não interativo com -p, bloqueio repetido aborta a sessão — não tem ninguém pra perguntar. Se você roda Claude Code em CI, planeje isso.

Subagent não escapa. O classificador verifica em três pontos: a descrição da tarefa antes do subagent começar, cada ação dele durante a execução, e o histórico completo no retorno. Qualquer permissionMode no frontmatter do subagent é ignorado.

Regra ampla é descartada. Ao entrar em modo automático, Bash(*), PowerShell(*), interpretadores com wildcard e regras Agent são derrubadas. Elas voltam quando você sai do modo.

FAQ rápido

Dá pra simplesmente continuar no modo Manual? Dá. Shift+Tab durante a sessão resolve na hora, e "defaultMode": "manual" em ~/.claude/settings.json deixa permanente. O alias manual para o valor default existe a partir da v2.1.200.

Sou admin e não quero isso na empresa. Configurações gerenciadas com permissions.disableAutoMode em "disable". Isso remove o modo do ciclo e rejeita a flag na inicialização — é controle de organização, não sugestão.

Vale para quem usa Bedrock, Google Cloud ou Foundry? No dia 14, não. A virada é em Pro, Max e Team; Enterprise, API e as plataformas parceiras seguem opt-in com previsão de virar ao longo do mês seguinte. Nesses provedores o modo automático só roda em Sonnet 5, Opus 4.7 e Opus 4.8.

O classificador vai comer meu limite de uso? Não em Pro, Max e Team — a Anthropic parou de cobrar esses tokens extras. A documentação ainda diz o contrário em um trecho; nesse ponto ela está desatualizada em relação ao comunicado.

O padrão mudou. A responsabilidade, não.

O dado da Anthropic é real e é incômodo: aprovando na mão, a gente pega 13,6% dos comandos perigosos. Ninguém lê com atenção o milésimo prompt do dia. Automatizar essa decisão é, na média, uma melhora — e os 720 ataques de prompt injection que não passaram na avaliação independente não são pouca coisa.

Mas média não é a sua sessão. O que decide o seu risco é o que está na lista de permitido por padrão: push na branch principal, leitura do .env, instalação de dependência. Se algum desses três te deu um frio na barriga lendo, você tem quatro dias e um arquivo JSON pra resolver.

Abre o ~/.claude/settings.json hoje. Roda claude auto-mode config e olha o que sai. É mais barato do que descobrir na quinta-feira que a definição de "rotineiro" da sua ferramenta não era a mesma que a sua.

Se você quer ver o que acontece quando um agente decide sozinho o que é razoável fazer, o Claude que invadiu três empresas reais é a leitura seguinte. E se o assunto é o que a Anthropic mexe sem avisar, tem também os 80% do system prompt do Claude Code que sumiram.