Até onde deixar o Claude Code rodar comandos sozinho no terminal?

Aprovar cada comando cansa, liberar tudo assusta

E é bem nesse meio termo desconfortável que quase todo vibe coder trabalha hoje

Só que a pergunta mudou de figura: agora existe um modo em que um SEGUNDO modelo revisa cada ação antes dela rodar, e ele virou o padrão das novas sessões pra boa parte dos usuários

Ou seja, "até onde deixar o agente solto" deixou de ser papo de confiança e virou papo de configuração

Nesse post eu vou te dar critério de decisão, não opinião solta: o que mudou nas permissões do Claude Code, como o classificador decide, o que é seguro automatizar, o que sempre merece um olho humano e como montar suas travas antes de soltar a rédea

Bora? 😀

O que mudou: o auto mode virou o padrão das novas sessões

O auto mode passou a ser o modo de permissão padrão das novas sessões do Claude Code para quem está nos planos Pro, Max e Team

O anúncio saiu em 7 de agosto de 2026 e a mudança valeu a partir de 14 de agosto de 2026

E segue valendo hoje, sem evidência de reversão

Quem NÃO foi trocado automaticamente:

Se você já tinha definido um defaultMode nos seus settings ou escolhido um modo pelo seletor, nada mudou pra você

Se o admin do seu Team definiu o default nas managed settings, também nada muda

A troca pegou quem não tinha default configurado, e essa galera recebeu aviso dentro do produto

E fora de Pro, Max e Team?

Continua opt-in

Isso vale no Claude Enterprise, na Claude API, no Claude Platform na AWS, no Amazon Bedrock, no Google Cloud Agent Platform e no Microsoft Foundry

A justificativa declarada é simples: dar tempo dos admins revisarem antes

Tem mais um detalhe que mexe no bolso: o classificador consome um punhado de tokens extras por tool call, e esse overhead deixou de ser cobrado dos usuários de Pro, Max e Team

O aviso antigo de que o auto mode custaria um pouco mais foi removido do primeiro uso nesses planos

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Os modos de permissão do Claude Code lado a lado

Antes de decidir qualquer coisa, você precisa saber o que cada modo libera sozinho

Porque o modo é o que define o que roda SEM te perguntar

Dá pra trocar de modo no meio da sessão, não precisa reiniciar nada: Shift+Tab no CLI, indicador de modo no VS Code e seletor de modo no Desktop

O plan mode também entra prefixando um prompt único com /plan, quando você quer só aquela resposta em modo pesquisa

Tome cuidado com um detalhe: o bypassPermissions só aparece no ciclo de modos se a sessão foi iniciada com a flag correspondente, ou seja, –permission-mode bypassPermissions, –dangerously-skip-permissions ou –allow-dangerously-skip-permissions

E mesmo lá dentro existe trava residual: regras deny e regras ask explícitas continuam valendo em TODOS os modos, inclusive no bypassPermissions

Se um deny casa, a ferramenta é bloqueada do mesmo jeito

Se um ask casa, a chamada cai em confirmação do mesmo jeito

Quem revisa no auto mode não é você: como o classificador decide

Essa é a parte que muita gente não entendeu ainda

No auto mode, quem olha cada ação antes dela rodar é um modelo, não você

O classificador analisa a tool call antes da execução, deixa passar o que julga seguro e bloqueia o arriscado, redirecionando o Claude pra outra abordagem

Como ele funciona por dentro:

Ele roda em Sonnet 4.6 e trabalha em dois estágios

Primeiro vem um filtro rápido de um token só: "não" libera a ação na hora, "sim" é o sinal de bloqueio

E só quando esse sinal aparece o classificador segue pro segundo passo, com cadeia de raciocínio

Se você conhece um linter que roda rápido em tudo e só chama a análise pesada no que cheirou mal, é bem essa a ideia

O que ele bloqueia:

As categorias são declaradas pela própria Anthropic:

• Destruir ou exfiltrar: force-push por cima do histórico, deleção em massa de cloud storage, envio de dados internos pra fora
• Exploração de credenciais: varrer variáveis de ambiente e arquivos de config atrás de tokens de outro escopo
• Parâmetro inferido pelo agente: consultar um cluster e apagar o item de nome mais parecido (esse aí é sinistro)
• Triagem de prompt injection: conteúdo trazido de fontes externas passa por checagem

