Auto mode do Claude Code explicado: o que mudou (e como se manter segura) em 2026

- Os números, requisitos de versão e o comportamento do classifier abaixo foram conferidos diretamente na documentação oficial do code.claude.com no momento em que escrevi (2026-08-20); essa superfície muda a cada release, então confirme na documentação ao vivo antes de depender de qualquer coisa daqui.

O que mudou em 14 de agosto de 2026

Se o Claude Code parou recentemente de perguntar "posso fazer isso" antes de cada edição de arquivo ou comando de shell, aqui está o porquê: desde 14 de agosto de 2026, o auto mode passou a ser o modo de permissão inicial embutido nos planos Pro, Max e Team - não um recurso que você habilita, mas um que já está ligado para você. A mudança exige o Claude Code v2.1.228 ou posterior no macOS, Linux e WSL, ou v2.1.233 ou posterior no Windows nativo (não pelo WSL); versões mais antigas ainda iniciam no modo Manual, como antes.

Algo fácil de deixar passar: isto não é uma mudança para todo o sistema. Enterprise, sessões rodando com uma chave de API do Claude Console, claude -p/Agent SDK e sessões no Amazon Bedrock, no Agent Platform do Google Cloud ou no Microsoft Foundry ainda iniciam no default (Manual), como antes - a mudança só afeta sessões de terminal e VS Code nos três planos de consumidor/equipe.

O que o auto mode realmente é

A definição oficial e curta: o auto mode é um modo de permissão em que um segundo modelo, o classifier, revisa as ações no seu lugar, em vez de você clicar em prompts de sim/não um por um. O classifier bloqueia qualquer coisa que ultrapasse o seu pedido, mire uma infraestrutura que ele não reconhece como confiável ou pareça guiada por conteúdo hostil que o Claude acabou de ler.

Um detalhe que a maioria das fontes ignora: uma regra ask explícita no settings.json ainda força um prompt, mesmo no auto mode - porque uma regra ask é você já declarando "quero ser perguntada aqui". E o auto mode não é o único lugar onde o classifier roda: o modo plan também encaminha comandos de shell por ele quando o auto mode está disponível (ligado por padrão via a configuração useAutoModeDuringPlan) - a linha entre "plan" e "auto" é mais fina do que a maioria imagina.

Os quatro níveis de regra do classifier: hard_deny, soft_deny, allow e user intent

Esta é a parte que a maioria das fontes erra ou pula por completo: dentro do classifier, cada ação passa por exatamente quatro níveis de precedência, em uma ordem fixa - cada nível supera o de baixo.

As três listas acima (hard_deny/soft_deny/allow) são as regras embutidas da Anthropic, escritas como descrições em prosa, não como regex. Separado delas está o autoMode.environment, onde você declara qual infraestrutura - repositórios, buckets, domínios internos - o classifier deve tratar como seu "limite de confiança". Por padrão, o classifier confia apenas no seu diretório de trabalho atual e nos remotes configurados daquele repositório; todo o resto, incluindo os buckets em nuvem ou domínios internos da sua própria empresa, conta como "externo" até você adicioná-lo ao environment. É por isso que um push interno perfeitamente legítimo às vezes ainda é bloqueado: o classifier simplesmente ainda não "sabe" que aquela infraestrutura é sua.

O que o auto mode bloqueia e permite por padrão

A lista completa é longa (e limitada por versão item a item), mas aqui está o que mais importa para quem desenvolve sozinha:

Um detalhe fácil de deixar passar no lado "permitido": fazer push para a branch padrão (incluindo main) agora é permitido por padrão - antes da v2.1.211, apenas sua própria branch de trabalho e as branches criadas pelo Claude eram permitidas. Branches cujos nomes parecem alvos de deploy, como production, release ou gh-pages, não são cobertas por esse padrão - o classifier julga um push ali pelos próprios critérios, tratando-o como um deploy de produção. Para ajustar mais essa lista (adicionando buckets/domínios internos confiáveis ao environment, ou apertando o soft_deny), veja /docs/en/auto-mode-config.

O auto mode é mesmo mais seguro? Os números

Do estudo controlado da Anthropic com 1.053 testadores pagos: revisores humanos pegaram sozinhos apenas 13,6% dos comandos perigosos; o auto mode pegou 89%. Em dados reais de produção, 6,3% das sessões aprovadas manualmente continham uma ação prejudicial que a pessoa não havia pedido explicitamente, contra 2,4% das sessões em auto mode (severidade em nível de produção, limite 7+).

Este é o par de números corroborado de forma independente em pelo menos três fontes, então é seguro citá-lo. Fonte: o post oficial da Anthropic, auto-mode-default-in-claude-code (claude.com/blog, 08/2026). Uma ressalva que vale dizer com clareza: outros números secundários desse mesmo post (como as taxas médias de aprovação por sessão) retornaram valores um pouco diferentes em buscas distintas enquanto eu pesquisava este texto - então este artigo só cita o par bem corroborado acima, e você deve tratar qualquer alegação de "X% mais seguro" como uma tendência, não uma garantia para a sua sessão específica.

