Claude Code

Permissões do Claude Code: regras allow, ask e deny, sintaxe de regras e ferramentas permitidas

Como funcionam as permissões do Claude Code e como permito ou bloqueio ferramentas específicas?

O Claude Code verifica cada chamada de ferramenta contra as regras de permissão nos seus arquivos de configuração. As regras ficam em permissions.allow, permissions.ask e permissions.deny, usam o formato Tool ou Tool(specifier) e são avaliadas primeiro deny, depois ask, depois allow. Use /permissions para ver todas as regras e o arquivo de origem de cada uma, ou passe --allowedTools e --disallowedTools para uma única sessão.

Esta página é uma tradução do guia em inglês. Comandos, chaves de configuração e código não foram alterados; em caso de diferença, vale a versão em inglês. Ler em inglês → · Outros idiomas: 简体中文 · 日本語 · 한국어 · Español

Saiba quando a configuração mudar

Quando uma configuração, flag ou regra de permissão dessas ferramentas mudar, você recebe um e-mail semanal (em inglês), conferido na documentação oficial.

Allow, ask e deny

  • Regras allow deixam o Claude Code usar a ferramenta correspondente sem perguntar a você.
  • Regras ask pedem confirmação toda vez que a ferramenta correspondente é usada.
  • Regras deny bloqueiam a ferramenta correspondente.
  • A ordem é deny, depois ask, depois allow. A primeira correspondência vence e a especificidade não muda a ordem, então um deny amplo como Bash(aws *) vence um allow mais restrito como Bash(aws s3 ls).
  • Uma regra deny com apenas o nome da ferramenta, como Bash, remove a ferramenta do contexto do Claude. Um deny com escopo, como Bash(rm *), mantém a ferramenta e bloqueia só as chamadas correspondentes.

As regras são aplicadas pelo Claude Code, não pelo modelo. Instruções no CLAUDE.md orientam o que o Claude tenta fazer, mas não mudam o que ele tem permissão para fazer.

