Claude Code pedindo permissão a cada comando: como reduzir os prompts sem perder o controle

Fala aí, beleza? Você pede uma coisa simples, sai pra pegar café, volta e o Claude tá parado esperando você apertar "sim" pra rodar um npm test

Aí você aperta, ele anda três passos e para de novo

O reflexo é liberar tudo e nunca mais pensar no assunto. Só que aí você trocou a interrupção por outro problema: um agente com acesso total à sua máquina, sem ninguém olhando

O caminho do meio existe e é bem menos glamouroso do que "prompt mágico": é decidir POR CAMADA o que vale aprovar sozinho

O Claude Code te dá três alavancas pra isso: os modos de permissão, as regras allow, ask e deny, e um Bash em sandbox que joga o limite pro sistema operacional. Cada projeto pede uma combinação diferente, e é isso que a gente vai montar aqui

Modos de permissão do Claude Code: o que cada um libera

Antes de escrever regra nenhuma, entenda o que cada modo faz. É a decisão mais grossa e a que mais muda seu dia

Detalhe importante do modo auto: desde 14 de agosto ele é o modo de permissão padrão em novas sessões nos planos Pro, Max e Team

Se você já tinha definido um modo padrão seu, ele continua valendo, a não ser que você aceite o aviso único de troca. E padrão gerenciado pela organização não muda sozinho

O classificador não é um "sim pra tudo" com nome bonito: ele bloqueia ações que escapam do escopo do seu pedido, que miram infraestrutura não reconhecida ou que parecem dirigidas por conteúdo hostil que o Claude leu no caminho

Antes de mexer nas permissões: onde as regras moram e quem ganha de quem

Aqui é a parte que a galera pula e depois jura que "a regra não funciona"

Formato da regra. Uma regra de permissão é Tool ou Tool(especificador). Só isso. Bash(npm test), Read(./.env), WebFetch(domain:example.*)

Ordem de avaliação. As regras são avaliadas em deny, depois ask, depois allow, e a PRIMEIRA correspondência decide, independente de qual regra é mais específica

Repete isso pra você mesmo, porque é contraintuitivo: um deny amplo ganha de um allow cirúrgico. Não é o mais específico que vence, é o que casa primeiro na ordem

De onde a regra vem. O Claude Code lê configuração em ordem de precedência, do maior pro menor: managed policy, depois argumentos de linha de comando, depois .claude/settings.local.json, depois .claude/settings.json, depois ~/.claude/settings.json

E quando as camadas se combinam, arrays são mesclados e escalares da camada mais alta sobrescrevem os de baixo

Traduzindo: sua lista de deny do projeto NÃO apaga a lista de deny global, ela soma. Já um valor único (um modo padrão, por exemplo) é substituído por quem tá mais em cima

Esse escopo por camada é a mesma lógica que vale pra outras coisas que você configura por projeto, tipo skills, comandos e subagentes, então se você já pegou o jeito lá, aqui vai parecer familiar

A fonte da verdade. O comando /permissions abre uma interface que lista todas as regras (allow, ask e deny) e o arquivo settings.json de onde cada uma veio

Tem também uma aba de modo auto, pra ver e editar as regras do classificador sem abrir arquivo nenhum. Ela lista as entradas allow, soft_deny, hard_deny e environment de cada escopo lido pelo classificador

Tome cuidado com a versão: essa aba exige Claude Code v2.1.246 ou posterior. Se ela não aparecer pra você, é aí que eu olharia primeiro

Passo a passo: reduzindo os prompts sem abrir a guarda

A ordem aqui não é decorativa. É do mais seguro pro mais permissivo, porque cada passo diminui o risco do passo seguinte

1. Rode /permissions e mapeie o que já existe

Antes de escrever qualquer coisa, descubra o que já tá valendo

<pre><code>/permissions</code></pre>

Olhe as três listas e, principalmente, a ORIGEM de cada regra. Uma regra que veio de ~/.claude/settings.json te acompanha em todo projeto, e é bem comum a pessoa achar que tá configurando o repositório atual quando na verdade tá mexendo na configuração global

O erro comum deste passo: escrever regra nova sem olhar a lista, e depois brigar com um deny herdado que você mesmo criou meses atrás 🙂

2. Escreva o deny dos arquivos sensíveis PRIMEIRO

Nunca comece afrouxando. Comece fechando

A doc traz esse exemplo pra arquivos sensíveis:

<pre><code class="language-json">{ "permissions": { "deny": [ "Read(./.env)", "Read(./.env.*)", "Read(./secrets/**)" ] } }</code></pre>

E olha que legal: arquivo coberto por deny de leitura também some da descoberta de arquivos e dos resultados de busca, e Edit e Write ficam bloqueados nesses caminhos

Ou seja, não é só "ele não lê": ele não acha, não busca e não escreve por cima