Por que o classifier resiste a prompt injection - ele nunca lê resultados de ferramentas

Uma pergunta que a maioria dos concorrentes passa por cima: se o Claude ler um arquivo malicioso (o README de uma dependência, uma issue do GitHub com instruções ocultas), isso também consegue enganar o classifier? Segundo a documentação oficial: o classifier só vê as suas mensagens, as chamadas de ferramenta que o Claude faz e o conteúdo do seu CLAUDE.md - ele nunca vê o resultado de uma ferramenta. Conteúdo hostil dentro de um arquivo ou página web que o Claude acabou de ler não consegue manipular diretamente a decisão do classifier.

Essa camada é reforçada por uma sonda separada no lado do servidor que examina os resultados de ferramentas que chegam e sinaliza conteúdo suspeito antes de o Claude ler. Para deixar claro: esta é uma defesa parcial, não uma garantia absoluta - o próprio aviso da Anthropic afirma que o auto mode "reduz os prompts de permissão, mas não garante segurança".

Os comandos da CLI claude auto-mode

Quer adicionar suas próprias regras mantendo os padrões? Inclua a string literal "$defaults" no array - as regras embutidas são inseridas naquela posição, e as suas podem vir antes ou depois. Omitir "$defaults" significa substituir toda a lista padrão daquela seção - inclusive as regras que bloqueiam force push ou vazamento de dados - então só faça isso quando você realmente pretender assumir a lista inteira por conta própria. Combine isso com o sandbox de Bash do Claude Code para uma camada de isolamento independente do classifier.

Revisar e repetir uma ação bloqueada - a aba "Recently denied"

Quando o classifier bloqueia uma ação, o Claude Code mostra uma notificação e a registra em /permissions, na aba Recently denied. Abra essa aba e pressione r em uma ação negada para marcá-la para nova tentativa - ao sair do diálogo, o Claude Code informa ao modelo que ele pode repetir aquela chamada de ferramenta e retoma a conversa.

Há um fallback automático que vale a pena conhecer: se o classifier bloquear uma ação 3 vezes seguidas ou 20 vezes no total em uma sessão, o auto mode se pausa sozinho e o Claude Code volta a perguntar manualmente. Esse limite não é configurável. Aprovar qualquer ação zera o contador consecutivo, enquanto o contador total persiste pela sessão inteira até disparar o fallback por conta própria. A causa mais comum de bloqueios repetidos é o classifier sem contexto sobre a sua infraestrutura - a correção mais rápida é adicionar o destino (domínio, bucket, host do repositório) ao autoMode.environment e depois rodar claude auto-mode config para confirmar que pegou.

Como voltar ao Manual (ou a qualquer outro modo)

O jeito mais rápido ainda é Shift+Tab. Vale ser exata: o ciclo padrão vai de default → acceptEdits → plan → auto → de volta ao default. Estando no auto, um toque te leva direto de volta ao default (Manual) - porque o auto é a última parada antes de o ciclo dar a volta.

Outras três maneiras:

• Uma flag de inicialização: claude --permission-mode default
• Uma configuração fixa via defaultMode no settings.json - o valor "auto" especificamente só tem efeito quando declarado em ~/.claude/settings.json (o arquivo de escopo do usuário); defini-lo no .claude/settings.json de um projeto é ignorado, a mesma proteção que impede um repositório clonado de conceder a si mesmo permissões elevadas
• Um interruptor geral da organização: um administrador define permissions.disableAutoMode como "disable" nas configurações gerenciadas - isso remove o auto do ciclo do Shift+Tab por completo

Para o panorama completo dos seis modos de permissão e da configuração de regras allow/deny, veja permissões do Claude Code e configuração segura.

Uma lista de verificação de segurança prática para o auto mode

• Confirme se o seu plano e modelo realmente suportam o auto mode (Opus 4.6+/Sonnet 4.6+/Fable 5 na API da Anthropic; Sonnet 5/Opus 4.7+/Fable 5 no Bedrock/Vertex/Foundry) - modelos mais antigos como Sonnet 4.5, Opus 4.5 e Haiku não são suportados em nenhum provedor.
• Antes de uma tarefa que toca uma infraestrutura importante, revise a lista de confiança em autoMode.environment com claude auto-mode config - não deixe o classifier adivinhar o que é confiável.
• Quer um ponto de checagem humano antes de um push ou PR? Adicione uma regra permissions.ask (por ex. "Bash(git push *)") - ela sempre vence; o classifier não consegue aprovar automaticamente por cima dela.
• Não trate o auto mode como substituto de um sandbox em execuções genuinamente sem supervisão - um contêiner ou VM adiciona uma camada de isolamento que não depende só do classifier.
• Confira /permissions → Recently denied periodicamente, em vez de dispensar a notificação de bloqueio - normalmente é um sinal de que o classifier está sem contexto, não de que está errado.
• Limites ditos na conversa ("não faça push", "espere minha revisão antes de fazer deploy") são respeitados pelo classifier como sinal de bloqueio - mas podem ser perdidos quando o contexto é compactado. Para um limite que precisa se manter, use permissions.deny ou permissions.ask em vez de só dizer no chat.

