O Claude Code vive pedindo permissão? Resolva sem --dangerously-skip-permissions

Aprovar npm test pela quadragésima vez é só ruído. O Claude Code tem tudo de que você precisa para silenciar os prompts chatos e manter os perigosos. Só que isso está espalhado por três arquivos e seis modos.

Por Aslan, equipe Pet Island · Atualizado em 26 de out. de 2026 · 5 min de leitura

RESPOSTA CURTA

Coloque os comandos que você sempre aprova em permissions.allow (por exemplo, Bash(npm run *)), os que sempre devem parar em ask ou deny e escolha um modo de permissão adequado à tarefa: acceptEdits para muita edição, auto para o trabalho rotineiro, plan para leitura. As regras são verificadas na ordem deny → ask → allow, então um deny nunca pode ser sobrescrito. Use /permissions para ver de onde vem cada regra. Deixe --dangerously-skip-permissions para contêineres descartáveis.

Por que o Claude Code pergunta tanto

No modo padrão (chamado de Manual na CLI), o Claude Code pede confirmação na primeira vez que usa cada ferramenta e pergunta de novo para cada comando de shell que ainda não tem permissão para executar. O prompt é o momento em que você pode impedir um rm errado ou um git push acidental, então vale a pena mantê-lo. O problema é que ele também aparece para as centenas de coisas inofensivas que um agente faz em uma sessão.

Três coisas decidem se você vê um prompt: as regras nos seus arquivos de configuração, o modo de permissão em que você está e as respostas que você deu antes com “Sim, e não perguntar novamente”. Para acabar com o ruído, é preciso ajustar as três.

O Claude Code v2.1.283 e posteriores iniciam sessões interativas no terminal e no VS Code no modo auto, em todos os planos e provedores. No modo auto, um classificador em segundo plano compara comandos e requisições de rede com o que você pediu, em vez de pedir confirmação para ações rotineiras. Se você ainda vê um prompt para tudo, confira a barra de status: “⏸ manual mode on” significa que você está no modo padrão.

Regras allow, ask e deny

As regras ficam em permissions em um arquivo de configuração. Este exemplo vem direto da referência de configurações da Anthropic:

~/.claude/settings.jsonCopiar

