Claude Code pediu permissão para rodar um comando: quando aprovar e quando negar?

Fala aí, beleza? Aquela caixinha do Claude Code pedindo pra rodar um comando não é um obstáculo no seu caminho

Ela é a última decisão humana antes da máquina mexer na sua máquina

Por padrão o Claude Code trabalha com permissões restritas pra tudo que muda estado: ler ele lê à vontade, mas quando precisa editar arquivo, rodar teste ou executar comando, ele PARA e pergunta

E aí você decide se aprova uma vez ou libera de vez

O problema é que a maioria da galera (eu incluído, em dia corrido) bate o olho no verbo do comando e clica em aprovar no automático

Este post é sobre separar as duas pilhas: o que dá pra liberar sem medo e o que merece leitura linha a linha antes do sim

O que o Claude Code está perguntando de verdade

Antes de decidir, entende o que tem dentro do prompt

Ele te oferece três saídas: Yes, Yes, don’t ask again e No

A primeira aprova só aquela chamada, agora

A segunda é a que pesa: ao escolher Yes, don't ask again para um comando Bash, a regra é gravada permanentemente em .claude/settings.local.json na raiz do repositório git

E ela passa a valer em sessões futuras em qualquer ponto daquele repositório, inclusive subdiretórios e worktrees

Ou seja: não é "pra esta conversa", é "pra sempre neste repo"

Pré-inscrição Formação Claude Code

Domine o Claude Code do básico ao avançado

Você vai aprender a criar sistemas completos com Claude Code, sem precisar ser programador. Inscreva-se para ter acesso a um desconto de lançamento e bônus especiais!

Quero minha vaga

Onde as regras moram:

O Claude Code lê três arquivos de configuração, em escopos diferentes:

• ~/.claude/settings.json: nível usuário, vale pra todo projeto seu
• .claude/settings.json: nível projeto, aquele que vai versionado no repo e vale pro time
• .claude/settings.local.json: pessoal daquele projeto, fora do git

Dentro deles as regras ficam no objeto permissions, com as categorias allow, deny e ask, mais um defaultMode pro que não foi nomeado:

{
  "permissions": {
    "allow": ["Bash(npm run build)"],
    "ask": ["Bash(git push *)"],
    "deny": ["Read(./.env)"],
    "defaultMode": "default"
  }
}

E a ordem de avaliação é a parte que quase ninguém lê: primeiro deny, depois ask, depois allow

A primeira correspondência nessa ordem decide, e especificidade da regra NÃO muda essa ordem

Pra gerir isso dentro da sessão existe o comando /permissions

Tome cuidado com um detalhe: ele não está disponível na aba Code do app Desktop, onde responde que não está disponível nesse ambiente

Nesse caso a edição é pelo CLI ou direto nos arquivos de settings

Se você ainda mistura os conceitos de ferramenta, atalho e agente, dar uma olhada em skills, comandos e subagentes ajuda a entender o que exatamente está sendo autorizado quando o prompt aparece

Como decidir em 5 passos quando o pedido aparecer

A rotina é sempre a mesma, e ela cabe em poucos segundos depois que vira hábito

1. Leia o comando inteiro, não só o verbo

O risco quase nunca está no começo da linha, está no argumento lá no fim: o caminho, a flag, o pipe

O erro comum deste passo: aprovar porque começou com um comando familiar, sem ver pra onde ele apontava

2. Pergunte se a ação é reversível

Build quebrou? roda de novo

Arquivo apagado fora do controle de versão? boa sorte

O erro comum deste passo: tratar "eu tenho git" como rede de segurança universal, sendo que o que não está commitado não está protegido por nada

3. Cheque se o alvo está dentro da pasta da sessão

O Claude Code só escreve na pasta em que foi iniciado e nas subpastas dela, e não modifica arquivos em diretórios pai sem permissão explícita

Então um caminho subindo de nível no pedido é um sinal pra ler com calma

O erro comum deste passo: iniciar a sessão na raiz da home e achar que o escopo está estreito, quando na verdade tudo virou subpasta

4. Escolha entre aprovar uma vez e gravar regra

Aqui a pergunta certa não é "esse comando é seguro agora?"

É "eu quero que ele rode sem me perguntar daqui a três semanas, em outro ponto deste repo?"