O erro comum deste passo: achar que deny de leitura é blindagem total. Ele cobre as ferramentas de arquivo embutidas e os comandos de arquivo que o Claude Code reconhece no Bash (cat, head, tail, sed), mas não cobre subprocesso arbitrário: um script Python ou Node que abre o arquivo por conta própria passa

3. Escolha o modo do dia a dia

Com o deny no lugar, aí sim escolhe o modo

Dentro da sessão, Shift+Tab alterna entre os modos (a partir do modo manual, uma vez já te joga no modo plan)

Na abertura, dá pra definir direto:

<pre><code class="language-bash">claude –permission-mode plan</code></pre>

O erro comum deste passo: escolher o modo mais solto "só pra essa tarefa" e esquecer que ficou solto. Se é exceção, abra a sessão com a flag e feche ela quando acabar, em vez de mudar o padrão

4. Empurre o limite pro sistema operacional

Essa é a alavanca mais subestimada

O Bash em sandbox deixa o Claude rodar a maioria dos comandos sem parar pra pedir permissão, porque quem aplica o limite não é o julgamento do modelo, é o sistema

São duas fronteiras: isolamento de sistema de arquivos (leitura e escrita no diretório de trabalho, bloqueando modificação fora dele) e isolamento de rede (acesso só por um socket unix ligado a um proxy fora do sandbox). Vale pra cada comando Bash e pros processos filhos dele

Por baixo, ele é construído sobre primitivas do próprio sistema: bubblewrap no Linux e seatbelt no macOS

No uso interno da Anthropic, isso deu uma redução de 84% nos pedidos de permissão

Quando você precisar de mais folga, os ajustes são sandbox.filesystem.allowWrite, que concede escrita em caminhos adicionais, e sandbox.filesystem.disabled, que dispensa o isolamento de sistema de arquivos MANTENDO o isolamento de rede

O erro comum deste passo: tentar isso no Windows nativo. Não é suportado. Roda o Claude Code dentro de uma distribuição WSL2 (macOS, Linux e WSL2 estão cobertos)

5. Só agora libere allow específico, por projeto

Chegou a hora do allow, e a regra de ouro é: nomeie o comando, não o executor

Regras de Bash pra executores de ambiente casam com TUDO que vem depois do comando. Então Bash(devbox run *) libera qualquer coisa depois do run, e a doc orienta escrever a regra específica incluindo o comando interno:

<pre><code class="language-json">{ "permissions": { "allow": [ "Bash(devbox run npm test)" ] } }</code></pre>

O erro comum deste passo: liberar o runner porque "é só pra rodar teste". Você não liberou teste, você liberou o shell inteiro com um prefixo bonitinho

6. Ajuste em tempo real, sem matar a sessão

Desde a semana de 17 a 21 de agosto de 2026, dá pra abrir o /permissions ou rodar /add-dir <path> ENQUANTO o Claude tá trabalhando, e a mudança de regra vale pro resto do turno atual

Isso muda bastante o fluxo: em vez de cancelar, editar arquivo e recomeçar do zero, você corrige a regra e a tarefa segue

O erro comum deste passo: usar isso como muleta e ir liberando na correria, uma regra ampla de cada vez, até o projeto virar um allow gigante que ninguém releu

7. No modo auto, revise o que foi negado

Quando o classificador nega uma ação, a negação volta como resultado de ferramenta com instrução pro modelo procurar um caminho mais seguro em vez de contornar o bloqueio. Ele é instruído a tratar o limite de boa fé e não tentar rotear em volta

Se a negação foi engano, você não precisa reescrever nada na mão: dentro do /permissions tem a aba Recently denied, e a tecla r marca a ação negada pra retry

Ao sair do diálogo, o Claude Code avisa o modelo que pode tentar de novo e retoma a conversa

O erro comum deste passo: ignorar as negações e ficar reformulando o pedido no chat. Se algo legítimo tá sendo barrado toda hora, o lugar de arrumar é a regra, não o prompt

Quando a regra não funciona como você esperava

Separei os tropeços mais previsíveis, com causa e correção

Sintoma: você escreveu um allow bem específico e ele é ignorado

Causa: um deny amplo casou antes. Uma regra deny ampla bloqueia todas as chamadas correspondentes, inclusive as que também batem em um allow mais estreito. O exemplo da própria doc é Bash(aws *), que bloqueia tudo que casa, mesmo com allow mais específico no lugar

Correção: estreite o deny em vez de empilhar allow por cima. Primeira correspondência decide, lembra?

Sintoma: o Claude rodou um comando que você jura que não liberou

Causa: você liberou o runner. Bash(devbox run *) casa com qualquer coisa depois do run

Correção: reescreva incluindo o comando interno, tipo Bash(devbox run npm test)

Sintoma: o padrão de caminho não pega o alvo certo

Causa: em Read e Edit, o asterisco simples casa exatamente UM segmento do caminho e o asterisco duplo casa ATRAVÉS de segmentos, com o casamento ancorado no caminho de diretório inteiro

Correção: decida se você quer um nível só (*) ou a subárvore toda (**), e teste conferindo no /permissions

