Permissões e Modos de Permissão

Intermediário

Última verificação: 2026-07-14.

A sintaxe exata das regras e os nomes dos modos evoluem — confirme na documentação oficial de permissões e modos de permissão do Claude Code.

Confirme na fonte oficial.

What you'll learn

• O que significam os três veredictos de permissão (allow / ask / deny)
• Como uma regra de permissão associa uma ferramenta a um padrão
• Os seis modos de permissão e quando usar cada um
• Como o modo auto substitui os prompts por um classificador de segurança
• Como montar uma allowlist inicial sensata que reduz prompts sem perder segurança
• Onde armazenar as regras de permissão do projeto versus as pessoais

As permissões decidem o que o Claude Code pode fazer sem parar para perguntar a você. Ajuste-as bem e você obtém fluidez sem perder o controle; ajuste-as mal e você acaba aprovando tudo automaticamente ou se afogando em prompts.

Os três veredictos

Toda ação potencial se resolve em um destes:

Pressione Enter ou Espaço para virar o cartão. Use as setas esquerda e direita para navegar entre os cartões.Termo exibido.

1 / 3

As regras geralmente associam uma ferramenta a um padrão, por exemplo, permitir Bash(npm run test:*) ou negar Read(./.env).

Permitir uma ferramenta + padrão

Bash(npm run test:*)

Negar uma ferramenta + padrão

Read(./.env)

Modos de permissão

Um modo define a postura geral de uma sessão. São seis. Alterne entre os mais comuns com Shift+Tab ou defina permissions.defaultMode nas configurações.

Modo	Executa sem perguntar	Use quando
default (exibido como Manual)	Somente leituras	Trabalho do dia a dia, mudanças sensíveis
acceptEdits	Leituras, edições de arquivo, comandos comuns de sistema de arquivos	Uma sessão de edição confiável e bem delimitada
plan	Somente leituras; propõe, nunca edita	Tarefas grandes/arriscadas — veja Modo Plano
auto	Tudo, filtrado por um classificador de segurança	Tarefas longas em que a fadiga de prompts é o risco real
dontAsk	Apenas ferramentas pré-aprovadas; todo o resto é negado	CI e scripts em ambiente restrito
bypassPermissions	Tudo, sem verificações	Apenas sandboxes/contêineres — nunca em uma máquina com segredos

Modo auto

O auto é o meio-termo entre perguntar sobre tudo e desligar a segurança. Em vez de perguntar a você, um modelo classificador separado revisa cada ação antes de ela ser executada e bloqueia qualquer coisa que escale além do que você pediu, toque em infraestrutura que ele não reconhece ou pareça motivada por conteúdo hostil que o Claude acabou de ler. Regras explícitas de ask continuam parando e perguntando a você.

Ele bloqueia coisas como curl | bash, force pushes, deploys e migrações em produção e envio de segredos para endpoints externos — enquanto deixa o trabalho rotineiro (edições locais, instalação de dependências declaradas, HTTP somente leitura, push para a sua própria branch) passar direto. Se ele bloquear a mesma ação repetidamente, o modo auto pausa e devolve os prompts a você.

O modo auto não é uma garantia de segurança — ele reduz os prompts, não elimina a necessidade de revisar operações sensíveis. A disponibilidade depende do seu plano, do modelo e (no Team/Enterprise) de uma opção habilitada pelo administrador.

Watch out

• O bypassPermissions pertence a uma sandbox. Rodar com todos os prompts desligados na sua máquina real é como um agente acaba tocando em algo que não deveria. Reserve isso para ambientes descartáveis — se o que você realmente quer é menos prompts, use o modo auto. Veja Fortalecendo Execuções Autônomas em /docs/security/hardening-autonomous-runs.

Uma allowlist inicial sensata

O objetivo: pré-permitir as coisas seguras e repetitivas; manter as coisas destrutivas em ask ou deny.

Guided walkthrough1 of 3

1. Ler arquivos, executar seus comandos de teste/lint/build, git status/diff.

Armazene as regras do projeto em settings.json (compartilhado) e as substituições pessoais em settings.local.json.

Pro tip

• Deixe-o aprender com seus prompts: aprove o mesmo comando seguro algumas vezes e você saberá exatamente o que adicionar à sua allowlist — transformando prompts repetidos em uma regra única.

Key takeaways

• Três veredictos: allow (sem prompt), ask (padrão — pause e confirme), deny (nunca).
• As regras associam uma ferramenta a um padrão, como Bash(npm run test:*) ou Read(./.env).
• Seis modos definem a postura da sessão: default (Manual), acceptEdits, plan, auto, dontAsk, bypassPermissions.
• O modo auto filtra cada ação por um classificador de segurança em vez de perguntar a você — essa é a ferramenta contra a fadiga de prompts, não o bypassPermissions.
• Monte uma allowlist: permita o seguro + repetitivo, pergunte para o risco médio, negue o destrutivo.
• As regras compartilhadas vão em settings.json; as substituições pessoais em settings.local.json.

Teste-se

0/5

1. 1O que o veredicto padrão 'ask' faz para uma ação que não é explicitamente permitida nem negada?
2. 2Qual modo de permissão é seguro APENAS em sandboxes ou contêineres, nunca em uma máquina com segredos?
3. 3Você quer bem menos prompts de permissão em uma tarefa longa, mas ainda quer uma rede de segurança. Qual modo?
4. 4Onde você deve armazenar as regras de permissão compartilhadas do projeto versus as substituições pessoais?
5. 5Qual destas pertence à lista 'deny' em uma allowlist inicial sensata?

Próximos passos

• settings.json: O Sistema de Configuração
• Hooks — imponha regras de forma determinística, além de allow/deny
• Segurança e Uso Responsável