E se ele bloquear demais?

Tem freio automático, e ele devolve o volante pra você

3 bloqueios seguidos ou 20 bloqueios no total da sessão fazem o auto mode pausar, e o Claude Code volta a perguntar

Qualquer ação liberada zera o contador de seguidos, mas o contador total persiste na sessão

Os limiares não são configuráveis, e aprovar a ação pedida retoma o auto mode

Os números que sustentam a decisão

Aqui é onde o papo sai do achismo

A motivação declarada do recurso é a fadiga de aprovação: 93% dos prompts de permissão são aprovados pelos usuários do Claude Code

E quanto mais aprovações a pessoa vê, menos atenção ela dá a cada uma

No teste contra comandos perigosos, a diferença foi grande: o auto mode bloqueou 89% (937 de 1.053), enquanto os testadores humanos pegaram 13,6% (143 de 1.053)

No confronto direto sobre os mesmos comandos, a assimetria fica ainda mais clara: o auto mode bloqueou 800 comandos que um humano tinha aprovado, e os humanos bloquearam apenas 6 que o auto mode deixou passar

Agora a parte honesta, que eu acho MUITO massa terem publicado: o classificador erra

A taxa de falso negativo é de cerca de 17% (ele pega aproximadamente 83% dos comportamentos exagerados antes de executarem) e a de falso positivo é de cerca de 0,4% dos comandos benignos bloqueados

Em sessões reais, com severidade de nível 7 ou maior, 6,3% das sessões com aprovação manual continham uma ação prejudicial que o usuário não tinha pedido, contra 2,4% das sessões em auto mode

Tradução: o humano clicando "aprovar" no piloto automático é pior revisor do que o classificador

Mas 17% de falso negativo não é zero, e é por isso que a próxima seção existe

O que é seguro automatizar e o que sempre merece um olho humano

O critério que eu uso tem três eixos, e recomendo que você adote os mesmos:

Reversibilidade (dá pra desfazer com git checkout?), raio de alcance (isso sai da minha máquina?) e parâmetro inferido (quem escolheu o alvo do comando, eu ou o agente?)

Com esses três, cada cenário praticamente escolhe o modo sozinho

Explorar código desconhecido: plan

Você não quer edição nenhuma aqui, quer entendimento

O plan mode pesquisa e propõe sem fazer, então o raio de alcance é zero

Refatorar em repositório limpo: acceptEdits

É reversível, o alcance não passa do disco e o git diff é a sua rede de segurança

A condição é essa: repositório LIMPO antes de começar, senão você não separa o que foi você do que foi o agente

Rodar testes e build local: auto

Repetitivo, local, reversível e chatíssimo de aprovar um por um

É o cenário que o auto mode foi feito pra resolver

Infra em nuvem, histórico remoto e credenciais: deny ou ask fixos

Aqui o raio de alcance sai da sua máquina, e boa parte não tem ctrl+Z

Force-push por cima do histórico, deleção em massa em storage, leitura de arquivo de credencial: nada disso deveria depender do julgamento de nenhum modelo, nem do meu depois de 4 horas de código

Se você já pensa em delegar o Git pro agente, é bem nessa fronteira que vale desenhar a linha

Ambiente descartável e isolado: bypassPermissions, só onde a doc autoriza

A própria documentação restringe o –dangerously-skip-permissions a ambientes isolados como containers, VMs ou dev containers sem internet

Mesmo lá, as regras ask explícitas continuam pedindo confirmação, e remoções com rm e rmdir apontando pra caminho crítico também

Não é convite pros rm -rf da vida na sua máquina principal, beleza?

Como montar suas travas antes de soltar a rédea

Agora a parte prática

A ordem importa: primeiro você desenha o que NUNCA pode rodar, depois escolhe o modo

Fazer o contrário é como configurar o firewall depois de abrir a porta 😛

1. Abra o painel de regras com /permissions

Ele lista todas as regras de permissão e mostra de qual arquivo settings.json cada uma veio

Dá pra abrir com o Claude trabalhando, e ao adicionar ou remover uma regra a mudança passa a valer a partir da próxima tool call do mesmo turno

