A Anthropic lançou ontem o "auto mode" no Claude Code. Em vez de pedir permissão para cada arquivo que cria ou cada comando que roda, o agente agora decide sozinho o que é seguro executar.
Funciona assim: antes de cada ação, um classificador analisa se o comando é destrutivo, se tenta exfiltrar dados, ou se executa código malicioso. Se for seguro, roda direto. Se não, bloqueia e eventualmente pede confirmação.
Parece simples, mas a decisão de design é sutil. A Anthropic não removeu as permissões. Ela criou uma camada intermediária entre "aprovar tudo manualmente" e "liberar geral com --dangerously-skip-permissions". É um meio-termo que reconhece algo importante: ninguém aprova 200 permissões por sessão com atenção real. Depois da décima, vira clique automático.
O que me faz pensar é o seguinte. Quando a gente delega decisões de segurança para um classificador, estamos confiando num modelo que avalia se outro modelo está fazendo algo seguro. E a própria Anthropic avisa: o classificador pode deixar passar ações arriscadas e pode bloquear ações inofensivas. Por enquanto, recomendam usar em ambientes isolados.
Para times que já usam Claude Code no dia a dia, isso muda o fluxo de trabalho. Menos interrupções, mais autonomia do agente. Mas levanta uma conversa que todo Tech Lead vai ter que ter com o time: qual nível de autonomia faz sentido pro nosso contexto? Porque "mais rápido" e "mais seguro" nem sempre andam juntos.
Disponível agora no plano Team, em breve no Enterprise. Funciona com Sonnet 4.6 e Opus 4.6.
O classificador troca o tipo de falha na sessão
Aprovação manual falha por fadiga: depois de dezenas de prompts, a pessoa confirma o comando sem ler. Auto mode falha por veredito: o classificador libera o que era arriscado ou bloqueia o que era inofensivo. A Anthropic descreve os dois lados. A pergunta operacional é qual falha o time consegue ver e reverter.
Num fluxo longo (refatorar um módulo, aplicar um review, subir um patch de teste) a fadiga é o risco dominante. Aí o modo faz sentido. Num repositório com segredos, IaC de produção ou acesso a dados reais, o veredito errado custa mais que a interrupção. Nesses casos o padrão continua sendo permissão explícita, ou acceptEdits se o time só quer parar de aprovar mkdir.
--dangerously-skip-permissions continua existindo. Auto mode ainda bloqueia classes de ação (exfiltração, destruição em massa, execução maliciosa) e, se o agente insiste, volta a pedir confirmação. Tratar os dois como equivalentes apaga o ganho de desenho.
Meça por uma semana: quantos prompts de permissão a sessão ainda mostra, quantas ações o classificador bloqueou, quantas o humano reabriu, quantos commits passaram sem ninguém olhar o diff. Sem esse quadro, "menos interrupção" vira impressão.
Isolamento e regras deny ficam fora do modelo
A recomendação da Anthropic é ambiente isolado. O classificador é uma camada, ao lado da borda da rede, do sandbox e do permissions.deny do repositório. Se o agente roda na máquina do desenvolvedor com credenciais de produção, um falso negativo do classificador tem o mesmo alcance que um clique distraído.
Deny rules continuam valendo em qualquer modo. Vale a pena escrever as óbvias antes de ligar auto mode: git push para main, terraform apply, kubectl em cluster compartilhado, leitura de .env para fora do diretório, curl | bash. O classificador cobre uma família de padrões; a regra deny cobre o que o time já sabe que não quer.
Sandbox de Bash e container são controles diferentes do modo de permissão. Dá para combiná-los. Time que já usa worktree ou VM para o agente ganha pouco ao discutir o classificador e ganha muito ao padronizar o isolamento. Time que liga auto mode no laptop com a sessão de nuvem aberta está apostando no modelo.
Se a organização não confia no veredito, disableAutoMode no managed settings tira o modo do ciclo. Isso é decisão de admin, não de hábito individual. Deixar cada pessoa escolher no Shift+Tab produz uma frota com três políticas.
O log precisa mostrar o que passou sem clique
Quando a aprovação some da tela, some também o momento em que o humano via o comando. Alguém ainda precisa reconstruir o que o agente fez. Transcript da sessão, git diff por intervalo, lista de ferramentas chamadas e, se existir, a aba de ações recém-negadas. Sem isso, o postmortem vira "o Claude fez alguma coisa".
Defina o que fica registrado por padrão no repositório de trabalho: branch com prefixo de agente, commits pequenos, nenhum force-push, nenhum segredo no transcript. Auto mode reduz o atrito para o agente escrever; o time decide se isso chega em main por PR ou por push direto.
Pergunta que o Tech Lead faz no review: esta mudança passaria se a pessoa tivesse aprovado cada ferramenta? Se a resposta depende de "o classificador deixou", o PR precisa de mais contexto, não de menos. O modo não é argumento de qualidade.
Em tarefa que toca auth, pagamento ou migração, volte para aprovação manual mesmo que o resto da semana rode em auto. Uma confirmação extra nesses arquivos custa pouco frente a um falso negativo.
Quem liga o modo, quem desliga, em qual plano
No anúncio, o modo chegou como research preview no Team, com Sonnet 4.6 e Opus 4.6, e Enterprise na fila. Admin desliga com disableAutoMode. No CLI o caminho descrito foi claude --enable-auto-mode e ciclo com Shift+Tab. Desktop e VS Code pedem toggle em settings antes de aparecer no seletor.
Isso importa porque "o time já usa Claude Code" não descreve a política. Sem default documentado, cada sessão começa num modo diferente. Vale escrever duas linhas no README interno: modo inicial, repositórios onde auto é permitido, repositórios onde é deny.
Planos e modelos mudam. O que não muda é a necessidade de um dono. Se o admin não decide, o default do produto decide. No lançamento o default era conservador o bastante para pedir opt-in. Depois o produto pode inverter isso. A política do time precisa sobreviver à inversão.
API e sessões -p são outro recorte: não há humano para o fallback quando o classificador bloqueia de novo. Auto mode em CI sem allowlist é um modo de falha diferente do laptop. Trate os dois fluxos separado.
Token e latência entram no custo do fluxo longo
A Anthropic avisou impacto pequeno em token, custo e latência por chamada de ferramenta. Em sessão curta isso some no ruído. Em loop de horas, o classificador é uma inferência extra por ação. Vale olhar a fatura da semana em que o modo ligou, não só o sentimento de "fluiu mais".
O ganho que justifica a conta é tarefa longa com pouca superfície destrutiva: testes, refactors locais, aplicar comentários de review, gerar patches. Deixar o agente "resolver a madrugada sozinho" em cima de produção troca o custo de token por um blast radius que o classificador não limita.
Se o time já paga o plano Team, o modo é mais uma alavanca de permissão, não um produto novo. A conversa útil com engenharia é prosaica: em quais repos ligamos, com qual isolamento, com qual evidência depois de quinze dias. Sem data de revisão, auto mode vira default invisível.