O erro comum deste passo: usar Yes, don't ask again como se fosse um "sim, vai logo", quando ele é permanente naquele repositório

5. Se for gravar, escreva a regra no escopo certo

A sintaxe é Tool ou Tool(especificador), com curinga em qualquer posição:

Bash(npm run build)
Bash(npm *)
Bash(* install)
Read(./.env)
WebFetch(domain:example.com)

Repare que Bash(npm run build) e Bash(npm *) são universos MUITO diferentes de confiança

O erro comum deste passo: escrever curinga largo demais por preguiça de listar dois ou três comandos

E tem um detalhe fino de caminho de arquivo: ao aprovar um caminho com Yes, don't ask again, o Claude Code escapa caracteres de padrão gitignore no caminho (como [, ] e *) pra que a regra gerada case apenas com o caminho literal aprovado

Isso é proteção, não bug: sem isso, aprovar um arquivo com colchete no nome poderia virar uma regra bem mais ampla do que você quis

O que liberar sem medo e o que ler antes de aprovar

A régua é reversibilidade e escopo, sempre

Libera fácil:

• Leitura de código do próprio projeto: não muda estado nenhum, e leitura é justamente o que já corre solto por padrão
• Build e teste do projeto: rodam, quebram, você roda de novo
• Comandos repetitivos e reversíveis do seu dia a dia, tipo o script de lint que você chama vinte vezes por dia

Esses são os candidatos naturais a virar allow estreito, nomeando o comando inteiro em vez de um * genérico

Lê antes de aprovar:

• Comandos de rede: curl e wget não são auto aprovados por padrão e pedem permissão como qualquer comando Bash que não seja somente leitura
• rm e rmdir apontando pra /, pra home ou pra outros caminhos críticos de sistema: eles disparam prompt, ou checagem do classificador no modo auto, e é exatamente aí que o clique automático dói
• Escrita em diretórios protegidos: a lista inclui .git, .config/git, .vscode, .idea, .husky, .cargo, .devcontainer, .yarn, .mvn e .claude (com exceção de .claude/worktrees)
• Push: uma regra ask com escopo de conteúdo, tipo Bash(git push *), continua forçando o prompt, e isso é bom, porque push é a ação que sai da sua máquina

E tem o motivo menos óbvio pra ler antes: prompt injection

É quando um atacante tenta sobrescrever ou manipular as instruções por meio de conteúdo em arquivos, páginas web ou entrada do usuário

Ou seja: um README com instruções estranhas pode virar ação do Claude Code, e a própria Anthropic documenta esse risco

O Claude Code aplica análise sensível ao contexto pra detectar instruções potencialmente danosas, sanitiza entrada contra injeção de comando e exige aprovação pra comandos de rede

Mas repara na peça central desse desenho: a aprovação é sua

É literalmente pra esse cenário que o prompt existe

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

Os modos são: default (rotulado Manual no CLI e nas extensões de IDE), plan, acceptEdits, auto, dontAsk e bypassPermissions

Pra alternar, é Shift+Tab no CLI, ou o seletor de modo no VS Code, no Desktop e no claude.ai

E duas regras não mudam com o modo, o que é ótimo saber:

