Modo Auto do Claude Code

Problema: Qualquer utilizador do Claude Code acaba exausto com os prompts de permissão. Estás a refatorar três ficheiros, Claude precisa de npm test, e um modal aparece à frente do teu trabalho. Aprovar. Leitura de ficheiro. Aprovar. Escrita de migração. Aprovar. Depois de trinta prompts já não os estás a ler. Só estás a clicar.

A outra opção era --dangerously-skip-permissions. Essa flag remove todas as proteções. Dentro de um container, tudo bem. No teu laptop, com chaves SSH e ficheiros .env e credenciais git ali mesmo? Não é uma opção que qualquer pessoa sensata devia escolher.

O modo auto é o caminho do meio. Foi lançado a 24 de março de 2026, e funciona ao correr um segundo modelo de IA em background. Cada chamada de ferramenta que Claude quer fazer é inspecionada primeiro. As chamadas arriscadas são bloqueadas e Claude é informado do porquê. As seguras executam sem qualquer prompt. O revisor fica entre Claude e o teu sistema de ficheiros, e toma a decisão que tu tomas, mais rápido do que consegues clicar.

O Que o Modo Auto Realmente É

O modo auto é um novo modo de permissão. Encaixa entre default (tu revisas tudo) e bypassPermissions (nada é revisto). Ativa-o e Claude para de mostrar prompts. Antes de cada chamada de ferramenta executar, um modelo classificador separado analisa a conversa e a ação pendente, e decide passar ou bloquear.

Três categorias de risco conduzem a decisão:

1. Escalada de âmbito: a ação vai além do que pediste?
2. Infraestrutura não confiável: o alvo é algo que o classificador não tem razão para confiar?
3. Injeção de prompt: a ação parece ter vindo de conteúdo hostil que Claude leu num ficheiro ou página?

Passa e a ação executa. Bloqueia e Claude recebe o motivo para tentar uma abordagem diferente. As tuas mãos ficam no teclado. O revisor fica de guarda.

Como o Classificador Funciona

Cada chamada do classificador corre no Claude Sonnet 4.6, independentemente do modelo que a tua sessão usa. A entrada são as tuas mensagens de utilizador mais as chamadas de ferramenta pendentes. A própria prosa do Claude e os resultados anteriores das ferramentas são removidos propositadamente. Como o output das ferramentas nunca chega ao contexto do classificador, nada malicioso dentro de um ficheiro ou página pode entrar e alterar a decisão.

O teu CLAUDE.md passa pelo classificador. As regras do projeto influenciam o que o classificador aceita e recusa. Listas estáticas de permissão e bloqueio correspondem a nomes de ferramentas e argumentos como um grep. O classificador lê prosa e raciocina sobre intenção, por isso trata casos que a correspondência de padrões não consegue.

Ordem de Avaliação

Cada chamada de ferramenta percorre uma hierarquia fixa. O primeiro a corresponder ganha:

As tuas regras do settings.json ainda correm primeiro. Bash(npm test) na lista de permissões executa sem o classificador acordar. Bash(rm -rf *) na lista de bloqueios é eliminado antes do classificador ver.

Regras de Permissão Amplas São Removidas

Aqui está o detalhe que a maioria das pessoas não percebe: no momento em que entras no modo auto, o Claude Code remove as tuas regras de permissão amplas que concedem execução arbitrária. Coisas como Bash(*), Bash(python*), Bash(node*), e todas as regras Agent são removidas durante a sessão.

O motivo é direto. Se Bash(*) ficasse ativo, os exatos comandos com maior probabilidade de te prejudicar seriam aprovados automaticamente antes do classificador ter oportunidade de analisar. A funcionalidade toda ficaria derrotada.

Regras precisas ficam intactas. Bash(git status) e Bash(npm test) passam sem problemas. As regras removidas voltam quando sais do modo auto.

O Que É Bloqueado vs Permitido

Uma fronteira de confiança percorre a visão do classificador do teu sistema. O teu diretório de trabalho local é confiável. Se estás dentro de um repositório git, os remotes configurados para esse repositório são confiáveis. Tudo fora desse perímetro conta como externo até um administrador dizer o contrário.

Bloqueado por Defeito

Permitido por Defeito