Sintoma: você bloqueou .env e mesmo assim apareceu um .env acessível

Causa: nome de arquivo simples segue semântica de gitignore e casa em qualquer profundidade. Read(.env) e Read(**/.env) são equivalentes: bloqueiam qualquer .env na pasta atual ou abaixo, mas não um .env em diretório pai nem em outro projeto

Correção: se o segredo mora fora do projeto, a regra do projeto não vai te salvar. Trate isso na camada global

Sintoma: o deny de leitura não segurou um script

Causa: deny de Read e Edit cobre as ferramentas de arquivo embutidas e os comandos de arquivo que o Claude Code reconhece no Bash, mas não cobre subprocesso arbitrário. cat, head, tail e sed estão cobertos. Um script Python ou Node que abre o arquivo sozinho, não

Correção: aqui o remédio é o isolamento do sandbox, não mais uma linha de deny

Sintoma: você acha que a regra de domínio tá frouxa demais

Causa/prevenção: boa notícia, o curinga em regra de domínio do WebFetch não atravessa ponto. WebFetch(domain:example.*) casa com example.org, mas NÃO casa com example.evil.com, então um domínio registrado por atacante não entra de carona

Sintoma: a sessão trava de repente e volta pra você

Causa: é proposital. No modo auto existe um limite de negações que interrompe o modelo e escala pro humano: 3 negações consecutivas ou 20 no total na sessão

Correção: não é hora de afrouxar tudo no susto, é hora de olhar a aba de negadas e entender qual regra tá no caminho

Como calibrar por tipo de projeto

Não existe uma configuração só. Existe a combinação que faz sentido pro que tá em jogo naquele repositório

Repositório de trabalho, com segredos e deploy. Deny forte primeiro (.env, .env.*, secrets/**), modo auto pra ter o classificador revisando shell e rede, e allow estreito comando por comando. Nada de runner genérico

Explorar código alheio ou revisar. Modo plan. Ele lê, roda comando de shell pra explorar e escreve um plano, sem editar o código fonte. É o modo que eu deixaria ligado pra ler repositório que não é seu

Refatoração grande, com revisão no git diff. Modo acceptEdits. As operações de arquivo passam direto e você revisa em bloco depois, no editor ou no diff. Lembrando que comando Bash que não é operação de sistema de arquivos continua pedindo permissão

Ambiente descartável, em container ou VM. Aí sim bypassPermissions tem lugar: acesso autônomo total, sem aviso, num ambiente onde o Claude Code não pode causar dano. Fora disso, não

Time ou organização. Use o padrão gerenciado, que fica no topo da precedência e não muda sozinho quando o produto muda o default. E se a política interna não permitir o classificador, dá pra desligar o modo auto pra todo mundo com permissions.disableAutoMode no valor "disable" nas configurações gerenciadas, o que se aplica aos planos Team e Enterprise

E já que a gente tocou em planos: se a sua dúvida do lado do bolso é outra, tem um comparativo aqui sobre como o Claude Code cobra que fecha essa parte

O que vale liberar, o que nunca liberar

Veredito curto, sem enrolação

Vale liberar: leitura e edição dentro do diretório de trabalho, e comandos de teste NOMEADOS. É o grosso da interrupção e o menor risco real, ainda mais com o sandbox segurando escrita fora do projeto

Nunca liberar: leitura de .env e de secrets, runner genérico com curinga solto, e bypassPermissions na sua máquina principal. Esse último a doc já diz na cara: só em ambiente isolado

O princípio que amarra tudo é esse: o ganho não vem de esvaziar a lista de perguntas, vem de MOVER o limite

Ou você move pro sistema operacional, com o sandbox aplicando isolamento de arquivo e de rede, ou você move pra um revisor automático, com o classificador do modo auto olhando shell e rede por você

Inclusive é por isso que o modo auto não fica lento à toa: ações somente leitura e edições de arquivo no diretório de trabalho são aprovadas automaticamente e pulam o classificador (menos escritas em caminhos protegidos, que vão pro classificador mesmo quando um allow casa)

O custo do classificador recai principalmente sobre comandos de shell e operações de rede, que é exatamente onde você quer alguém olhando

Conclusão

A ordem de ataque é sempre a mesma: deny primeiro, modo depois, allow por último

Deny primeiro porque ele ganha na ordem de avaliação e porque tira o arquivo até da busca. Modo depois porque é a decisão mais grossa e muda o comportamento inteiro da sessão. Allow por último e cirúrgico, com o comando interno escrito na regra

E não esquece que camada de settings soma array e sobrescreve escalar, então a regra que te incomoda pode estar vindo de um arquivo que você nem abriu hoje

Próximo passo concreto: abre o /permissions no projeto em que você tá agora, confere a origem de cada regra e escreve o bloco deny ANTES de afrouxar qualquer coisa

Depois disso, afrouxar fica fácil e bem menos assustador 😀

até o próximo post!