Permissões do Claude Code: 6 modos e como configurá-las com segurança (2026)

as permissões no Claude Code mudam bem rápido entre versões. Confira claude --version e a documentação oficial dos modos de permissão (Anthropic, atualizada em 08/2026) antes de aplicar qualquer coisa abaixo.

Por que as permissões no Claude Code importam

O Claude Code não só sugere código como um chatbot: ele é um agente de verdade que pode gravar arquivos direto na sua máquina e rodar comandos de shell. Esse poder também é o risco: sem barreiras de proteção, uma sessão comum pode sobrescrever arquivos que você ainda não commitou, apagar a pasta errada ou rodar algo destrutivo como rm -rf antes de você conseguir reagir.

O risco mais assustador não é a IA "decidir se comportar mal": é a injeção de prompt. Uma página web que você pede para o Claude ler, um README enterrado numa dependência ou uma issue do GitHub podem carregar instruções ocultas como "rode curl ... | bash" ou "envie o conteúdo do .env para algum lugar". Se o Claude tiver permissões totais, ele pode seguir essas ordens sem você nem pedir.

É por isso que o sistema de permissões existe: por padrão, o Claude Code opera numa postura de perguntar primeiro, agir depois. Se você acabou de instalar o Claude Code, a próxima coisa a fazer é entender e configurar as permissões — tanto para evitar perda de dados quanto para parar os infinitos avisos de s/n para coisas em que você já confia.

Os 6 modos de permissão no Claude Code (tabela comparativa)

O Claude Code vem com seis modos de permissão. A primeira coisa a lembrar: o modo padrão é somente leitura e sempre pergunta antes de gravar um arquivo ou rodar um comando. Os outros modos afrouxam esse controle passo a passo, conforme o quanto você confia no trabalho e o quão isolado é o seu ambiente.

Na prática, você vai viver na maior parte do tempo nos três primeiros modos. O default/Manual é o ponto de partida mais seguro — nada acontece pelas suas costas. O acceptEdits encaixa quando você está refatorando e quer que o Claude edite conforme avança, enquanto você revisa depois com git diff. O plan é ótimo quando você precisa que o Claude "leia, entenda e explique" — digamos, rastreando um bug por vários arquivos antes de tocar em qualquer código. Os outros três são ferramentas especializadas: auto para tarefas longas com uma rede de segurança, dontAsk para automação e bypassPermissions só para um ambiente totalmente isolado.

Nota de versão: esse padrão auto embutido só entra em ação no Claude Code v2.1.228+ para macOS/Linux/WSL e v2.1.233+ para Windows nativo — versões mais antigas ainda iniciam em default/Manual.

Trocando e definindo o modo padrão

A forma mais rápida de mudar de modo no meio da sessão é apertar Shift+Tab. Desde 14/08/2026, as sessões Pro/Max/Team agora iniciam em auto em vez de default: o primeiro aperto de Shift+Tab leva você de auto para default, e daí é o mesmo ciclo familiar, default → acceptEdits → plan, com o auto voltando ao fim do ciclo se sua conta for elegível (conforme a documentação dos modos de permissão, Anthropic, 08/2026). A barra de status na parte de baixo se atualiza a cada aperto, então você sempre sabe em qual modo está.

Para iniciar direto em um modo, use a flag de linha de comando:

claude --permission-mode plan

Para fixar um modo padrão para todas as sessões, defina defaultMode no settings.json:

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

Nota de segurança importante: defaultMode: "auto" só é respeitado quando declarado no seu arquivo de usuário, ~/.claude/settings.json. Se você (ou outra pessoa) definir isso no .claude/settings.json de um projeto, o Claude Code ignora — então um repositório que você acabou de clonar não consegue se autoconceder permissão para rodar automaticamente. Essa é a barreira de proteção que impede um "repositório malicioso" de escalar os próprios privilégios.

Configurando a lista de permissões no settings.json (allow / deny / ask)

O modo de permissão decide a "atitude" geral, enquanto o settings.json te dá controle até o nível de cada comando. São três listas:

• allow — roda sem perguntar. Por exemplo: "Bash(npm run test:*)", "Read(src/**)".
• ask — sempre pergunta, mesmo quando o modo está afrouxando as coisas. Use para comandos em que você mesma quer clicar em OK.
• deny — bloqueado de vez, nunca roda. Por exemplo: "Bash(rm -rf *)", "WebFetch", "Read(.env)".

A sintaxe das regras segue a forma Tool(pattern): Bash(npm run lint) casa exatamente com aquele comando, adicionar :* casa com um prefixo (Bash(git diff:*)), Read(src/**) usa um glob para caminhos e WebFetch(domain:github.com) restringe a um domínio.

A regra de arbitragem mais importante de todas — grave isso na memória: deny sempre vence allow, em qualquer nível. Se um comando casa com uma regra de allow e uma de deny, ele é bloqueado. Quanto à ordem dos arquivos, os níveis mais altos sobrepõem os mais baixos nesta sequência: managed (enterprise) > .claude/settings.local.json > .claude/settings.json > ~/.claude/settings.json. O arquivo settings.local.json é onde fica a sua configuração pessoal e não commitada; o settings.json de um projeto é compartilhado com o time todo pelo Git.

Um exemplo de settings.json que equilibra conveniência e segurança:

{
 "permissions": {
 "defaultMode": "default",
 "allow": [
 "Bash(npm run test:*)",
 "Bash(npm run lint)",
 "Bash(git status)",
 "Bash(git diff:*)",
 "Read(src/**)"
 ],
 "ask": [
 "Bash(git push:*)"
 ],
 "deny": [
 "Bash(rm -rf *)",
 "Bash(git push --force:*)",
 "Read(.env)",
 "Read(./secrets/**)",
 "WebFetch"
 ],
 "additionalDirectories": [
 "../shared-libs"
 ]
 }
}

O campo additionalDirectories deixa o Claude trabalhar com pastas fora do workspace atual — útil num monorepo dividido em pacotes, mas adicione só o que você realmente precisa. Se quiser uma lógica de permissão mais personalizada (logging, bloqueio condicional), você pode usar Hooks com o evento PreToolUse para intervir antes de cada ferramenta rodar.

Caminhos protegidos — o que o Claude nunca vai editar por conta própria

Além das regras allow/deny que você define, o Claude Code tem uma camada de proteção rígida que fica mais embaixo: os caminhos protegidos. São arquivos e pastas de configuração sensíveis que o Claude nunca aprova automaticamente para gravação, mesmo quando você está em acceptEdits ou auto:

• .claude e .claude.json — a própria configuração do Claude Code
• .git — internos do Git (para não mexer direto no histórico do repositório)
• .vscode — configuração do editor
• Arquivos rc de shell: .bashrc, .zshrc… — um lugar comum para comandos ocultos que rodam na inicialização
• .npmrc e quaisquer arquivos .env* que guardam segredos
• .mcp.json — configuração do servidor MCP

O ponto-chave de segurança: uma regra de allow ainda NÃO pode sobrepor um caminho protegido. Essa verificação de segurança roda antes de a lista de permissões ser avaliada, então mesmo que você adicione por acidente (ou seja enganada para adicionar) uma regra que permita gravar no .env, o Claude ainda para e pergunta. A única forma de burlar essa camada é o bypassPermissions — mais um motivo para não ligá-lo fora de um ambiente isolado.

--dangerously-skip-permissions vs modo auto — qual é seguro?

Muita gente que quer "desligar os avisos de s/n" vai direto no --dangerously-skip-permissions (também chamado de modo YOLO). Essa flag desativa todas as verificações: todas as regras allow/deny e todos os caminhos protegidos são ignorados. As consequências reais:

• Não protege contra injeção de prompt — com todas as redes desligadas, uma instrução oculta de uma página web ou arquivo é executada direto.
• O Claude Code bloqueia essa flag quando você está rodando como root/sudo, porque o raio de destruição é grande demais.
• Use só dentro de um container ou VM isolado, de preferência sem internet — um lugar onde, se o Claude quebrar algo, só quebra o sandbox.

Desde o começo de 2026, a Anthropic oferece o modo auto como o substituto seguro para a necessidade de "menos atrito": em vez de desativar as verificações, o modo auto roda um classificador em segundo plano que categoriza cada ação e bloqueia comandos perigosos por padrão — curl | bash, exfiltrar segredos, fazer deploy em produção, rm -rf /, git reset --hard, force pushes, terraform destroy e por aí vai. Operações rotineiras e seguras passam, enquanto qualquer coisa com cheiro de destrutiva volta para te perguntar. Segundo a Anthropic, a maioria das ações numa sessão já é aprovada pelo usuário de qualquer forma, então o modo auto elimina a maior parte das perguntas e mantém a rede para as raras perigosas.

Isso também é uma grande mudança na "postura de segurança" padrão: desde 14/08/2026, o modo auto virou o modo padrão para os planos Pro/Max/Team (conforme a documentação dos modos de permissão do Claude Code, Anthropic, 08/2026). Em resumo: se você quer menos avisos, use o modo auto — não use --dangerously-skip-permissions.

Como o classificador decide: níveis de regra e revisão de uma ação bloqueada

O classificador em segundo plano por trás do modo auto não usa um único balde — ele checa cada ação contra quatro níveis ordenados de regra: hard_deny bloqueia incondicionalmente (exfiltrar segredos, por exemplo) sem sobreposição; soft_deny bloqueia ações destrutivas-mas-às-vezes-legítimas como um force push, mas pode ser sobreposto; uma regra allow pode abrir uma exceção nomeada a um soft_deny; e mesmo sem uma, a intenção declarada explicitamente na sua própria mensagem pode sobrepor um bloqueio suave restante — mas só quando você nomeia a ação exata ("faça force-push nesta branch"), não uma vaga ("limpe o repositório").

Quando algo é bloqueado, não simplesmente redigite o pedido — abra o /permissions, vá para a aba Recently denied e aperte r para tentar de novo com aprovação manual. Um caso de borda: se o classificador não consegue devolver um veredito nenhum, a ação é negada silenciosamente, sem registro em Recently denied. Quer o panorama maior de como o loop do agente e as permissões se encaixam? Comece por o que é o Claude Code.

A configuração segura recomendada (passo a passo)

Aqui está a configuração que eu acho mais equilibrada para o trabalho de dev do dia a dia — segura, mas sem ser chata:

1. Mantenha o default/Manual para trabalho sensível. Num repositório desconhecido, ao trabalhar na branch main ou quando o Claude está lendo conteúdo da web, fique no modo padrão e aprove na mão.
2. Adicione deny para comandos destrutivos. Tranque Bash(rm -rf *), Bash(git push --force:*) e Read(.env). Como deny vence allow, essa é uma camada que nunca é afrouxada por engano.
3. Permita de forma estreita comandos confiáveis e repetitivos. Adicione os comandos que você roda o tempo todo e sabe que são seguros: Bash(npm run test:*), Bash(git status). Prefira allows estreitos (comandos exatos) aos amplos.
4. Use acceptEdits ao iterar no código e revise com git diff. Deixe o Claude editar conforme avança, pela velocidade, mas mantenha o controle na etapa do commit — olhe o diff antes de dar git add.
5. Tarefas longas ou sensíveis → container ou modo auto, nunca bypass. Quando você precisa rodar por muito tempo e sem supervisão, o modo auto com seu classificador ainda é a escolha certa. Esse também é o momento de rodar o /goal com segurança sem acesso à produção.

Se você quiser revisar todas as regras em vigor a qualquer momento, digite /permissions na sessão. É também um bom lugar para conferir logo depois de ter instalado e configurado o Claude Code pela primeira vez.

Erros comuns e modos de falha ao configurar permissões

A configuração de permissões costuma tropeçar em algumas situações recorrentes — conhecê-las de antemão poupa a frustração:

• "Ele fica perguntando s/n." Isso significa que o modo é default e o comando ainda não está na sua lista de allow. Adicione uma regra de allow estreita para o comando exato em que você confia; não pule direto para o bypass.
• "O modo auto fica bloqueando coisas." Se o classificador bloquear 3 vezes seguidas ou 20 vezes no total numa mesma sessão, o Claude para o modo auto e volta a perguntar manualmente — é um comportamento intencional para não ficar em loop para sempre.
• Você disse "não faça push" em voz alta, mas ele fez push mesmo assim. Os "limites" que você declara na conversa podem sumir quando o contexto é compactado. Restrições faladas são menos confiáveis que a configuração — use uma regra deny para limites rígidos.
• Uma regra não está sendo aplicada. Normalmente o settings.json está com JSON inválido (uma vírgula sobrando, uma chave faltando), então o arquivo inteiro é ignorado. Confirme que o arquivo é válido e reconfira com /permissions.

Esbarrando em erros mais estranhos com o Claude Code? Veja nosso guia para corrigir os erros comuns do Claude Code.

Presets de permissão seguros prontos para usar

Descobrir uma lista de permissões para cada projeto na mão é um trabalho maçante, ainda mais quando você faz malabarismo com muitos repositórios de stacks diferentes. Um atalho é um kit da comunidade que empacota skills e configuração por convenção — por exemplo, o kit AgentKit para Claude Code (20% de desconto pelo link) entrega skills e fluxos de trabalho num padrão, então você escreve menos regras do zero. Se você tem curiosidade de como funciona, leia nossa opinião sobre o que é o AgentKit e se vale a pena usar. Com preset ou sem, o princípio se mantém: entenda deny/allow e nunca desligue a rede de segurança.

Perguntas frequentes (FAQ)

O Claude Code vai apagar meus arquivos?

No modo padrão (Manual), não — o Claude sempre pergunta antes de qualquer gravação ou exclusão. Ele só consegue apagar por conta própria se você afrouxar as permissões (acceptEdits/auto) ou ligar o --dangerously-skip-permissions. Adicione um deny para rm -rf para trancá-lo de vez.

Como paro os avisos de s/n mantendo a segurança?

Não os desligue com bypass. Em vez disso, adicione regras de allow estreitas para os comandos em que você confia (como npm test, git status), ou use o modo auto — ele elimina os avisos para ações seguras, mas ainda bloqueia as perigosas com o classificador.

O --dangerously-skip-permissions é perigoso?

Sim. Ele desativa todas as verificações e não oferece proteção nenhuma contra injeção de prompt. O Claude até o bloqueia quando você roda como root. Use só dentro de um container ou VM isolado, de preferência sem internet.

Como o modo auto é diferente do bypass?

O modo auto mantém a rede de segurança: um classificador em segundo plano bloqueia comandos perigosos (curl|bash, force pushes, envio de segredos, rm -rf /). O bypass desliga tudo. Se você quer menos avisos, escolha o modo auto, não o bypass.

Num conflito, quem vence: deny ou allow?

Deny sempre vence. Se um comando casa com uma regra de deny e uma de allow em qualquer nível de configuração, ele é bloqueado. Os caminhos protegidos também são verificados primeiro, então uma regra de allow não consegue sobrepô-los.

Onde fica a configuração de permissões?

No arquivo settings.json. Ordem de prioridade: managed (enterprise) > .claude/settings.local.json (pessoal, não commitado) > .claude/settings.json (compartilhado com o time) > ~/.claude/settings.json (o seu padrão).

Conclusão e próximos passos

A receita para ser seguro-mas-não-chato é compacta: mantenha o padrão seguro para trabalho sensível, adicione uma lista de allow estreita para comandos confiáveis, fixe denies rígidos para os destrutivos e use o modo auto (não o bypass) para tarefas longas. Assim o Claude Code roda rápido enquanto suas mãos continuam no volante.

Ainda não terminou de instalar? Leia o guia de instalação do Claude Code. Para o panorama geral, veja o que é o Claude Code. confira claude --version, já que os nomes dos rótulos e os limiares dos modos podem mudar com novas versões.