Quando o Claude Code deve perguntar e quando deve decidir sozinho?

Tem dois tipos de agente que cansam: o que trava a cada comando pedindo permissão pra respirar, e o que sai fazendo tudo sozinho e só te avisa depois que já mexeu em meio projeto

O bom é que isso não é personalidade da ferramenta, é configuração

A autonomia do Claude Code se calibra em quatro camadas: o modo de permissão da sessão, as regras que você deixa escritas nos arquivos de configuração, as instruções do próprio pedido e os hooks, que disparam antes da checagem de modo

Neste post eu vou montar contigo essa calibragem por tipo de tarefa, deixando claro quais decisões ele pode tomar e quais ele tem que devolver pra você, beleza?

Os modos de permissão do Claude Code e quanto cada um pergunta:

Parada rápida pra definir o termo, porque tudo depende dele

Modo de permissão é o ajuste que define o quanto o Claude Code pede confirmação antes de agir

São seis modos disponíveis: default, acceptEdits, plan, dontAsk, bypassPermissions e auto

Formação Recomendada

Formação Claude Code

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

• 118 aulas
• 4 projetos
• 9h 33min

Conhecer formação

O bypassPermissions é ativado com --permission-mode bypassPermissions (ou com --dangerously-skip-permissions), e essa flag volta a aparecer lá no passo 7

Uma nota que vale pro post inteiro: regras deny e ask explícitas são avaliadas ANTES do classificador do modo auto

Ou seja, o que você proibiu na mão continua proibido mesmo no modo mais espertinho

E se o seu objetivo é apenas reduzir prompt, a própria documentação sugere o auto mode no lugar do bypassPermissions

O que ter pronto antes de calibrar a autonomia:

Antes de soltar a rédea, quatro coisas precisam estar de pé

• Repo com versionamento, sempre. Edição automática só é confortável quando dá pra voltar atrás
• Saber onde mora a configuração. Os arquivos de projeto ficam no repo em .claude/, sendo que CLAUDE.md, .mcp.json e .worktreeinclude ficam na raiz. Os arquivos globais ficam em ~/.claude/ e valem pra todos os projetos
• Lembrar que o settings.json é JSON estrito. Comentário com // ou vírgula sobrando é erro de sintaxe, e o Claude Code reporta o arquivo como Settings Error na próxima inicialização
• Ter a ordem de avaliação na cabeça: deny, depois ask, depois allow

Essa ordem é o que te salva dentro do settings.json: entre as regras que você escreve ali, o deny vence o ask e o allow, então proibição não é derrubada por nenhuma liberação que veio depois

Acima dessas regras ainda existe o hook PreToolUse, que dispara antes da checagem de modo e é a camada mais externa de todas (volto nele no passo 7)

Se você já brincou com skills, comandos e subagentes, esse diretório .claude/ já é velho conhecido seu

Como calibrar o nível de autonomia passo a passo:

O roteiro abaixo vai do mais fechado pro mais solto

A ideia é subir um degrau por vez, e não pular direto pro modo que aprova tudo

1. Comece toda tarefa incerta no modo plan

Tem três formas de entrar: Shift+Tab, o comando /plan antes do pedido, ou já abrir a sessão assim:

claude --permission-mode plan

Nessa fase ele explora o código e faz perguntas antes de propor o plano

Aproveite essas perguntas, é ali que você corrige o rumo barato, antes de qualquer arquivo ser tocado

O erro comum deste passo: tratar o modo plan como burocracia e pular direto pra execução em tarefa que você ainda não sabe explicar

2. Escolha a saída do plano com consciência

Quando você aprova o plano, o Claude Code oferece opções de como seguir, e a sua escolha define o modo de permissão da execução: aprovar e usar o modo auto, aprovar e revisar cada edição manualmente, ou continuar planejando

E se o plano não te convenceu? Pressionar Shift+Tab de novo sai do modo plan sem aprovar nada

O erro comum deste passo: clicar na primeira opção no automático, e só perceber depois que a execução inteira ficou num modo mais solto do que você queria

3. Escreva no pedido o que ele decide e o que ele devolve

Modo de permissão controla ferramenta, não critério

Então diga no texto: nome de variável, organização de arquivo e estrutura de teste ele resolve sozinho; escolha de biblioteca, nome de rota pública e mudança de contrato ele para e pergunta

O canal de devolução já existe: a ferramenta AskUserQuestion, em que o Claude te manda a pergunta como opções de múltipla escolha, cada uma com um label curto e uma description, mais a propriedade multiSelect quando dá pra escolher mais de uma

Decisão visual entra na mesma lista, e é por isso que vale descrever a tela no prompt em vez de deixar ele adivinhar layout sozinho

O erro comum deste passo: pedir "me pergunte se tiver dúvida" e achar que resolveu. Dúvida é vaga, lista de decisões é concreta

4. Fixe no CLAUDE.md o que já é decisão fechada

Esse arquivo markdown fica na raiz do projeto e é lido no início de cada sessão

Ele serve pra padrões de código, decisões de arquitetura, bibliotecas preferidas e checklists de revisão

Pensa assim: toda pergunta que você já respondeu três vezes não deveria mais ser pergunta, deveria ser linha no CLAUDE.md

O erro comum deste passo: escrever um textão genérico de boas intenções ali. Vale mais uma decisão específica ("formulário novo usa a lib X, não escreve validação na mão") do que um parágrafo bonito sobre qualidade

5. Transforme o repetitivo em allow e o perigoso em deny

Aqui você tira do caminho o que sempre é aprovado e fecha de vez o que nunca pode

O exemplo oficial de ~/.claude/settings.json é esse:

{
  "permissions": {
    "allow": ["Bash(npm run lint)", "Bash(npm run test *)"],
    "deny": ["Read(./.env)", "Read(./.env.*)"]
  }
}

Além de allow e deny, existe o ask, que pede confirmação sempre, pro que você quer olhar caso a caso pro resto da vida

O erro comum deste passo: colocar comentário // no arquivo pra se lembrar do porquê da regra. É JSON estrito, e você vai ser recebido por um Settings Error na próxima inicialização 😛

6. Suba pro modo auto quando quiser menos prompt sem abrir tudo

O auto roda os tool calls por um classificador em dois estágios: primeiro um filtro rápido de um token, que bloqueia ou libera, e só quando ele sinaliza é que entra um segundo passo com raciocínio em cadeia

Ao entrar nesse modo, o Claude Code descarta regras de permissão que dariam execução arbitrária de código, tipo acesso geral ao shell, interpretadores com wildcard (python, node, ruby e similares) e comandos run de gerenciador de pacotes

O escopo de confiança padrão é curto: só o diretório de trabalho e os remotes configurados do repo atual

Destino que não estiver listado em autoMode.environment é tratado como potencial exfiltração e bloqueado

Tem ainda uma sonda server-side que varre saídas de ferramenta (leitura de arquivo, web fetch, saída de shell, respostas de ferramentas externas) antes de entrarem no contexto, e adiciona um aviso quando o conteúdo parece tentativa de sequestrar o comportamento

Quer ver as listas de regras padrão na íntegra? Roda isso:

claude auto-mode defaults

Sai tudo em JSON, e é MUITO melhor conferir a lista do que supor o que ele libera

O erro comum deste passo: usar bypassPermissions fora de ambiente isolado quando o objetivo era só ter menos interrupção. Aí você não ganhou autonomia calibrada, você desligou o freio

7. Trave as exceções com hook PreToolUse

O hook PreToolUse dispara antes da checagem de modo, inclusive no dontAsk

Ele define o permissionDecision com valor "allow", "deny", "ask" ou "defer", e o "ask" mostra o prompt de permissão normalmente

Se liga nisso: um permissionDecision com "deny" bloqueia a ferramenta mesmo em bypassPermissions ou com a flag --dangerously-skip-permissions

É o seu último anteparo, o que não cai nem no modo que aprova tudo

O erro comum deste passo: achar que acceptEdits já cobre esse tipo de trava. Ele aprova edição de arquivo e só, outras ferramentas continuam na permissão normal

Qual nível de autonomia usar em cada tipo de tarefa:

A calibragem muda conforme o estrago possível

Minha leitura, cenário por cenário:

• Explorar código desconhecido e desenhar mudança grande: plan. Somente leitura, e as perguntas de esclarecimento aparecem justo quando ainda dá pra mudar de ideia de graça
• Refatoração mecânica em repo versionado: acceptEdits. Edição em massa passa direto, e o git é a sua rede de segurança
• Sessão longa de implementação com menos interrupção: auto, com deny e ask cobrindo o que não pode passar de jeito nenhum
• Pipeline ou ambiente sem interação humana: dontAsk com allow rules escritas antes, ou bypassPermissions SÓ em isolamento de verdade
• Decisão de produto, nome de API, escolha de biblioteca e migração de dados: devolve pra você, sempre. Não importa o modo

E agora a leitura honesta dos números, porque autonomia alta não é mágica

O classificador do modo auto bloqueia cerca de 0,4% dos comandos benignos, e tem 17% de falso negativo sobre ações overeager reais

Traduzindo: ele quase não te atrapalha à toa, e ainda assim deixa passar uma fatia relevante das ações afoitas

Interessante também que os usuários aprovam 93% dos prompts de permissão, o que explica bem a sensação de estar carimbando papel o dia inteiro

Menos ruído, sim. Dispensa de revisar o diff, não 🙂

O que a prática mostra sobre deixar o Claude Code decidir:

No vídeo em que eu monto um projeto do zero, uma calculadora de IMC em HTML, CSS e JavaScript, o Claude Code estava configurado pra pedir confirmação antes de agir

E eu tive que autorizar cada ação, uma por uma

Liberei na mão a permissão pra ele editar o arquivo HTML, e a cada nova ação necessária ele voltava a perguntar

Funciona? Funciona

Mas o desenvolvimento fica pausado o tempo todo, e o ritmo do trabalho vai embora

A saída que eu mostro ali não é reclamar da pergunta, é trocar o modo de operação em vez de aprovar passo a passo

Agora, o contrário também é verdade: quando eu abri o resumo das ações executadas e o raciocínio (thinking) depois que o projeto ficou pronto, deu pra acompanhar como ele planejou cada funcionalidade antes de executar

É esse o hábito que fica: plano antes, revisão depois, e a pergunta reservada pro que é decisão sua mesmo

No fim eu abri a calculadora no navegador e confirmei que funcionava normalmente, que é a parte que nenhum modo de permissão faz por você

Conclusão:

A regra de bolso cabe em uma linha: reversível e dentro do seu ambiente, ele decide; irreversível, externo ou subjetivo, ele devolve

O resto é só escolher onde escrever isso: modo de permissão pra sessão, allow, ask e deny pro que se repete, CLAUDE.md pro que já é decisão fechada e hook PreToolUse pras exceções que não podem cair nunca

Próximo passo bem concreto pra sua próxima tarefa: comece no modo plan, anote as três perguntas que mais se repetiram durante a execução e transforme cada uma delas em allow, deny ou linha no CLAUDE.md

Faz isso por uma semana e a sessão para de te interromper pelo que não interessa, sobrando pergunta só onde a decisão é realmente sua 😀

até o próximo post!