Sintaxe de regras por ferramenta

  • Ferramenta inteira: Bash, Read ou WebFetch sem parênteses. Bash(*) é o mesmo que Bash.
  • Bash: Bash(npm run build) corresponde exatamente a esse comando. Bash(npm run *) corresponde a todos os scripts npm. Coloque o * depois do subcomando: Bash(git log *) permite só git log, enquanto Bash(git *) permite qualquer comando git.
  • Bash(ls *) exige um espaço depois de ls, então não corresponde a lsof. Bash(ls:*) é uma forma equivalente de escrever o curinga final.
  • Read e Edit usam padrões do gitignore. Read(./.env) bloqueia o arquivo .env no diretório atual, Read(./secrets/**) bloqueia uma pasta. Use regras Edit, não Write, para caminhos que nenhuma ferramenta pode alterar.
  • Caminhos: //path é absoluto a partir da raiz do sistema de arquivos, ~/path parte da sua pasta home, /path é relativo ao projeto do arquivo de configuração, e path ou ./path é relativo ao diretório atual.
  • WebFetch: WebFetch(domain:example.com) corresponde só a example.com. Adicione WebFetch(domain:*.example.com) para subdomínios.
  • MCP: mcp__github corresponde a todas as ferramentas do servidor github, mcp__github__get_* corresponde às ferramentas get_ dele, e mcp__github__create_issue corresponde a uma ferramenta.
  • Subagents: Agent(Explore) ou Agent(my-custom-agent). Coloque um em deny para impedir que o Claude use esse subagent.

Exemplo de configuração

.claude/settings.json

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)",
      "WebFetch(domain:docs.example.com)",
      "mcp__github__get_*"
    ],
    "ask": ["Bash(git push *)"],
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Bash(rm *)"
    ]
  }
}

Regras allow e additionalDirectories no .claude/settings.json de um projeto só entram em vigor depois que você aceita o diálogo de confiança do workspace para aquela pasta. Regras deny e ask valem imediatamente.

Ferramentas permitidas na linha de comando

  • --allowedTools (ou --allowed-tools): ferramentas que rodam sem pedir confirmação, com a mesma sintaxe de regras.
  • --disallowedTools (ou --disallowed-tools): regras deny para esta sessão. "mcp__*" remove todas as ferramentas MCP.
  • --tools: limita quais ferramentas nativas existem, por exemplo "Bash,Edit,Read".
  • --add-dir: adiciona diretórios de trabalho que o Claude pode ler e editar. Salve-os em permissions.additionalDirectories para mantê-los.

Terminal

claude -p "summarize recent changes" \
  --allowedTools "Bash(git log *)" "Bash(git diff *)" "Read" \
  --disallowedTools "Edit"

O que pede confirmação por padrão e o que "don't ask again" salva

  • Ferramentas somente leitura, como leitura de arquivos e Grep: sem confirmação dentro do seu diretório de trabalho e dos diretórios adicionais.
  • Comandos Bash: pedem confirmação, exceto um conjunto nativo de comandos somente leitura. "Yes, and don't ask again" é salvo permanentemente para aquele repositório e comando.
  • Edições e gravações de arquivos: pedem confirmação. "Don't ask again" dura só até o fim da sessão e não é salvo em arquivo.
  • WebFetch: pede confirmação, exceto um conjunto nativo de domínios de documentação pré-aprovados. A aprovação é salva por repositório e domínio.
  • WebSearch: pede confirmação. A aprovação é salva por repositório.

Uma aprovação salva é gravada como regra em .claude/settings.local.json na raiz do repositório git (resolvida através de worktrees até o checkout principal), então também vale em subdiretórios e worktrees. Aprovar um comando composto como git status && npm test salva uma regra separada para cada subcomando que precisou de aprovação, até 5 regras. Você pode abrir /permissions enquanto o Claude trabalha; uma regra adicionada ou removida vale a partir da próxima chamada de ferramenta do Claude.

Comandos Bash que nunca pedem confirmação e wrappers que o Claude Code enxerga por dentro

  • Comandos somente leitura rodam sem confirmação em todos os modos: o conjunto nativo inclui ls, cat, echo, pwd, head, tail, grep, find, wc, which, diff, stat, du, cd e formas somente leitura do git. O conjunto não é configurável; adicione uma regra ask ou deny para que um deles peça confirmação.
  • Alguns comandos somente leitura ainda pedem confirmação no modo Manual, por exemplo find, sort, sed ou git com um glob sem aspas, ou um cd para outro diretório combinado com git.
  • Antes de comparar, o Claude Code remove timeout, time, nice, nohup, stdbuf, command, builtin e zsh noglob, então Bash(npm test *) também corresponde a timeout 30 npm test. Ele também remove xargs puro (sem flags) e uma atribuição inicial de variáveis de ambiente conhecidas como seguras.
  • Executores como npx, docker exec, direnv exec, devbox run e mise exec não são removidos. Bash(devbox run *) corresponderia a qualquer coisa depois de run, então escreva uma regra exata por comando interno, como Bash(devbox run npm test).
  • Regras de prefixo não conseguem aprovar automaticamente wrappers de execução como watch, setsid, ionice e flock, nem find com -exec, -delete ou -fprint. Use uma regra exata para o comando completo, ou um hook PreToolUse.

O que uma regra deny de Bash não impede

Regras Bash comparam o texto do comando que o Claude escreve. Regras deny e ask valem quando qualquer subcomando corresponde, inclusive dentro de um subshell, uma substituição de comando ou um loop for. Elas não pegam o mesmo programa chamado de outro jeito.

  • Bash(curl *) impede curl https://example.com, mas não /usr/bin/curl https://example.com nem sh -c 'curl https://example.com'.
  • Bash(rm *) impede rm -rf build/, mas não /bin/rm -rf build/ nem bash -c 'rm -rf build/'.
  • Bash(git push *) impede git push origin main, mas não git -C . push origin main.
  • Padrões que tentam limitar argumentos, como Bash(curl http://github.com/ *), deixam passar flags antes da URL, https, redirecionamentos e variáveis.
  • Redirecionamentos de saída (>, >>, 2>) e destinos de tee são verificados contra suas regras Edit e diretórios de trabalho, então Bash(git commit *) permite o comando, mas não o local onde a saída é gravada.

Para um limite que valha independentemente do texto do comando, use as regras de rede e sistema de arquivos do sandbox, ou um hook PreToolUse que inspecione o comando completo. Para restringir o acesso à web, negue curl e wget e permita WebFetch(domain:...) para os sites em que você confia; regras WebFetch sozinhas não bloqueiam o acesso à rede enquanto Bash estiver permitido.

Quais configurações vencem

  • Um deny em qualquer nível não pode ser liberado por outro nível. Se as configurações de usuário permitem algo e as do projeto negam, fica negado, e o inverso também vale.
  • As managed settings têm a maior prioridade. Nem --allowedTools consegue sobrepor um deny gerenciado, enquanto --disallowedTools pode adicionar mais restrições.
  • allowManagedPermissionRulesOnly faz das managed settings a única fonte de regras de permissão.
  • Defina permissions.disableBypassPermissionsMode ou permissions.disableAutoMode como "disable" para bloquear esses modos. Eles são mais úteis nas managed settings.

Modos de permissão

As regras ficam acima do modo de permissão da sessão: default (Manual), acceptEdits, plan, auto, dontAsk ou bypassPermissions. Defina um com claude --permission-mode <mode> ou permissions.defaultMode nas configurações. dontAsk nega tudo que pediria confirmação, exceto ferramentas que suas regras allow já aprovam. Para rodar sem nenhuma confirmação, veja o guia sobre permitir todos os comandos no Claude Code.

Fontes

Documentação oficial (em inglês) usada para conferir este guia. Versão em inglês revisada em: 2026-10-18

Mais guias em português