AIREITERSe você usa o Claude nos planos Pro, Max ou Team, o modo automático está prestes a virar o ponto de partida para novas sessões. Em 22 de outubro, a Anthropic anunciou que a mudança chegaria na semana seguinte à maioria dos aplicativos Claude. Administradores do Enterprise recebem um aviso por e-mail antes, enquanto a API e as plataformas de nuvem continuam exigindo ativação manual por enquanto.
O que mudou em 22 de outubro — e o que continua igual
A atualização de 22 de outubro amplia para a maioria dos aplicativos Claude uma mudança que começou no Claude Code. Desde 14 de agosto de 2026, novas sessões do Claude Code nos planos Pro, Max e Team passaram a começar no modo automático, com um aviso único para quem havia fixado outro modo como padrão. Na mesma annoucement da Anthropic, a empresa diz que o modo automático será ativado como padrão na semana seguinte para novas sessões da maioria dos aplicativos Claude nos planos Pro, Max e Team. Administradores do Enterprise serão avisados por e-mail antes da alteração chegar às suas organizações.
Três limites permanecem inalterados. Administradores do Team que fixaram um modo padrão nas configurações gerenciadas não mudam a experiência de seus usuários. Enterprise, Claude API, Claude Platform on AWS, Amazon Bedrock, Google Cloud's Agent Platform e Microsoft Foundry continuam no modelo opt-in, com previsão de que o modo automático vire padrão nessas superfícies no próximo mês. Preferências pessoais fixadas também continuam valendo, a menos que o usuário aceite o aviso único de mudança.
A versão instalada também influencia o que aparece para cada pessoa. Segundo o acompanhamento das notas de versão, o Claude Code v2.1.283 e posteriores exibem o modo automático como opção inicial integrada nas sessões interativas do terminal e do VS Code quando nenhum modo de permissão foi configurado. Ainda assim, uma instalação nova pode abrir no modo manual no primeiro lançamento se os sinalizadores de recurso ainda não tiverem chegado.
Como o modo automático do Claude toma decisões
No modo automático, cada chamada de ferramenta passa por um classificador separado, em vez de pedir aprovação a cada etapa, segundo o anúncio da Anthropic. O classificador libera ações rotineiras e bloqueia aquelas consideradas irreversíveis, destrutivas ou direcionadas para fora do ambiente de trabalho. Em seguida, o Claude procura um caminho mais seguro ou pede instruções diretamente. Se a sessão acumular três bloqueios consecutivos ou vinte bloqueios no total, ela volta a exigir aprovações manuais.
As regras explícitas de permissão continuam sendo avaliadas antes do classificador. Entradas em permissions.deny bloqueiam a ação imediatamente, sem que uma decisão do classificador possa substituí-las, enquanto entradas em permissions.ask sempre exibem um pedido de confirmação. Regras amplas que liberam execução arbitrária de código, como Bash(python:*), são ignoradas enquanto o modo automático está ativo, evitando que comandos passem completamente ao largo do classificador.
O classificador considera mais contexto do que uma lista estática de permissões. A Anthropic afirma que ele verifica o destino de um git push ou pull request — privado, confiável ou público — antes de executar a ação. Também consulta o estado atual do git antes de comandos destrutivos, como git reset --hard.
Conteúdo externo vindo de páginas da web, arquivos ou saídas de ferramentas passa por uma verificação contra prompt injection. Quando algo parece uma tentativa de injeção, um alerta é acrescentado ao contexto do Claude. Exfiltração de dados fica em uma categoria de bloqueio absoluto e nunca é aprovada automaticamente; para executar esse tipo de ação, é preciso mudar de modo ou rodar o comando diretamente.
Por que a Anthropic diz que o modo automático é melhor do que clicar em “Aprovar”
A Anthropic apresenta a mudança como uma melhoria de usabilidade sustentada por dados. Usuários aprovam 97% dos pedidos de permissão no Claude Code, mas rejeitam 39% dos planos apresentados. Para a empresa, essa diferença sugere que muitos cliques em prompts individuais acontecem por reflexo, e não após uma análise real. Em junho de 2026, 49,5% dos usuários ativos de CLI haviam escrito manualmente uma regra de permissão para Bash, 62% tinham usado bypassPermissions ou “não perguntar novamente”, e 25% das sessões interativas começaram no modo de bypass.
Um estudo controlado transformou esse comportamento em números. A Anthropic contratou 1.053 testadores pagos por meio de uma empresa de pesquisa, substituiu um pedido de permissão por sessão por um comando claramente perigoso e registrou a reação dos participantes. O texto perigoso não executava nada. Pessoas identificaram o comando em 13,6% dos casos (143 de 1.053), enquanto o modo automático bloqueou 89% dos mesmos comandos (937 de 1.053).
Na comparação direta, o modo automático bloqueou 800 comandos que os participantes aprovaram, enquanto as pessoas bloquearam apenas 6 comandos liberados pelo modo automático. O desempenho humano também caiu de cerca de 17% no início para aproximadamente 5% depois de 50 ou mais prompts anteriores; o modo automático permaneceu estável.
Dados de produção e de terceiros apontam na mesma direção, segundo o anúncio da Anthropic. Entre sessões sinalizadas de maio a junho de 2026, 6,3% das sessões aprovadas manualmente continham algum dano em nível de produção que o usuário não havia solicitado explicitamente, contra 2,4% das sessões em modo automático. A Trajectory Labs executou 72 cenários de prompt injection dez vezes cada: nenhuma das 720 tentativas foi bem-sucedida contra Claude Fable 5, Opus 5 ou Sonnet 5 no modo automático, contra uma taxa de sucesso de 5,83% diante do GPT-5.6 Sol no modo Codex Auto-review.
Em testes de red team, a Apollo Research reduziu a taxa de falhas do classificador de 12% para 7% depois de reforçá-lo com informações sobre visibilidade do repositório, estado do git e regras de tratamento de dados. A Anthropic também cita três bloqueios internos que evitaram problemas — um fallback de upload para fora da rede que iria parar em um site público de paste, a finalização em massa de processos em cerca de 2.000 pods que ameaçava jobs de treinamento em GPUs e uma escalação ampla demais de privilégios de faturamento — além de cerca de 25% mais pull requests entre usuários corporativos, incluindo Adobe, Nuro, Gusto e Garner Health.
O que aparece na prática depois da mudança
Relatos de usuários acrescentam atritos que o anúncio não enfatiza. As principais reclamações envolvem tarefas rotineiras: commits, limpeza de worktrees, operações via SSH e em servidores e comandos de deploy que acabam bloqueados ou voltam a pedir autorização no modo automático.
“o classificador automático está pedindo permissão até para as operações mais básicas e ainda se recusa a executá-las mesmo depois que dou permissão explícita.” — u/dfritter4 no r/ClaudeCode
O ponto mais irritante é quando uma aprovação não consegue reverter uma negativa. Vários usuários relatam aprovar uma ação e, ainda assim, ver o ambiente recusá-la. O resultado é ter de mudar para o modo manual ou abrir o terminal.
“Passei por situações em que precisei voltar ao modo manual, mandar o agente continuar, aprovar manualmente e depois voltar ao automático.” — u/phoenixmatrix no r/ClaudeCode
Falhas do classificador são uma categoria diferente das negativas de segurança. Em um incidente que afetou vários projetos, usuários viram a mensagem “The server-side auto mode classifier gave no verdict” em diferentes projetos, embora a página de status não mostrasse nenhuma ocorrência. A solução temporária foi mudar para o modo manual até o serviço voltar.
Problemas de qualidade completam a lista, especialmente na discussão sobre a mudança do padrão. Alguns usuários se preocupam menos com comandos destrutivos do que com o Claude complicando demais a implementação, desviando do escopo ou criando uma arquitetura fraca enquanto trabalha de forma autônoma. Esse atrito recorrente leva uma minoria de volta ao --dangerously-skip-permissions, protegido apenas por git, contêineres e revisão antes do merge.
Como manter checkpoints sem abandonar o modo automático do Claude
A regra padrão que mais surpreende desenvolvedores é a liberação de pushes e da criação de pull requests no modo automático, inclusive para a branch em que o trabalho está sendo feito e para a branch padrão. Force pushes, segredos que aparecem em commits e reescritas de histórico continuam bloqueados de forma flexível e exigem uma intenção explícita. Dizer “limpe o repositório” não autoriza um force push; nomear a ação exata, sim. Nomes de branches que indicam destinos de deploy, como production, release ou gh-pages, são avaliados individualmente como deploys de produção.
Para manter o modo automático em todo o resto, mas exigir confirmação para pushes e PRs, adicione regras ask com escopo de conteúdo, avaliadas antes do classificador:
{ "permissions": { "ask": ["Bash(git push *)", "Bash(gh pr create *)"] } }Quando um limite não pode ser ultrapassado, use permissions.deny em vez de instruções no chat. Um “não faça push até eu revisar” pode desaparecer quando o contexto é compactado; uma regra ask ou deny continua valendo. Negativas repetidas para um destino conhecido normalmente indicam que o classificador não reconhece a infraestrutura. Nesses casos, nomeá-la em autoMode.environment, nas configurações do usuário ou gerenciadas, ajuda.
Consulte as negativas na aba Recently denied de /permissions e pressione r para tentar uma novamente. Para auditar a configuração, use claude auto-mode config, claude auto-mode defaults e claude auto-mode critique. Há duas armadilhas importantes: regras allow estreitas, como Bash(npm test), são resolvidas antes do classificador e podem deixar um argumento destrutivo passar sem análise; no v2.1.193 ou posterior, defina autoMode.classifyAllShell como true para classificar cada comando de shell, aceitando algum custo adicional de latência. Além disso, listas personalizadas de allow, soft_deny, hard_deny ou environment substituem completamente as regras integradas, a menos que mantenham a entrada literal "$defaults".
Desative quando precisar
Trocar de modo durante uma sessão exige apenas um comando. No CLI, pressione Shift+Tab para alternar entre os modos ou use o seletor de modo no aplicativo para desktop. Também é possível iniciar a sessão com claude --permission-mode manual. A alteração vale apenas para a sessão atual.
Para fixar o modo manual permanentemente, salve essa preferência nas configurações do usuário em ~/.claude/settings.json:
{ "permissions": { "defaultMode": "manual" } }O valor manual é um alias de default no v2.1.200 e posteriores. O arquivo de repositório .claude/settings.json não pode conceder nem fixar o modo automático: defaultMode: auto e bypassPermissions definidos ali são ignorados. Portanto, a ativação ou desativação deve ser feita nas configurações do usuário ou nas configurações gerenciadas. Administradores da organização fixam o padrão da empresa usando defaultMode nas configurações gerenciadas ou removem completamente o modo automático com permissions.disableAutoMode definido como "disable". Desde o v2.1.251, essa opção também se aplica a sessões que já estão em andamento. O classificador do modo automático também analisa comandos de shell durante o modo de planejamento quando useAutoModeDuringPlan está ativado — e essa é a configuração padrão onde o modo automático está disponível.
Deixar ligado ou fixar o modo manual?
A melhor escolha depende do potencial de impacto, não do entusiasmo com a novidade. Trabalhos exploratórios individuais, refatorações locais isoladas, atualizações de dependências, geração de testes e limpeza de documentação, sempre com diff e suíte de testes como barreiras, combinam naturalmente com o modo automático. Em repositórios compartilhados, há uma condição extra: caminhos protegidos, bloqueios rígidos para segredos e manifestos de deploy e o uso de sandboxes ou branches descartáveis definidos antes da adoção.
| Fluxo de trabalho | Modo recomendado | Proteção para configurar primeiro |
|---|---|---|
| Exploração individual, edições reversíveis | Modo automático | Revisar Recently denied + criar o hábito de tentar novamente com r |
| Repositório de equipe, trabalho rotineiro em funcionalidades | Modo automático com checkpoints para push | ask em git push * e gh pr create * |
| Deploys de produção, IAM, segredos, resposta a incidentes | Modo manual ou de planejamento + revisão humana do diff | Regras deny para limites que nunca podem ser ultrapassados |
| Sessões reguladas ou elegíveis para HIPAA | Manual (o automático continua disponível para ativação) | defaultMode gerenciado + auditoria de quem pode alterá-lo |
Atualize o CLI e as integrações com editores para a mesma linha de versões, defina um único padrão gerenciado, estabeleça caminhos protegidos e bloqueios rígidos, faça as primeiras execuções em devcontainers ou VMs isoladas com dados falsos e mantenha git diff, execuções de testes e uma revisão real como etapas obrigatórias antes do merge. Segundo a Anthropic, cerca de 10% das sessões desde meados de maio incluem uma negativa do classificador.
Perguntas frequentes
O modo automático do Claude custa tokens extras?
Não há cobrança adicional nos planos Pro, Max e Team, segundo a Anthropic, com efeito a partir de 7 de agosto de 2026. Sessões Enterprise, da API e de plataformas de nuvem continuam contabilizando as chamadas do classificador feitas no lado do cliente no uso de tokens.
O que fazer quando o modo automático bloqueia um trabalho legítimo?
Abra /permissions, consulte a aba Recently denied e pressione r para tentar novamente a ação negada. Se o mesmo destino continuar sendo bloqueado, nomeie a infraestrutura confiável em autoMode.environment.
Por que um push para main passou sem pedir confirmação?
Por padrão, o modo automático permite pushes para qualquer branch do repositório em uso, incluindo a branch padrão. Adicione Bash(git push *) a permissions.ask para exigir um checkpoint ou a permissions.deny para criar um limite rígido.
O modo automático é seguro para trabalhos de produção?
A Anthropic apresenta o modo automático como mais seguro do que clicar habitualmente em aprovações, mas continua recomendando revisão humana para mudanças de alto impacto na infraestrutura de produção. Mantenha o modo automático em trabalhos reversíveis e prefira o modo manual ou de planejamento para deploys, segredos e IAM.
Como diferenciar uma negativa de segurança de uma falha do classificador?
Uma negativa de segurança informa o motivo do bloqueio e normalmente leva o Claude a sugerir outra abordagem. Já uma falha de “no verdict” bloqueia gravações e ações Bash em vários projetos ao mesmo tempo. Consulte /status para verificar a linha do servidor do modo automático e tente o modo manual se houver suspeita de indisponibilidade.
O modo automático funciona da mesma forma no Claude Code e nos aplicativos Claude?
O mecanismo do classificador é compartilhado, mas o cronograma de adoção é diferente: o Claude Code mudou primeiro, em 14 de agosto; os aplicativos Claude vêm na semana seguinte; e as superfícies Enterprise e API continuam no modelo opt-in até que os administradores sejam avisados.
Leia também: guia do modo automático do OpenAI Codex