• Regras deny e regras ask explícitas continuam valendo em todos os modos, inclusive no auto e no bypassPermissions, porque são avaliadas antes do classificador
• allow não vence caminho protegido: a checagem de segurança roda antes da avaliação das regras, então uma entrada tipo Edit(.claude/**) não muda o resultado

Escritas em caminhos protegidos nunca são auto aprovadas, com exceção do bypassPermissions

Dá pra usar isso a seu favor: em vez de confiar no modo, você fixa no deny o que nunca deve rodar e dorme tranquilo em qualquer modo

O auto mode vira padrão e o prompt aparece menos

Em 7 de agosto de 2026 a Anthropic anunciou que, a partir de 14 de agosto de 2026, o auto mode passa a ser o modo de permissão padrão em novas sessões nos planos Pro, Max e Team

Quem já fixou um padrão próprio pode receber um prompt único perguntando se quer trocar, e não sofre mudança automática

Fora daí ele segue opt-in: Claude Enterprise, Claude API, Claude Platform na AWS, Amazon Bedrock, Agent Platform do Google Cloud e Microsoft Foundry, com plano da Anthropic de torná-lo padrão nesses ambientes no mês seguinte

E o que é o auto mode na prática? Ele delega a aprovação a classificadores baseados em modelo, como meio termo entre revisão manual e nenhuma barreira

A proposta declarada é substituir o --dangerously-skip-permissions sem trazer de volta as interrupções

O classificador de transcrição roda no Sonnet 4.6 e avalia cada ação antes da execução, em dois estágios: um filtro rápido de um token e, só se ele sinalizar, um raciocínio em cadeia

Quando o classificador bloqueia, a negação volta como resultado de ferramenta com instrução pro modelo achar um caminho mais seguro em vez de contornar o bloqueio

E a sessão para e escala pro humano após 3 negações consecutivas ou 20 no total

Agora o número que explica a decisão toda: em estudo controlado da Anthropic com 1.053 testadores pagos, revisores humanos pegaram um comando perigoso plantado em 13,6% das vezes, contra 89% do auto mode

Sacou? O ponto não é que a máquina é infalível

É que o humano clicando em Yes no automático é pior do que ele imagina

E o sandbox, entra onde?

O sandbox do Claude Code isola execução de código com controles de sistema de arquivos e de rede, liberando operações seguras, bloqueando as maliciosas e perguntando só quando necessário

Pra começar, é rodar /sandbox no Claude Code

O detalhe que faz ele valer a pena: restrições do sandbox impedem que comandos Bash alcancem recursos fora dos limites definidos, MESMO que um prompt injection contorne a decisão do modelo

É uma camada independente do julgamento do modelo, e no uso interno da Anthropic ela reduziu com segurança os prompts de permissão em 84%

Já o --dangerously-skip-permissions desliga todos os prompts e deixa o Claude agir livremente, o que é inseguro na maioria das situações

Se o seu incômodo é a quantidade de prompt, a saída é regra estreita, modo adequado e sandbox, não a flag

E se estiver de olho em qual plano faz sentido pra rodar isso no dia a dia, tem um material sobre preço do Claude Code em 2026 que ajuda nessa conta

Aprovei o que não devia: como corrigir a regra

Calma que tudo aqui tem conserto 🙂

Sintoma: gravei uma regra sem querer no "Yes, don’t ask again"

Causa: aquela escolha grava a regra permanentemente em .claude/settings.local.json na raiz do repositório, valendo em sessões futuras

Solução: editar ou remover a entrada nesse arquivo, ou abrir /permissions na sessão e ajustar por lá

Sintoma: o comando está no allow e continua bloqueado

Causa: se uma ferramenta é negada em qualquer nível de configuração, nenhum outro nível consegue liberar

Um deny do usuário bloqueia um allow do projeto, e vice versa

E tem o agravante: uma regra deny ampla bloqueia toda chamada que casa com ela, mesmo com uma regra allow mais estreita

O exemplo clássico: deny Bash(aws *) bloqueia até um Bash(aws s3 ls) liberado no allow

Solução: deny não comporta exceções de allowlist, então estreite o próprio deny em vez de tentar furar ele por baixo

Sintoma: ele pergunta mesmo com allow que casa

Causa: ferramentas de conectores que a organização configurou como ask e ferramentas MCP marcadas com requiresUserInteraction perguntam direto ao usuário, mesmo quando existe regra allow que casa

Solução: aqui não é bug de configuração sua, é comportamento esperado, então a decisão é responder o prompt mesmo

Sintoma: /permissions responde que não está disponível

Causa: o comando não está disponível na aba Code do app Desktop

Solução: editar pelo CLI ou direto nos arquivos de settings

Como prevenir:

• allow com escopo estreito, nomeando o comando (Bash(npm run build)) em vez de abrir a família inteira
• deny pro que nunca deve rodar, lembrando que ele é avaliado primeiro e sobrevive até em auto e bypassPermissions

Conclusão

O critério pra responder o prompt de permissão cabe em três perguntas: a ação é reversível? o alvo está dentro do escopo da sessão? eu entendi o comando inteiro, e não só o começo dele?

Se as três respostas forem sim, aprovar é decisão consciente

Se alguma for não, aí vale os segundos de leitura

Próximo passo bem concreto: abre o /permissions, revisa o que já foi gravado no seu .claude/settings.local.json e decide em qual modo você quer trabalhar, antes que o auto mode assuma como padrão em novas sessões

Melhor escolher agora do que descobrir no susto depois…

até o próximo post! 😀