Introdução
Deixa eu te contar uma coisa que acontece com mais frequência do que você imagina: você está usando o Claude Code em auto mode, trabalhando numa feature complexa, o Claude está voando — lendo arquivos, rodando testes, editando código. Tudo fluindo. Aí você percebe que algo que deveria ter acontecido… não aconteceu. Um git push que sumiu. Uma query no banco que simplesmente não rodou. Um deploy que nunca foi executado.
O que aconteceu? O classifier do auto mode negou a ação. Silenciosamente. O Claude recebeu a negação, tentou outra abordagem, e seguiu em frente. Você nem ficou sabendo.
Na minha experiência com 300+ software houses, esse é o tipo de problema que mata a confiança numa ferramenta. Não é um bug. Não é uma falha. É pior: é uma decisão correta do sistema que te deixou no escuro. O auto mode protegeu você de algo que ele achou perigoso, mas não te contou. É como se o alarme de incêndio detectasse fumaça, desligasse o fogão, e não tocasse a sirene.
O Claude Code v2.1.89 resolve isso com três mudanças que parecem pequenas mas mudam completamente a experiência: notificação visível quando um comando é negado, um tab “Recent” no /permissions que lista tudo que foi bloqueado, e a tecla r para retry direto. Parece UX minor? É a diferença entre um sistema opaco e um sistema que você controla.
Como o Auto Mode funciona (e por que nega coisas)
Antes de entender a mudança, você precisa entender o que está por trás.
O classifier two-stage
O auto mode não é um “aceitar tudo” com filtro. É um sistema de classificação em duas etapas desenvolvido pela Anthropic (deep dive técnico aqui):
Stage 1 — Fast Filter: Uma decisão binária sim/não, sem raciocínio, otimizada pra velocidade. Taxa de false positive: 8.5%. Ou seja, a cada 100 ações seguras, 8-9 são bloqueadas por precaução. É agressivo de propósito — melhor bloquear demais do que de menos.
Stage 2 — Chain-of-Thought: Só roda nas ações flagadas pelo Stage 1. Aplica raciocínio detalhado. Taxa de false positive cai pra 0.4%. Ou seja, o Stage 2 elimina 95% dos bloqueios indevidos do Stage 1.
Na prática, 4 a cada 1.000 ações seguras são bloqueadas por engano. Parece pouco? Se sua equipe roda 500 ações por dia em auto mode, são 2 bloqueios indevidos. Por dia. 10 por semana. 40 por mês. E até agora, todos invisíveis.
O que o classifier bloqueia por padrão
O classifier é conservador. Ele confia no diretório de trabalho e nos remotes do git. Todo o resto é tratado como externo e potencialmente perigoso:
- Download e execução de código (
curl | bash) - Envio de dados sensíveis para endpoints externos
- Deploys em produção e migrations
- Deleção em massa em cloud storage
- Concessão de permissões IAM ou de repositório
- Force push ou push direto pra
main - Destruição irreversível de arquivos que existiam antes da sessão
O problema? Se sua SH usa um bucket S3 interno, um registry Docker privado, ou um GitHub Enterprise que o classifier não conhece — ele bloqueia. Não porque é perigoso, mas porque ele não sabe que é seguro.
O comportamento anterior (silencioso)
Até a v2.1.89, quando o classifier negava uma ação:
- A negação voltava como tool result pro Claude
- O Claude recebia a instrução: “encontre um caminho mais seguro, não tente contornar”
- O Claude silenciosamente tentava outra abordagem
- Nenhuma notificação aparecia pra você
Resultado: você não sabia que algo foi bloqueado, não sabia o quê, e não podia decidir se o bloqueio fazia sentido. O sistema te protegia, mas te deixava cego.
O que mudou na v2.1.89
1. Notificação visível no status area
Agora, quando o auto mode nega um comando, uma notificação aparece no status area do Claude Code. Você vê em tempo real que algo foi bloqueado. Não precisa adivinhar, não precisa investigar depois. O sistema te conta na hora.
É como a diferença entre um antivírus que deleta arquivos silenciosamente e um que mostra: “Bloqueei X porque Y. Quer revisar?”
2. /permissions → Tab “Recent”
O /permissions ganhou uma nova aba: Recent. Ela lista todos os comandos que foram negados durante a sessão atual. Pra cada entrada, você vê:
- O comando que foi tentado
- O motivo do bloqueio
- O contexto da ação
É um log completo de tudo que o classifier decidiu bloquear. Não some, não é efêmero. Fica ali pra você revisar quando quiser.
Isso é especialmente valioso em sessões longas. Você pode estar numa refatoração de 2 horas, e no final abrir /permissions → Recent pra ver se algo importante foi bloqueado que você precisa fazer manualmente.
3. Retry com r
Na tab Recent do /permissions, você pode pressionar r para retry qualquer comando negado. O Claude re-executa a ação, dessa vez com sua aprovação explícita.
Isso fecha o ciclo completo: ver → entender → decidir → agir. O sistema nega, você vê a notificação, abre o Recent, lê o motivo, e se discorda do bloqueio, aperta r. Pronto. O comando roda.
E tem um detalhe importante: quando você aprova um retry, os contadores de denial são resetados. Lembra que 3 denials consecutivos ou 20 totais fazem o auto mode pausar? Ao aprovar via retry, você sinaliza pro sistema que aquele tipo de ação é seguro, e o auto mode continua funcionando normalmente.
Por que isso importa para sua Software House
O problema real: confiança no auto mode
Eu mentoro mais de 300 software houses e vejo o mesmo padrão em todas que adotaram auto mode:
Fase 1 — Empolgação: “Cara, não preciso mais aprovar nada! Produtividade nas alturas!”
Fase 2 — Desconfiança: “Espera, por que o Claude não fez o push? Por que o deploy não rodou? Ele travou?”
Fase 3 — Abandono: “Voltei pro modo default. Auto mode é imprevisível.”
O problema nunca foi o auto mode. Foi a falta de visibilidade. Quando você não sabe que algo foi bloqueado, você assume que o sistema falhou. E quando você assume que o sistema falhou, você desliga ele.
A notificação + Recent + retry não muda o que o auto mode faz. Muda o que você sabe sobre o que ele faz. E isso muda tudo.
False positives em escala
Vamos fazer a conta com números reais:
| Tamanho da equipe | Ações/dia em auto mode | False positives/dia (0.4% FPR) | FP/semana | FP/mês |
|---|---|---|---|---|
| 3 devs | 300 | 1.2 | 6 | 24 |
| 10 devs | 1.000 | 4 | 20 | 80 |
| 30 devs | 3.000 | 12 | 60 | 240 |
Uma SH com 10 devs tem 80 false positives por mês que, até agora, eram completamente invisíveis. 80 vezes por mês o Claude tentou fazer algo seguro, foi bloqueado, e ninguém ficou sabendo.
Agora cada um desses 80 aparece como notificação, fica listado no Recent, e pode ser resolvido com um r. São 80 oportunidades de manter o auto mode funcionando em vez de pausar por frustração.
Configuração proativa: autoMode.environment
A notificação + retry é o tratamento. A prevenção é configurar o classifier pra conhecer sua infra.
Se seus devs estão vendo muitas notificações de bloqueio pra ações no seu GitHub Enterprise, no seu bucket S3, ou nas suas APIs internas, a solução não é ficar apertando r. É configurar o autoMode.environment:
{
"autoMode": {
"environment": [
"Organization: MinhaEmpresa. Software house de ERP industrial.",
"Source control: github.com/minha-empresa e todos os repos",
"Cloud provider: AWS. Trusted buckets: s3://minha-empresa-builds, s3://minha-empresa-artifacts",
"Trusted internal domains: *.internal.minhaempresa.com, api.minhaempresa.com",
"Key internal services: Jenkins em ci.minhaempresa.com, Nexus em nexus.minhaempresa.com"
]
}
}O classifier lê essas entradas como linguagem natural — não é regex, não é pattern matching. Você descreve sua infra como descreveria pra um engenheiro novo. E o classifier passa a tratar esses destinos como confiáveis.
Dica: distribua isso via managed settings pra que toda a equipe tenha a mesma configuração. Assim o classifier conhece sua infra desde o primeiro uso.
O ecossistema de controle do auto mode
A Anthropic tem construído camadas progressivas de controle sobre o auto mode. Cada uma atacando um cenário diferente:
| Feature | Versão | Cenário | Tipo de controle |
|---|---|---|---|
| Auto mode classifier | v2.1.85+ | Ações perigosas | Automático (classifier) |
autoMode.environment |
v2.1.85+ | Infra não reconhecida | Configuração admin |
| PermissionDenied hook | v2.1.88 | CI/CD headless | Programático (hook) |
| Denied notification + Recent + retry | v2.1.89 | Sessão interativa | Visual (UX) |
| Defer hook | v2.1.89 | Pipeline com aprovação | Human-in-the-loop |
Percebe o padrão? Cada feature resolve o problema de “ação bloqueada” num contexto diferente:
- PermissionDenied hook: pro seu CI/CD — quando não tem humano, o hook decide programaticamente se retenta
- Denied notification + retry: pro dev interativo — quando tem humano, ele vê e decide
- Defer hook: pro pipeline com aprovação — pausa e espera humano chegar
- autoMode.environment: prevenção — ensina o classifier sobre sua infra pra nem bloquear
CLI tools pra inspecionar seu auto mode
Se você nunca rodou esses comandos, está voando cego:
# Ver as regras padrão do classifier
claude auto-mode defaults
# Ver sua configuração efetiva (seus settings + defaults)
claude auto-mode config
# Feedback de IA sobre suas regras customizadas
claude auto-mode critiqueO auto-mode defaults mostra as 20+ regras de bloqueio e as exceções built-in. O auto-mode config mostra o que o classifier realmente usa na sua máquina. E o auto-mode critique é particularmente útil: uma IA revisa suas regras customizadas e aponta ambiguidades, redundâncias e possíveis false positives.
Antes de sair apertando r em tudo que aparece no Recent, rode claude auto-mode config e veja se o problema não é falta de configuração.
O que eu penso
Essa feature parece minor. “Notificação de denied commands, grande coisa.” Mas tem uma sutileza que a maioria vai ignorar: ela muda a relação de confiança entre dev e IA.
Até agora, auto mode era um ato de fé. Você ligava e torcia pra funcionar. Quando algo dava errado, você não sabia se foi o Claude que errou, o classifier que bloqueou, ou sua configuração que estava incompleta. O diagnóstico era impossível.
Agora você tem telemetria. Você vê o que foi negado, por que foi negado, e pode decidir se o bloqueio faz sentido. É instrumentação. É observabilidade. É a mesma mentalidade que fez a indústria de software evoluir de “funciona na minha máquina” pra dashboards de APM em tempo real.
O deep dive técnico da Anthropic mostra que o classifier tem 0.4% de false positive rate. Impressionante. Mas 0.4% em escala é barulho constante. E barulho que você não vê vira ruído que você ignora. Agora você vê. E isso faz toda a diferença.
Se sua software house está usando auto mode — ou pensando em adotar — essas são as três coisas que você precisa fazer:
- Configure
autoMode.environment— ensine o classifier sobre sua infra - Rode
claude auto-mode config— veja o que está ativo - Use o Recent tab — monitore o que está sendo bloqueado na primeira semana
Se você quer implementar esse nível de governança de IA na sua software house e não sabe por onde começar, vem conversar. A gente já ajudou centenas de SHs a sair do “IA de brinquedo” pra “IA de produção com controle real”.
Sou Thulio, mentoro 300+ SHs desde 2016.