{

"permissions": {

"allow": ["Bash(npm run *)"],

"ask": ["Bash(git push *)"],

"deny": ["Read(./.env)"],

"defaultMode": "acceptEdits"

}

allow: executa sem perguntar.
ask: sempre pergunta, mesmo em modos que aprovariam a ação.
deny: nunca executa.

A ordem é o que importa: deny, depois ask, depois allow. A primeira correspondência vence, e a especificidade não muda a ordem. Uma regra allow não consegue abrir uma exceção em uma regra deny, e se uma ferramenta for negada em qualquer nível, nenhum outro nível pode permiti-la. As regras são aplicadas pelo próprio Claude Code, não pelo modelo, então escrever “nunca faça push” no CLAUDE.md não tem o mesmo efeito que uma regra deny.

Como escrever uma regra

Regra	O que ela abrange
`Bash(npm run *)`	`npm run build`, `npm run test --watch`, mas não `npm install`
`Bash(git log *)`	Apenas `git log …`. Compare com `Bash(git *)`, que permite todos os comandos git.
`Bash(ls:*)`	O mesmo que `Bash(ls )`: `:` é outra forma de escrever um curinga no final
`Read(./.env)`	A leitura desse arquivo. Regras Read e Edit usam padrões do gitignore
`Edit(//Users/alice/notes/**)`	Um caminho absoluto. Uma única `/` no início é relativa ao arquivo de configuração, então caminhos absolutos precisam de `//`
`WebFetch(domain:example.com)`	Apenas `example.com`. Adicione `WebFetch(domain:*.example.com)` para subdomínios
`mcp__github__*`	Todas as ferramentas do servidor MCP `github`. Regras com parênteses depois de `mcp__` são ignoradas

No Windows, as regras de PowerShell têm o mesmo formato das regras de Bash.

Qual arquivo de configuração usar

Escopo	Arquivo	Use para
Usuário	`~/.claude/settings.json` (Windows: `%USERPROFILE%\.claude\settings.json`)	Seus próprios hábitos, em todos os projetos
Projeto, compartilhado	`.claude/settings.json`	Regras que toda a equipe deve receber (faça commit dele)
Projeto, local	`.claude/settings.local.json`	Suas regras pessoais para um repositório (sem commit)
Gerenciado	`managed-settings.json` e outras fontes gerenciadas	Política da empresa; nada pode sobrescrevê-la

Precedência, da maior para a menor: gerenciado, linha de comando, projeto local, projeto compartilhado, usuário. Chaves de lista como permissions.allow são combinadas entre os arquivos, não substituídas. Dois detalhes costumam confundir:

Os arquivos de configuração são JSON estrito: um comentário // ou uma vírgula sobrando no final é erro de sintaxe, e o arquivo inteiro é ignorado.
Regras allow em um arquivo de projeto compartilhado só valem depois que cada colega confia na pasta. Regras deny e ask valem imediatamente.

A maioria das alterações vale para a sessão em andamento sem reiniciar, incluindo permissions e hooks. Para ver o que realmente foi carregado, execute /status (a linha Setting sources) ou /permissions, que lista cada regra e o arquivo de onde ela veio.

O que “Sim, e não perguntar novamente” realmente salva

Responder a um prompt com “não perguntar novamente” grava uma regra para você em .claude/settings.local.json, na raiz do repositório git. Quanto tempo ela dura depende da ferramenta:

Ferramenta	Memorizado
Comandos Bash	Permanentemente, por repositório e comando
Edições de arquivo	Até o fim da sessão
WebFetch	Permanentemente, por repositório e domínio

Então, se o Claude pede para editar arquivos a cada nova sessão, isso é intencional: aprovações de edição de arquivo valem por sessão. Em vez disso, use o modo acceptEdits ou uma regra allow Edit(...). E se um comando continua perguntando mesmo depois de “não perguntar novamente”, procure uma regra ask em um arquivo de projeto ou gerenciado. Uma regra allow no seu arquivo local não tem prioridade sobre ela.

Modos de permissão e quando usar cada um

Modo	O que faz	Bom para
`default` (Manual)	Pede confirmação no primeiro uso de cada ferramenta	Repositórios desconhecidos, trabalho arriscado
`acceptEdits`	Aceita edições de arquivo sem perguntar	Refatorações longas que você vai revisar no git
`plan`	Lê e planeja, não altera nada	Explorar uma base de código, projetar uma mudança
`auto`	Sem prompts rotineiros; um classificador verifica antes os comandos e as requisições de rede	Trabalho do dia a dia
`dontAsk`	Não pede confirmação	Scripts e automação
`bypassPermissions`	Pula os prompts, inclusive gravações em `.git` e `.claude`	Apenas contêineres ou VMs isolados

Pressione Shift+Tab para alternar entre os modos. A partir do auto, o primeiro toque vai para o default e depois default → acceptEdits → plan. Defina o modo inicial com permissions.defaultMode; observe que auto e bypassPermissions só têm efeito nas configurações de usuário ou gerenciadas, não em um arquivo de projeto.

Algumas coisas sempre pedem confirmação, em todos os modos, inclusive o bypass: regras ask explícitas, perguntas que o Claude faz a você e rm em caminhos críticos, entre outras. Administradores podem desativar os modos arriscados definindo permissions.disableBypassPermissionsMode ou permissions.disableAutoMode como "disable".

Sobre --dangerously-skip-permissions

--dangerously-skip-permissions é o mesmo que --permission-mode bypassPermissions. A documentação da Anthropic é direta: use apenas em ambientes isolados, como contêineres, VMs ou dev containers sem acesso à internet. Ele se recusa a rodar como root no Linux e no macOS e, depois que você aceita o aviso, define skipDangerousModePermissionPrompt nas suas configurações de usuário.

Se o que você realmente quer é “parar de perguntar sobre coisas chatas”, o modo auto com algumas regras allow resolve, sem abrir mão dos prompts que importam.

O sandbox: menos prompts com uma rede de segurança

O Claude Code pode executar comandos de shell em um sandbox. Ele vem desativado por padrão; ative com /sandbox ou sandbox.enabled: true. Um modo do sandbox aprova automaticamente os comandos em sandbox; o outro continua perguntando. O sandbox cobre apenas comandos de shell: ferramentas de arquivo, servidores MCP e hooks rodam fora dele.

Ele funciona no macOS, no Linux e no WSL2. No Windows nativo o sandbox não funciona, e os comandos rodam sem sandbox. Esse é mais um motivo para manter uma lista ask curta por lá.

Uma configuração que funciona

Este é um ponto de partida razoável para um projeto JavaScript. Ajuste os comandos à sua stack:

~/.claude/settings.jsonCopiar

{

"permissions": {

"allow": [

"Bash(npm run *)",

"Bash(npx tsc *)",

"Bash(git status)",

"Bash(git diff *)",

"Bash(git log *)"

"ask": [

"Bash(git push *)",

"Bash(npm publish *)"

"deny": [

"Read(./.env)",

"Read(./.env.*)"

]

}

Comece com uma lista de permissões de comandos somente leitura e de teste.
Coloque em ask tudo o que sai da sua máquina (push, publish, deploy).
Negue o acesso a segredos, sem exceção.
Trabalhe em auto ou acceptEdits e mude para o modo plan quando estiver explorando.
A cada poucos dias, abra .claude/settings.local.json e remova as regras que o “não perguntar novamente” adicionou.

Quando os prompts que restam aparecem no lugar errado

Depois do ajuste, você só deve receber perguntas sobre coisas que merecem uma decisão. O problema que resta é onde a pergunta aparece: em uma aba de terminal atrás do navegador, onde o agente pode esperar vinte minutos até você perceber.

O Pet Island leva essas perguntas para uma pequena ilha no topo da sua tela. Quando o Claude Code precisa de permissão, a solicitação aparece lá com o comando ou o diff, e você permite, nega ou permite sempre sem trocar de janela. As perguntas e os planos do Claude Code também funcionam pela ilha e, se a ilha estiver fechada, o Claude Code simplesmente volta a perguntar no terminal.

PERGUNTAS FREQUENTES

Como faço o Claude Code parar de pedir permissão para cada comando?

Adicione os comandos em que você confia a permissions.allow em ~/.claude/settings.json, por exemplo "Bash(npm run *)", e use o modo auto ou acceptEdits. Mantenha os comandos arriscados em permissions.ask para que eles continuem parando.

Por que o Claude Code volta a pedir permissão para editar arquivos depois que eu disse para não perguntar novamente?

As aprovações de edição de arquivo só duram até o fim da sessão. Use o modo acceptEdits ou uma regra allow Edit(...) se quiser que as edições fiquem aprovadas entre sessões.

Uma regra allow pode sobrescrever uma regra deny?

Não. As regras são verificadas na ordem deny, ask, allow, e a primeira correspondência vence. Uma ferramenta negada em qualquer nível não pode ser permitida em outro.

O --dangerously-skip-permissions é seguro?

A Anthropic o recomenda apenas em ambientes isolados, como contêineres ou VMs sem acesso à internet. Ele também pula os prompts para gravações em .git e .claude.

Onde o “Sim, e não perguntar novamente” salva a regra?

Em .claude/settings.local.json, na raiz do repositório git.

O sandbox do Claude Code funciona no Windows?

Não no Windows nativo; lá os comandos rodam sem sandbox. Ele funciona no macOS, no Linux e no WSL2.

Fontes

Todas as configurações e comportamentos desta página foram conferidos com estas páginas em 26 de outubro de 2026. Os agentes mudam rápido; se algo não bater mais, vale o que diz a página oficial.

CONTINUE LENDO

Claude Code