Pular para o conteúdo principal

Permissões e Modos de Permissão

Intermediário
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
  • Por que o modo auto agora é o modo inicial das sessões interativas — e como desativá-lo
  • 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.

ModoExecuta sem perguntarUse quando
default (exibido como Manual)Somente leiturasTrabalho do dia a dia, mudanças sensíveis
acceptEditsLeituras, edições de arquivo, comandos comuns de sistema de arquivosUma sessão de edição confiável e bem delimitada
planLeituras, mais comandos aprovados pelo classificador quando o modo auto está disponível; nunca edita o seu código-fonteTarefas grandes/arriscadas — veja Plan Mode
auto (o modo inicial das sessões interativas desde a v2.1.283)Tudo, filtrado por um classificador de segurançaTarefas longas em que a fadiga de prompts é o risco real
dontAskLeituras de arquivos nos seus diretórios de trabalho e ferramentas pré-aprovadas; tudo o que geraria um prompt é negadoCI e scripts em ambiente restrito
bypassPermissionsTudo, sem verificaçõesApenas sandboxes/contêineres — nunca em uma máquina com segredos

O modo auto agora é o padrão do Claude Code​

Desde o Claude Code v2.1.283, o auto é o modo inicial integrado das sessões interativas de terminal e do VS Code em todos os planos e provedores. Nas versões anteriores, ele era o padrão para novas sessões apenas nos planos Pro, Max e Team, a partir de 14 de agosto de 2026. A justificativa da Anthropic (a partir de testes próprios com mais de 1.000 usuários pagantes): o classificador pegou 89% das ações prejudiciais contra 13,6% da revisão manual — porque usuários habituados aceitavam cerca de 97% dos prompts manuais sem lê-los.

Duas exceções preservam a sua intenção:

  • Se você definiu permissions.defaultMode nas suas configurações de usuário, ele permanece como está, a menos que você aceite um prompt único de troca no aplicativo.
  • Se a sua organização gerencia o padrão (configurações gerenciadas do Team/Enterprise), nada muda automaticamente.

Você sempre pode alternar os modos no meio da sessão com Shift+Tab. Mudança relacionada que já está em vigor nesses planos: as chamadas ao classificador que o modo auto faz não contam mais para os seus limites de uso.

Ative antes (antes de 14 de ago) — defina auto como padrão

~/.claude/settings.json
{
"permissions": {
  "defaultMode": "auto"
}
}

Mantenha o comportamento antigo de prompts depois de 14 de ago

~/.claude/settings.json
{
"permissions": {
  "defaultMode": "default"
}
}

Como o modo auto realmente funciona​

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, rm -rf em variáveis não resolvidas, adulteração de transcrições, comandos git destrutivos que descartam alterações não commitadas 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. Se você roda de forma realmente autônoma (cron, sessões na nuvem, CI), combine-o com Fortalecendo Execuções Autônomas — o auto ainda não é o bypassPermissions.

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.
  • Desde a v2.1.283, o auto é o modo inicial das sessões interativas de terminal e do VS Code em todos os planos; um defaultMode definido por você permanece, e os padrões gerenciados pela organização não são alterados.
  • 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/6
  1. O que o veredicto padrão 'ask' faz para uma ação que não é explicitamente permitida nem negada?
  2. Qual modo de permissão é seguro APENAS em sandboxes ou contêineres, nunca em uma máquina com segredos?
  3. Você quer bem menos prompts de permissão em uma tarefa longa, mas ainda quer uma rede de segurança. Qual modo?
  4. Onde você deve armazenar as regras de permissão compartilhadas do projeto versus as substituições pessoais?
  5. Qual destas pertence à lista 'deny' em uma allowlist inicial sensata?
  6. Em 14 de agosto de 2026, o que acontece em um plano Pro se você já tinha definido permissions.defaultMode como 'default' nas suas configurações de usuário?

Próximos passos​