Auto mode e as skills do AgentKit

A pergunta honesta: as skills do AgentKit driblam a supervisão do classifier? Não. As skills do AgentKit são arquivos SKILL.md que rodam pelo próprio sistema nativo de skills do Claude Code - elas não adicionam uma camada de permissão separada e não contornam o classifier. No auto mode, as ações de uma skill são revisadas pelo classifier exatamente da mesma forma que qualquer comando que você mesma digita.

Para não exagerar na afirmação: isto não é "o AgentKit é mais seguro que o auto mode" - não há base para essa afirmação, e fazê-la seria desonesto. O verdadeiro valor do AgentKit está em outro lugar: ele te dá fluxos de trabalho prontos (skills, agents, portões de revisão) em vez de você escrever scripts pontuais por conta própria, mas tudo ainda roda sob exatamente a mesma governança que este artigo acabou de descrever - nada a mais, nada a menos. O AgentKit é um complemento pago que roda dentro do Claude Code (e do Codex); o Claude Code em si já é gratuito ou incluído no plano que você paga. Para uma análise completa, leia o que é o AgentKit e se ele vale a pena.

Perguntas frequentes (FAQ)

O auto mode do Claude Code é seguro?

Mais seguro que a revisão manual pelos números do estudo controlado (89% contra 13,6% dos comandos perigosos pegos), mas não uma garantia absoluta. A própria documentação da Anthropic afirma claramente que o auto mode reduz os prompts de permissão sem garantir segurança - uma lista de verificação e pontos de checagem humanos ainda importam em trabalhos realmente sensíveis.

Como desligo o auto mode?

Pressione Shift+Tab para voltar ao default (Manual) no meio da sessão, ou defina defaultMode em ~/.claude/settings.json (precisa ser o arquivo de escopo do usuário, não o de um projeto). No nível da organização, um administrador pode desativá-lo por completo via permissions.disableAutoMode: "disable" nas configurações gerenciadas.

O auto mode custa mais ou usa mais tokens?

Nos planos Pro/Max/Team, não há cobrança extra pela sobrecarga do classifier. No Enterprise, e em contas usando a API do Claude, o Claude Platform na AWS, o Amazon Bedrock, o Agent Platform do Google Cloud ou o Microsoft Foundry, as chamadas do classifier CONTAM para o seu uso de tokens - uma distinção que vale conhecer antes de lançar o auto mode para uma equipe (verifique ao vivo: consulte a política de preços atual no momento em que você ler isto).

Quais modelos suportam o auto mode?

Na API da Anthropic e no Claude Platform na AWS: Opus 4.6 ou posterior, Sonnet 4.6 ou posterior, ou Fable 5. No Amazon Bedrock, no Agent Platform do Google Cloud, no Microsoft Foundry e nas sessões de gateway dos apps do Claude: apenas Sonnet 5, Opus 4.7 ou posterior e Fable 5. Modelos mais antigos - Sonnet 4.5, Opus 4.5, Haiku e a linha claude-3 - não são suportados em nenhum provedor.

O auto mode impede prompt injection?

Parcialmente, não completamente. O classifier nunca lê os resultados de ferramentas (onde o conteúdo hostil costuma se esconder), o que o torna difícil de manipular diretamente, além de uma sonda no lado do servidor examinar os resultados de ferramentas antes de o Claude lê-los. É uma defesa em camadas, não uma garantia de imunidade.

O Enterprise está em auto mode por padrão?

Não. O Enterprise (junto com sessões em uma chave de API do Claude Console, claude -p/Agent SDK e os provedores Bedrock/Vertex/Foundry) ainda inicia no default (Manual). O auto mode está disponível, mas exige adesão via defaultMode ou configurações gerenciadas pelo administrador, e não é ativado automaticamente como no Pro/Max/Team.

Conclusão

Não pense no auto mode como "desligar todos os avisos por velocidade" - é uma camada diferente de supervisão, não a ausência dela. Entenda os quatro níveis de regra (hard_deny/soft_deny/allow/user intent), saiba onde revisar ações bloqueadas (/permissions → Recently denied) e mantenha o mesmo princípio de sempre: um limite que precisa se manter pertence à configuração (deny/ask), não a uma nota falada que pode sumir na compactação. Para o panorama completo dos seis modos de permissão, leia permissões do Claude Code e configuração segura; para entender o Claude Code do zero, veja o que é o Claude Code.