Obtém o conjunto de regras padrão completo como o classificador as lê:

claude auto-mode defaults

Trabalho de equipa habitual às vezes aciona o classificador. Push para o repositório da tua organização, escrita para um bucket da empresa. O classificador não sabe que são teus. Admins corrigem isto configurando infraestrutura confiável em autoMode.environment.

Como Ativar o Modo Auto

Pré-requisitos

Três coisas precisam de ser verdade:

• Plano Claude Code Team (suporte Enterprise e API a chegar em breve)
• Claude Sonnet 4.6 ou Claude Opus 4.6 (não disponível em Haiku, modelos claude-3, ou fornecedores de terceiros como Bedrock ou Vertex)
• Ativação pelo administrador: um admin deve ativar o modo auto nas definições de admin do Claude Code antes dos utilizadores poderem ligá-lo

CLI

Lança uma sessão que pode entrar no modo auto:

claude --enable-auto-mode

Shift+Tab percorre os modos: default -> acceptEdits -> plan -> auto. O teu modo atual aparece na barra de estado.

Ou vai diretamente no lançamento:

claude --permission-mode auto

VS Code

1. Abre as definições da extensão Claude Code
2. Ativa Allow dangerously skip permissions (isto desbloqueia o modo auto na interface)
3. Clica no indicador de modo na parte inferior da caixa de prompt
4. Seleciona Auto no menu

Aplicação Desktop

1. Ativa o modo auto nas definições do Desktop
2. Usa o seletor de modo ao lado do botão de envio
3. Seleciona Auto no menu

O Desktop vem com o modo auto desativado. Ativas nas definições antes de aparecer como opção.

Modo Não-Interativo

Execuções com script funcionam bem com a flag -p:

claude -p "refactor the auth module" --permission-mode auto

Um aviso. Se o fallback entrar em ação (explicado abaixo), sessões não-interativas encerram. Não há ninguém no teclado para responder a um prompt.

Subagentes em Modo Auto

Equipas que executam loops de agentes e configurações multi-agente precisam de saber como isto flui para os subagentes. Três pontos de verificação:

No spawn: antes do subagente iniciar, o classificador lê a descrição da tarefa delegada. "Elimina todos os branches remotos correspondendo a este padrão" é recusado logo à entrada. O subagente nunca chega a correr.

Durante a execução: dentro da sessão filho, o modo auto aplica as mesmas regras de permissão e bloqueio que o pai. Qualquer permissionMode que o subagente definiu no seu próprio frontmatter é ignorado. Cada chamada de ferramenta passa pelo classificador por conta própria.

No retorno: quando o subagente termina, o classificador lê o seu registo completo de ações. Um filho que parecia bem no spawn pode ter sido comprometido a meio da execução por algo que leu. Se a passagem de retorno assinala um problema, um aviso de segurança é colocado no início do output do subagente para o pai poder reagir.

Três pontos de verificação significa que os subagentes não precisam da tua confiança cega. O classificador trata-os da mesma forma que trata a sessão principal.

Modo Auto ao Lado dos Outros Modos

Aqui está a visão completa de todos os modos de permissão do Claude Code:

A troca é simples. Pagas mais tokens e esperas um pouco mais por cada ação verificada. Perdes a chuva de prompts que transforma qualquer sessão longa num exercício de cliques.

Quando Escolhê-lo

Boa escolha quando:

• Tarefas longas onde aprovações constantes interrompem a concentração
• Confias na direção geral mas queres uma rede de segurança nas partes complicadas
• Loops de agentes sem ninguém por perto para confirmar cada passo
• Queres uma escolha mais segura do que bypassPermissions fora de um container

Má escolha quando:

• Infraestrutura de produção está em âmbito (este modo bloqueia essas ações de qualquer forma, com razão)
• Código desconhecido onde queres olhar para cada passo
• Controlo auditável determinístico é importante (usa dontAsk com regras de permissão explícitas)
• O custo é apertado (chamadas do classificador custam tokens)

O Fallback

Falsos positivos não devem afundar a tua sessão, por isso o fallback apanha-os. Se o classificador bloquear 3 seguidos ou 20 no total numa sessão, o modo auto pausa e o Claude Code volta a pedir aprovação manualmente.

Nenhum dos limites pode ser ajustado.