O erro comum deste passo: achar que a regra veio do seu arquivo pessoal quando ela veio do projeto ou de cima, e ficar editando o lugar errado sem entender por que nada muda

2. Entenda os três tipos de regra antes de escrever qualquer uma

allow deixa a ferramenta rodar sem aprovação manual

ask pede confirmação sempre que o Claude Code tentar usar aquela ferramenta

deny impede o uso da ferramenta

O erro comum deste passo: usar allow como se fosse documentação de intenção, enchendo o arquivo de permissões que você nunca precisou liberar

3. Respeite a ordem de avaliação: deny, depois ask, depois allow

O primeiro match decide, e a especificidade da regra NÃO muda essa ordem

Então um deny amplo como Bash(aws *) bloqueia inclusive o que casa com um allow mais estreito como Bash(aws s3 ls)

O erro comum deste passo: tentar fazer exceção por allowlist em cima de um deny largo

Não funciona: deny não aceita exceção

Se você quer liberar o aws s3 ls, o seu deny precisa ser mais estreito desde o começo

4. Escolha a camada certa do arquivo de settings

A precedência é essa, da mais alta pra mais baixa: managed settings (ninguém sobrescreve, nem argumento de linha de comando), depois argumentos de linha de comando, depois local (.claude/settings.local.json na raiz do repo, só pra você), depois project (.claude/ no repositório, vale pros colaboradores) e por fim user (~/.claude/, vale em todos os projetos)

O erro comum deste passo: colocar no user settings uma liberação que só fazia sentido em UM projeto

E vale lembrar: um deny de qualquer camada não é desfeito por um allow de outra

Se o seu user settings permite e o project settings nega, o deny bloqueia

5. Escreva o arquivo com os deny primeiro

Um esqueleto mínimo pra você adaptar:

{
  "permissions": {
    "defaultMode": "plan",
    "deny": ["Bash(aws *)"],
    "ask": ["Bash(git push *)"],
    "allow": ["Bash(npm test)"]
  }
}

O defaultMode define em que modo as sessões começam

Se você quer impedir o uso do auto mode de vez, defina permissions.disableAutoMode como "disable" em qualquer arquivo de settings

Os dois são bem mais úteis em managed settings, onde não podem ser sobrescritos

O erro comum deste passo: colocar disableAutoMode no arquivo do usuário achando que virou política do time

Se não está em managed settings, alguém sobrescreve

6. Ensine o classificador sobre o SEU ambiente

O auto mode é configurável, e isso é subutilizado

Dá pra informar quais repositórios, buckets e domínios são confiáveis, definir contexto de ambiente, sobrescrever as regras padrão de bloqueio e de liberação e inspecionar a configuração efetiva pelos subcomandos auto-mode da CLI

O padrão já traz mais de vinte regras de bloqueio, então você está mexendo em cima de uma base, não do zero

O erro comum deste passo: sair sobrescrevendo regra padrão de bloqueio pra parar de ver interrupção, em vez de declarar o que de fato é confiável no seu contexto

7. Ligue o sandbox como camada complementar

Permissões e sandbox NÃO são a mesma coisa

Permissões controlam quais ferramentas o Claude Code usa e quais arquivos ou domínios ele acessa

O sandbox aplica restrição de sistema operacional ao acesso do Bash a arquivos e rede, e vale só pra comandos Bash e seus processos filhos

Ele liga com enabled e se ajusta pelos sub-objetos filesystem, network e credentials

Na primeira vez que um comando precisa de um domínio de rede novo, o Claude Code pede aprovação, ou, em auto mode, manda a requisição pro classificador

O erro comum deste passo: achar que o sandbox cobre tudo

Ele não cobre: fora do Bash e dos filhos dele, quem manda são as suas regras de permissão

O que aprendi deixando o Claude Code trabalhar até terminar

Esse papo de permissão fica bem mais concreto quando você deixa o agente rodando por muito tempo sem olhar

Foi o que eu fiz testando o /goal, o comando que deixa o Claude Code trabalhando sozinho até concluir uma tarefa

A primeira coisa que aprendi é que um bom prompt de goal precisa de um estado final MENSURÁVEL e de uma forma do agente provar que chegou lá

