Controlar o que o Claude Code pode fazer sem perguntar

Mais cedo ou mais tarde, quem usa o Claude Code bate na mesma parede. O Claude pergunta antes de cada comando, carregas em "Yes" cinquenta vezes por dia e acabas por deixar de ler os pedidos ou por desligar todas as verificações. As duas saídas são piores do que configurar isto bem uma vez.

Este guia explica como o Claude Code decide o que pode fazer sozinho, como mudar isso para uma sessão ou de vez, e como escrever regras que aprovam os teus comandos de rotina e bloqueiam os que nunca queres ver corridos.

Como o Claude Code decide

Cada ação que o Claude quer fazer (ler um ficheiro, editá-lo, correr um comando, ir buscar uma página à web) passa por duas camadas:

• O modo de permissão define a base para a sessão inteira: perguntar quase tudo, aceitar edições de ficheiros, só planear, ou deixar um classificador de segurança decidir.
• As regras de permissão ficam por cima do modo. Aprovam, obrigam a perguntar ou bloqueiam ferramentas e comandos concretos, seja qual for o modo.

As regras são aplicadas pelo próprio Claude Code, não pelo modelo. Escrever "nunca faças push" no teu CLAUDE.md muda o que o Claude tenta fazer, mas não impede nada. Uma regra de bloqueio impede.

Os modos de permissão

• Manual (default): o Claude lê os ficheiros do projeto sem perguntar e pergunta antes de editar ficheiros, correr a maior parte dos comandos ou usar a rede. Um pequeno conjunto de comandos só de leitura, como ls, cat, grep e os comandos git que só leem, nunca pergunta. A definição chama-se default porque o Manual era o modo de arranque antes do Claude Code 2.1.228. Na maior parte dos planos, as sessões começam agora em modo automático (vê a nota abaixo).
• Aceitar edições (acceptEdits): as edições de ficheiros dentro do projeto correm sem perguntar, tal como os comandos de ficheiros mais comuns, como mkdir, touch, mv, cp e rm. Tudo o resto continua a perguntar. Bom quando revês as alterações depois, com git diff.
• Planear (plan): o Claude lê e explora, mas não edita nada até aprovares o plano dele. Bom para código que não conheces, ou antes de uma alteração grande.
• Automático (auto): o Claude trabalha sem os pedidos de rotina, e um modelo à parte, o classificador, verifica cada ação arriscada antes de ela correr. Mais sobre isto abaixo.
• Não perguntar (dontAsk): tudo o que perguntaria é recusado. Só correm as tuas regras já aprovadas. Pensado para scripts e automatismos, onde não há ninguém para responder.
• Ignorar permissões (bypassPermissions): nenhum pedido de permissão. As regras de bloqueio continuam a bloquear, e as tuas regras ask e os apagamentos críticos continuam a perguntar. Só para contentores ou máquinas virtuais que o Claude não possa estragar.

Mudar de modo

Durante uma sessão, carrega em Shift+Tab para passar de modo em modo. A partir do modo automático, o primeiro toque vai para Manual, e depois o ciclo segue Manual, Aceitar edições, Planear e volta ao início. O modo automático aparece no fim do ciclo quando está disponível para ti.

Para começar uma única sessão num dado modo, usa a opção:

$ claude --permission-mode plan

Para tornar um modo o predefinido em todas as sessões da tua máquina, define defaultMode nas tuas definições de utilizador:

{
  "permissions": {
    "defaultMode": "acceptEdits"
  }
}

Responder a um pedido

Quando o Claude quer correr um comando que ainda não está aprovado, pergunta (o Claude Code mostra o texto em inglês):

Run the project's lint script
 ❯ 1. Yes
   2. Yes, and don't ask again for: npm run *
   3. Yes, and switch to auto mode · auto mode handles these prompts for you
   4. No

• Yes aprova só este comando.
• Yes, and don't ask again guarda uma regra, para que o mesmo tipo de comando passe a correr sem perguntar neste projeto. Lê a regra antes de escolher: o pedido acima oferecia npm run *, que aprova todos os scripts npm do projeto, não só o do lint.
• No recusa. Carrega em Tab sobre Yes ou No para acrescentar um comentário, como "usa antes a base de dados de testes", e o Claude lê-o.

