Material gratuito

Modo automático do Claude Code: 5 ajustes antes do dia 14

O checklist de configuração pra não perder o controle quando o Claude Code ligar o modo automático por padrão.

Dia 14 de agosto o Claude Code passa a ligar o modo automático por padrão no Pro, no Max e no Team. Na prática: ele para de te perguntar a cada comando e passa a executar, com um classificador de segurança olhando cada ação antes dela rodar.

Muita gente vai receber essa mudança sem saber e vai achar que perdeu o controle. Não perdeu — só mudou de lugar. Antes o controle era você clicando "aprovar" cem vezes por dia (e a Anthropic mediu: a gente aprova 97% desses pedidos sem nem olhar). Agora o controle é a configuração que você deixa escrita antes.

São 5 ajustes. Levam uns 15 minutos e valem pro resto do ano.


1. Descubra em que modo você está hoje

Abre o Claude Code e aperta Shift + Tab. Isso circula entre os modos de permissão, e o modo atual aparece na barra de status. São seis:

ModoO que faz
default (ou manual)Pergunta antes de cada ação que altera algo
acceptEditsEdita arquivo sem perguntar, mas pergunta pra rodar comando
planSó lê e planeja, não altera nada
autoExecuta sozinho, com o classificador de segurança barrando o que for perigoso
dontAskNão pergunta e não checa — só respeita suas regras de deny
bypassPermissionsIgnora tudo. Só em container isolado

O que muda dia 14 é qual deles vem ligado quando você abre. Se você não fizer nada, vai ser o auto.

Sabe o pior? Muita gente vai confundir auto com dontAsk e desligar a coisa errada. auto tem classificador. dontAsk não tem nada.


2. Escreva sua lista de deny — essa é a que importa

O classificador é bom, mas ele julga contexto. A lista de deny é regra dura: se está lá, não roda, ponto. E tem uma coisa que quase ninguém sabe: as regras são avaliadas nesta ordem — deny, depois ask, depois allow. Ou seja, um deny em qualquer lugar ganha de um allow em qualquer outro. É a única trava que nada por cima desfaz.

No seu ~/.claude/settings.json:

{
  "permissions": {
    "deny": [
      "Bash(git push:*)",
      "Bash(rm -rf:*)",
      "Bash(docker system prune:*)",
      "Read(./.env)",
      "Read(./secrets/**)"
    ]
  }
}

Pensa no que na SUA operação não pode acontecer nem por acidente: subir pra produção, apagar volume de banco, mandar e-mail em massa, mexer no financeiro. Escreve tudo agora, com a cabeça fria — não às 23h no meio de um bug.

O Read(./.env) desse exemplo é o mais subestimado. Bloquear a leitura de credencial é o que impede a chave vazar pro contexto e, de lá, pra qualquer lugar.


3. Use ask pro que é sério mas legítimo

Nem tudo é "nunca". Tem ação que você quer fazer, só quer ver antes. Pra essas existe o ask — no modo automático ele continua parando e te perguntando:

{
  "permissions": {
    "ask": [
      "Bash(npm publish:*)",
      "Bash(supabase db push:*)",
      "Write(./infra/**)"
    ]
  }
}

Além do que você marca com ask, o modo automático já para sozinho em três situações: ferramenta de MCP marcada como requiresUserInteraction, rm -rf / e rm -rf ~. Essas três são de fábrica, você não precisa configurar.


4. Libere o que é repetitivo e inofensivo

O outro lado da mesma moeda. Se toda hora você aprova git status, isso não é segurança, é atrito:

{
  "permissions": {
    "allow": [
      "Bash(git status:*)",
      "Bash(git diff:*)",
      "Bash(npm test:*)",
      "Read(./**)"
    ]
  }
}

E aí que tá o ponto que dá nome a tudo isso: fadiga de alerta. Quando tudo pede permissão, nada é revisado. No teste que a Anthropic fez com 1.053 testadores pagos, a revisão humana pegou o comando perigoso só 13,6% das vezes — 143 de 1.053. O classificador automático pegou 89% — 937 de 1.053. Não é que a máquina seja mais esperta que você; é que ela não cansa na centésima vez.

Cada allow que você escreve é um alerta a menos pra ignorar quando importar.


5. Se você administra um time, fixe o padrão da empresa

Duas coisas que só quem gerencia precisa saber, e as duas são fáceis de errar.

Primeira: dá pra fixar o modo padrão com permissions.defaultMode. Mas o auto é ignorado quando vem de .claude/settings.json ou .claude/settings.local.json do projeto — isso é de propósito, pra que um repositório não consiga se conceder modo automático sozinho. Se você clonar o repo de terceiro, ele não liga o auto na sua máquina. Pra valer de verdade, o auto tem que vir do seu ~/.claude/settings.json ou das configurações gerenciadas da organização.

Segunda: se a sua empresa não quer modo automático de jeito nenhum, existe o desligamento no nível da organização:

{
  "permissions": {
    "disableAutoMode": "disable"
  }
}

Isso tira o auto do ciclo do Shift + Tab e recusa --permission-mode auto já na abertura. Ninguém liga por engano.

Ah, e se você está no Enterprise, na API, no Bedrock, no Vertex ou no Foundry: pra você nada muda dia 14, continua sendo opção que alguém precisa ligar.


Uma última coisa

O classificador tem um freio que não é configurável: depois de 3 bloqueios seguidos ou 20 no total, ele pausa e te chama. Isso não é bug, é o sistema dizendo que a tarefa saiu do trilho.

Se isso acontecer com você, não force. Para e lê o que ele barrou. Semana passada, trabalhando, ele me barrou duas vezes num dia — e nas duas eu ia seguir em frente. Não era a IA me atrapalhando, era ela vendo o que eu não vi.

Segurança que depende de alguém clicar "aprovar" cem vezes por dia já não é segurança. É teatro. Dia 14 é a chance de trocar o teatro por regra escrita.


Fonte: documentação oficial do Claude Code e o anúncio da Anthropic sobre o modo automático virar padrão (Claude Code e o modo auto são produtos da Anthropic). Confira sempre a documentação atual antes de aplicar em produção.

Imersão presencial — Empresa Inteligente, Empresário Livre

1º de setembro, presencial. Vagas limitadas.

Entrar na lista de espera

Curtiu? Tem mais coisa esperando.

Ver todos os materiais