Restrição (o que ele não pode fazer) é opcional na hora de escrever, mas na prática é ela que te salva quando ninguém está olhando

No vídeo eu mostro um goal real: pedi uma verificação de segurança do projeto tendo como condição de encerramento a criação de um arquivo com as considerações

Condição de encerramento verificável, saída em arquivo, fim

Quando testei a pausa, veio a surpresa: ela não é imediata

O agente termina o que está fazendo antes de parar, e eu vi o próprio Claude responder que tinha recebido a instrução e que ia encerrar a análise em curso

Eu li isso como proteção contra deixar coisa pela metade, e concordo

Mas repara no que isso significa pro seu risco: entre você mandar parar e ele parar de verdade, ainda cabe ação

O cancelamento tem o mesmo comportamento, ele acontece na interação seguinte, então tem que esperar um pouquinho

Depois eu retomei o trabalho e o goal voltou de onde tinha parado, e também testei marcar como concluído na mão, que é útil quando o objetivo já foi atingido na prática e você não quer o agente repetindo ciclo desnecessário

Dá pra listar o que está rodando, e dá pra ter mais de um goal ao mesmo tempo

Eu rodei dois em paralelo, uma análise de segurança e uma de performance, cada uma gerando seu arquivo de saída, só observando o trabalho acontecer

Mto massa de ver, e é aí que a ficha cai sobre permissão: com dois agentes rodando, você não está mais revisando ação por ação, você está confiando nas travas que montou ANTES

Por isso eu passei a fazer sempre a mesma coisa antes de disparar execução longa: repositório limpo, condição de encerramento clara, e os deny do que nunca pode rodar já escritos

O modo escolhido muda o resultado na prática

Em plan mode, execução longa não faz sentido nenhum

Em auto mode, ela flui e o classificador segura o que for exagero

Em bypassPermissions fora de ambiente isolado, você está apostando

Duas observações honestas: os exemplos que mostrei terminam numa única passada, e o uso realmente interessante é tarefa REPETITIVA, tipo rodar teste, corrigir e repetir até tudo passar

E o Claude Code precisa estar atualizado pro recurso aparecer, eu rodei a atualização na frente da câmera antes de usar

Se o teu interesse é justamente deixar o agente rodando sozinho por longos períodos, esse é o tipo de trabalho onde a configuração de permissão deixa de ser detalhe e vira o produto

No vídeo acima tu vê o goal sendo criado do zero, a pausa e a retomada acontecendo em tempo real e os dois goals rodando em paralelo

Veredito: onde traçar a linha

Minha posição, sem enrolação

O auto mode é a escolha padrão razoável pra trabalho LOCAL em repositório versionado

Os números não deixam muito espaço pra discussão: 89% contra 13,6% de bloqueio de comando perigoso, 800 contra 6 no confronto direto, e menos ação prejudicial não pedida em sessão real (2,4% contra 6,3%)

O humano médio, aprovando 93% do que aparece, não é o revisor que ele acha que é

Mas o auto mode NÃO substitui regra deny e regra ask pro que sai da sua máquina

O classificador erra em cerca de 17% dos casos, e o freio de 3 bloqueios seguidos ou 20 na sessão existe justamente pra devolver a decisão pra você quando a coisa começa a ficar estranha

Se você aceitar tudo no automático quando o freio puxa, você desfez o benefício inteiro

E pra quem o default manual continua fazendo mais sentido? Pra quem trabalha em ambiente onde uma ação errada não é reversível: produção, infra em nuvem, credencial de outro escopo, histórico remoto compartilhado

Lá o certo não é escolher entre auto e manual, é escrever o deny e parar de depender de escolha

Conclusão

O dilema "aprovar tudo ou liberar tudo" era falso desde o começo

A decisão real não é sobre quanto você confia no modelo, é sobre o que você configurou antes de começar a sessão

Seu próximo passo é bem concreto e leva uns 10 minutinhos:

Abre o /permissions e olha de onde vêm as regras que você já tem hoje

Escreve os deny do que nunca deve rodar na sua máquina, na camada certa

E SÓ DEPOIS escolhe em que modo as suas sessões vão começar

Nessa ordem, o auto mode vira ganho de produtividade

Na ordem inversa, ele vira sorte…

Até o próximo post! 😀