A regra guardada vai para .claude/settings.local.json, na raiz do teu repositório git. O Claude Code mantém esse ficheiro fora dos teus commits, por isso a regra fica só tua. A aprovação de uma edição de ficheiro é diferente: dura só até ao fim da sessão.

Escrever as tuas próprias regras

As regras ficam num ficheiro de definições, em três listas: allow (autorizar), ask (perguntar) e deny (bloquear). Um bom ponto de partida para um projeto:

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

Com este ficheiro, o Claude corre os testes, o lint e os commits sem perguntar. Pergunta sempre antes de um push, mesmo em modo automático. Não consegue ler nenhum ficheiro .env do projeto, nem nada numa pasta secrets. Uma regra Read de bloqueio também impede as ferramentas de ficheiros do Claude de editar ou reescrever esses ficheiros.

O Claude Code verifica as listas por uma ordem fixa: primeiro bloquear, depois perguntar, depois autorizar. Ganha a primeira que corresponder. Por isso uma regra de bloqueio ganha sempre, mesmo a uma regra de autorizar mais específica. Testámos isto com Bash(git *) em allow e Bash(git push *) em deny: o git tag correu sem perguntar e o git push foi recusado com:

Permission to use Bash with command git push origin master has been denied.

Como os padrões funcionam

• Bash(npm test) sem * corresponde exatamente a esse comando e a mais nenhum. npm test --watch continua a perguntar.
• * corresponde a qualquer texto, espaços incluídos. Bash(git commit *) corresponde a qualquer comando git commit, e também a git commit sozinho.
• Põe o * depois do subcomando. Bash(git log *) só autoriza git log, mas Bash(git *) autoriza todos os comandos git, incluindo git push e git reset --hard.
• O espaço antes do * conta. Bash(ls *) corresponde a ls -la mas não a lsof. Bash(ls*) corresponde aos dois.
• O Claude Code entende &&, ||, ; e |. Uma regra que autoriza npm test não aprova npm test && rm -rf build: cada parte tem de estar autorizada por si. As regras de bloqueio aplicam-se a cada parte, mesmo dentro de uma subshell.
• As regras de ficheiros (Read e Edit) usam padrões ao estilo do gitignore, relativos à pasta onde abriste o Claude. Um nome de ficheiro sozinho, como Read(.env), também corresponde a esse nome em qualquer subpasta. Para um caminho absoluto, começa com duas barras, como em Read(//etc/**). Nas definições de um projeto, uma única barra no início, como em Edit(/src/**), quer dizer a pasta do projeto, não a raiz do disco.
• As regras para a web usam o domínio: WebFetch(domain:docs.python.org).

Onde ficam as regras

• ~/.claude/settings.json, as tuas definições de utilizador: todos os projetos da tua máquina. Bom para preferências pessoais, como defaultMode, ou uma regra que bloqueia Read(~/.ssh/**).
• .claude/settings.json num projeto: partilhado com toda a gente que trabalha nele, se o puseres no git. Bom para os comandos de testes e de build do projeto.
• .claude/settings.local.json num projeto: só tu, só neste projeto. É aqui que o "Yes, and don't ask again" escreve.
• Definições geridas, distribuídas por uma organização: sobrepõem-se a tudo o resto e os utilizadores não as podem mudar.

Quando há regras em mais do que um ficheiro, as listas juntam-se, não se substituem. Uma regra de bloqueio em qualquer ficheiro trava a ação, seja o que for que os outros autorizem.

Escreve /permissions numa sessão para veres todas as regras em vigor e o ficheiro de onde vem cada uma. Também podes acrescentar e remover regras aí, mesmo enquanto o Claude está a trabalhar.

A caixa de confiança protege as regras do projeto

O .claude/settings.json de um projeto podia aprovar qualquer coisa, por isso o Claude Code não aplica as regras de autorizar até confiares na pasta. Da primeira vez que abres o Claude Code numa pasta com regras dessas, a caixa de confiança mostra-as:

⚠ This folder pre-approves 2 tool permissions in .claude/settings.json:
Bash(npm test) and Bash(git commit *)
These will apply without asking. Only proceed if you trust this configuration.

As regras de bloquear e de perguntar aplicam-se logo, com ou sem confiança, porque só restringem. Numa execução com claude -p, onde não há caixa de confiança, as regras de autorizar de uma pasta sem confiança são ignoradas, e o Claude Code avisa na saída de erros:

Ignoring 2 permissions.allow entries from .claude/settings.json: this workspace has not been trusted.

Se correres claude -p num repositório que não foste tu a escrever, acrescenta --setting-sources user, para que o Claude Code leia só as tuas definições e ignore os ficheiros do projeto.

Modo automático

No modo automático, o Claude trabalha sem os pedidos de rotina. As leituras e as edições dentro do projeto correm logo. As outras ações, como comandos de shell, pedidos à rede e edições fora do projeto, passam primeiro pelo classificador, que as compara com o que pediste.

Por predefinição, o classificador bloqueia, entre outras coisas:

• descarregar e correr código, como curl ... | bash
• enviar dados sensíveis para serviços externos
• publicações em produção e migrações de bases de dados
• force push e git reset --hard sobre trabalho por guardar em commit
• alterações a infraestrutura partilhada
• apagar ficheiros que já existiam antes da sessão

Quando bloqueia alguma coisa, o Claude vê o motivo e tenta outro caminho, ou pergunta-te. Um exemplo real: quando o pedido foi só "faz as duas", sem dizer o que mudar, o modo automático recusou uma delas, uma alteração ao ficheiro de configuração principal de um servidor web, com o motivo Modify Shared Resources. Quando uma mensagem seguinte indicou o ficheiro e a alteração exata, o classificador deixou passar. Bate certo com a documentação: um pedido na conversa só levanta um bloqueio quando diz qual é a ação e o que a torna arriscada.

O que convém saber:

• Os limites que dás na conversa contam. Se disseres "não faças push", o classificador bloqueia os pushes. Mas lê-os da conversa, por isso podem perder-se quando uma sessão longa é compactada. Para uma regra firme, usa uma regra de bloqueio.
• As regras ask continuam a perguntar-te em modo automático. São a ferramenta certa para "avança, mas fala comigo antes do push".
• Ao entrar em modo automático, as regras de autorizar demasiado largas, como Bash(*) ou Bash(python*), ficam desligadas, porque deixariam passar tudo sem o classificador ver. As regras estreitas, como Bash(npm test), ficam. As largas voltam quando sais do modo automático.
• Se o classificador bloquear 3 ações seguidas, ou 20 numa sessão, o modo automático faz uma pausa e o Claude Code volta a perguntar-te.
• As ações bloqueadas aparecem em /permissions, no separador Recently denied, onde podes carregar em r para tentar de novo com a tua aprovação.

O que nenhuma regra consegue aprovar

Algumas ações passam sempre por uma verificação, mesmo com uma regra de autorizar que lhes corresponda:

• Caminhos protegidos. Escritas em .git, .claude, .vscode, .bashrc, .zshrc, .gitconfig, .mcp.json e mais alguns ficheiros de configuração nunca são aprovadas por regras de autorizar. O modo Manual pergunta, o modo automático manda-as ao classificador.
• Apagamentos críticos. rm ou rmdir apontados à raiz do disco, a uma pasta de topo como /etc ou /usr, à tua pasta pessoal ou à própria pasta do projeto também nunca são aprovados por regras de autorizar.

Só o bypassPermissions salta a verificação dos caminhos protegidos, e mesmo ele pergunta antes de um apagamento crítico. Não o uses numa máquina de que gostas. Em Linux e macOS, o Claude Code recusa arrancar nesse modo como root ou com sudo.

Fontes

• Configure permissions, documentação do Claude Code (em inglês)
• Choose a permission mode, documentação do Claude Code (em inglês)
• Settings files and precedence, documentação do Claude Code (em inglês)
• Sandboxing, documentação do Claude Code (em inglês)