![Imagem de capa de [Claude Code #3] Resumo de permissões: /permissions e ciclo de modos](/assets/images/posts/b17b8c27-14dd-4d96-bc74-34a249a2ae3b/claude-code-permission-rules.jpg)
Ao usar ferramentas de codificação com IA, surge um dilema: pedir permissão toda vez é cansativo, mas liberar tudo assusta por causa de git push e rm -rf.
O Claude Code resolve esse equilíbrio com regras de permissão. Alguns comandos passam silenciosamente, outros exigem confirmação e outros são bloqueados por completo.
O modo de planejamento abordado em Claude Code, parte 2 também funciona sobre este sistema de permissões. Nesta parte, vamos organizar a visão geral.
Comportamento básico: o que pede confirmação?
De acordo com Documentação oficial de permissões, cada tipo de ferramenta tem regras padrão diferentes.
Ferramentas somente leitura, como leitura de arquivos e busca, funcionam sem aprovação dentro do diretório de trabalho.
Em princípio, comandos de shell exigem aprovação. A exceção é o conjunto integrado de comandos somente leitura.
Alterações em arquivos sempre pedem confirmação. Mesmo escolhendo “Não perguntar novamente”, a opção é redefinida quando a sessão termina. Já “Não perguntar novamente” para comandos de shell é salvo como regra por repositório e permanece nas sessões seguintes.
Ver regras com /permissions
Ao digitar /permissions na sessão, a lista de regras atualmente aplicadas é aberta. Ela também mostra de qual settings.json cada regra veio.
Há três tipos de regra.
- allow: permite a execução sem perguntar
- ask: exige confirmação a cada tentativa
- deny: bloqueia a execução completamente
A ordem de avaliação define tudo
O que acontece quando as regras se sobrepõem? A ordem é deny → ask → allow, e vence a primeira regra correspondente.
O ponto importante é que a especificidade não altera a ordem. Se você colocar Bash(aws *) em deny, ele será bloqueado mesmo que Bash(aws s3 ls) seja escrito de forma muito específica em allow.
Regras deny não permitem exceções. Não é possível configurar “bloquear todo aws, mas permitir apenas consultas de s3”; é preciso dividir as regras em escopos menores.
Além disso, se você escrever apenas o nome da ferramenta em deny, sem parênteses (por exemplo, Bash), ela desaparecerá completamente do contexto do Claude. Uma regra com escopo restrito, como Bash(rm *), mantém a ferramenta e bloqueia apenas aquela chamada.
Revisão rápida da sintaxe das regras
As regras têm o formato 도구 ou 도구(지정자). As regras do Bash aceitam o curinga *, que pode aparecer em qualquer posição.
{
"permissions": {
"allow": [
"Bash(npm run *)",
"Bash(git commit *)",
"Bash(* --version)"
],
"deny": [
"Bash(git push *)",
"Read(./.env)"
]
}
}Se houver um espaço antes do asterisco no fim do comando (Bash(ls *)), o limite entre palavras será respeitado. ls -la corresponde, mas lsof não. Sem espaço, Bash(ls*) corresponde até lsof.
Comandos compostos como git status && npm test só passam quando cada subcomando corresponde a uma regra. Mesmo permitindo Bash(safe-cmd *), safe-cmd && other-cmd não passa.
As regras de caminho de arquivo verificam apenas Read(경로) e Edit(경로). Elas usam a sintaxe de padrões do gitignore. Se você escrever Write(docs/**), será ignorado; use Edit(docs/**).
Como bônus, Read deny também bloqueia edição e escrita no mesmo caminho. Com apenas Read(./.env) do exemplo, tanto a leitura quanto a alteração ficam bloqueadas.
Modos de permissão: ciclo com Shift+Tab
Se as regras fazem um ajuste preciso, o modo de permissão define a orientação de toda a sessão.
A cada toque em Shift+Tab, os modos alternam nesta ordem: default (aprovação manual) → acceptEdits (aprovação automática de edições) → plan (modo de planejamento). O modo de planejamento foi tratado na parte anterior.
Segundo Documentação oficial dos modos de permissão, o modo auto também entra no ciclo quando as condições da conta e do plano são atendidas. Um modelo classificador filtra apenas ações perigosas e não pergunta sobre as demais. Mesmo assim, regras ask explícitas continuam exigindo confirmação.
Como referência, Com base no anúncio oficial define que, a partir de 14 de agosto de 2026, novas sessões dos planos Pro, Max e Team usarão auto por padrão.
Prioridade entre arquivos de configuração
As regras podem ser distribuídas por vários níveis de settings.json: configuração pessoal global (~/.claude/), projeto (.claude/settings.json), configuração apenas local e configuração administrada pela organização.
O princípio descrito em Documentação oficial sobre a prioridade da configuração é simples: se deny for acionado em qualquer nível, um allow de outro nível não poderá desfazê-lo.
Você pode bloquear com deny pessoal algo permitido pelo projeto, e vice-versa. O deny da configuração administrada pela organização também não pode ser desfeito por uma flag de linha de comando.
Quem aplica as regras é a ferramenta, não o modelo
Por fim, há um ponto fácil de interpretar mal.
Escrever “não faça git push” no CLAUDE.md é um pedido, não uma imposição. Se o modelo esquecer a instrução ou julgar errado, poderá ignorá-la.
As regras de permissão são diferentes. O cliente do Claude Code as aplica mecanicamente, independentemente da decisão do modelo. O que precisa ser bloqueado obrigatoriamente deve entrar em uma regra deny, não no CLAUDE.md.
Resumo
A estrutura do sistema de permissões tem três elementos: regras allow, ask e deny; a ordem de avaliação deny → ask → allow; e o modo de permissão que define a orientação da sessão.
A estratégia básica é liberar com allow os comandos seguros usados com frequência para reduzir a fadiga de confirmações e bloquear firmemente os comandos perigosos com deny.
Na próxima parte, veremos o conjunto de três mecanismos /resume, /branch e /fork, que continuam e dividem as conversas.
Fontes e critérios de verificação
- Documentação oficial do Claude Code — Configure permissions (Anthropic, verificado em 13/08/2026)
- Documentação oficial do Claude Code — Choose a permission mode (Anthropic, verificado em 13/08/2026)
Continue lendo
Série Claude Code
- Parte anterior: [Claude Code #2] Modo de planejamento /plan: alinhe o design antes de alterar
- Parte anterior: [Claude Code #1] Começando com /init e a geração automática do CLAUDE.md