Quando ativa:

• CLI: uma nota aparece na área de estado. Aprova o próximo prompt manual e os contadores de bloqueio reiniciam, para poderes ficar no modo auto.
• Modo não-interativo (flag -p): a sessão encerra. Não há ninguém para responder.

Bloqueios repetidos vêm de um de dois lugares. A tarefa genuinamente quer algo que o classificador foi construído para parar, ou o classificador está sem contexto sobre infraestrutura que realmente é tua. Usa /feedback quando parece um falso positivo. Se continua a não reconhecer que os teus repositórios e serviços são confiáveis, pede a um admin para configurar infraestrutura confiável nas definições geridas.

Defesa em Profundidade

Uma camada nunca é a história toda. O modo auto dá-te mais proteção do que bypassPermissions e menos do que revisar cada chamada manualmente. A configuração mais forte empilha:

Camada 1: Regras de permissão. Listas de permissão e bloqueio no settings.json resolvem antes do classificador correr. Usa-as para controlo determinístico e rígido em ferramentas específicas.

Camada 2: Classificador do modo auto. Apanha tudo o que as regras não cobrem. Raciocina sobre contexto, não apenas padrões de texto.

Camada 3: Hooks. Hooks PreToolUse correm lógica personalizada antes do sistema de permissões. O Permission Hook vem com um auto-aprovador baseado em LLM com um fluxo de três níveis (aprovação rápida, rejeição rápida, análise LLM). Hooks e modo auto coexistem: os hooks correm primeiro e podem aprovar, rejeitar ou escalar antes do classificador ver a chamada.

Camada 4: Sandboxing. O sandboxing ao nível do SO isola o acesso ao sistema de ficheiros e rede no kernel. Mesmo quando o classificador falha, o sandbox mantém os comandos shell dentro da caixa que definiste. Isto importa porque o classificador lê intenção enquanto o sandbox impõe limites rígidos.

Camada 5: Agentes auto-validadores e stop hooks. Estes mantêm os agentes na tarefa e dentro do âmbito, adicionando mais uma passagem de verificação por cima da história de permissões.

Cada camada preenche a lacuna que as outras deixam. Isso é defesa em profundidade.

Limitações a Saber

Isto foi lançado como research preview. Sê honesto sobre o que essa palavra significa:

• Sem garantia de segurança. Intenção de utilizador ambígua ou contexto de ambiente em falta pode fazer o classificador perder uma ação arriscada. O inverso também acontece (falsos positivos em ações benignas).
• Custa mais. Chamadas do classificador contam para o teu uso de tokens. Cada ação verificada envia uma parte da transcrição mais a chamada pendente. A maior parte do custo extra vem de comandos shell e operações de rede, porque ações só de leitura e edições de ficheiros locais saltam o classificador completamente.
• A latência é real. Cada verificação adiciona uma ida e volta antes da ação executar. Sequências de comandos shell rápidos ficam mais lentas.
• Disponibilidade limitada. Só plano Team por agora (research preview). Suporte Enterprise e API a chegar em breve. Sonnet 4.6 ou Opus 4.6 obrigatório. Sem Haiku, sem claude-3, sem fornecedores de terceiros.
• Não substitui revisão em operações sensíveis. Confia-lhe trabalho onde a direção está sólida. Para qualquer coisa que toque produção, credenciais ou infraestrutura partilhada, a revisão humana é ainda a chamada certa.

A calibração melhora com dados. /feedback é como falsos positivos e bloqueios falhados são reportados. Cada um desses relatórios afina o sistema.

O Que Vem A Seguir

Os utilizadores do plano Team ganham um novo fluxo de trabalho diário com isto. A antiga troca entre segurança e velocidade tem agora uma terceira opção.

Para uma postura de segurança completa em torno do modo auto:

• Escreve regras de permissão para controlo determinístico em ferramentas específicas
• Configura hooks para lógica de permissão personalizada além do que o classificador trata
• Ativa o sandboxing para enforcement ao nível do SO como backstop rígido
• Lê a referência de definições para todas as opções relacionadas com permissões
• Explora loops de agentes autónomos para tirar o máximo proveito dos prompts reduzidos em execuções longas

O prompt de permissão já não é o bottleneck. O classificador está de guarda. Volta a construir.