Claude Code --dangerously-skip-permissions: o que a flag faz, o que não faz e o que usar no lugar dela

O que faz ao certo o claude --dangerously-skip-permissions?

Arranca o Claude Code em modo bypassPermissions. A referência da CLI da Anthropic define a flag como «equivalente a --permission-mode bypassPermissions», e a página dos modos de permissão explica que este modo «desativa os pedidos de permissão e as verificações de segurança, de forma que as chamadas de ferramentas são executadas de imediato, incluindo as escritas em caminhos protegidos». Edições de ficheiros, comandos de shell, pedidos web e ferramentas MCP passam a correr com o teu utilizador, sem perguntar nada.

Os «caminhos protegidos» são a parte que a maioria dos tutoriais deixa de fora. Em todos os outros modos, uma escrita em .git, .vscode, .claude, .mcp.json ou num perfil de shell como o .zshrc dá origem a um pedido de permissão, vai ao classificador ou é recusada. Em modo bypass, a tabela da documentação diz «Permitida». Ora, esses ficheiros são executados mais tarde por outro programa, e é esse o mecanismo por trás da maioria das fugas à sandbox divulgadas em 2026.

Eis o que sai e o que fica:

Numa execução com -p não há ninguém para responder, por isso as chamadas que ainda dariam origem a uma pergunta são simplesmente recusadas.

O aviso da Anthropic cabe numa linha: «o bypassPermissions não oferece qualquer proteção contra prompt injection nem contra ações não intencionais».

Que modos de permissão tem o Claude Code, e o bypass já vem ativado?

Não vem. O Claude Code tem seis modos de permissão (os permission modes da documentação) e o bypassPermissions nunca é a predefinição de origem. Nos planos Pro, Max e Team, uma sessão nova no terminal arranca em auto (a partir da v2.1.228). Com um plano Enterprise, uma chave de API da Console, Bedrock, Foundry, claude -p ou o Agent SDK, arranca em default, que a interface apresenta como Manual.

O modo de arranque decide-se por esta ordem: primeiro a flag, depois permissions.defaultMode num ficheiro de settings, por fim a predefinição de origem.

Há aqui um pormenor que conta se costumas clonar repositórios alheios. A referência de settings indica que auto e bypassPermissions «não têm efeito a partir das settings de projeto nem das locais», e acrescenta: «Antes da v2.1.257, o bypassPermissions tinha efeito a partir de qualquer ficheiro.» Nas versões mais antigas, um .claude/settings.json versionado no repositório podia escolher o modo bypass por ti, atrás de um aviso mostrado uma única vez.

Dá para ativar o bypass permissions durante a sessão, com o Claude Code já aberto?

Só se a sessão tiver sido lançada com o bypass disponível. A documentação não deixa margem: «Não podes entrar em bypassPermissions a partir de uma sessão que iniciaste sem ele ativado.» Para deixares a porta aberta, lança o Claude Code com --allow-dangerously-skip-permissions, que acrescenta o modo ao ciclo do Shift+Tab, a seguir ao plan. Um hook também não o consegue conceder.

Essa flag traz um efeito secundário. Com o bypass disponível num terminal interativo, os bloqueios do modo plan deixam de ser aplicados: «o Claude continua a receber a instrução de planear sem editar, mas uma edição de ficheiro ou um comando de shell que tente durante o planeamento corre sem pedir permissão». O modo plan passa a ser uma instrução dada ao modelo e deixa de ser um bloqueio imposto pelo cliente, exceto nas execuções com -p, no Agent SDK e no painel de chat do VS Code.

O --dangerously-skip-permissions funciona na extensão do VS Code?

Funciona, atrás de um interruptor que vem desligado. A extensão só mostra Bypass permissions no indicador de modo depois de ligares a opção Allow dangerously skip permissions (allowDangerouslySkipPermissions, false de origem), cuja descrição diz: «Usa-o apenas em sandboxes sem acesso à internet.» Sem essa opção, uma predefinição bypassPermissions faz a conversa arrancar em Manual, e um repositório não consegue escolher o modo de arranque.

É na extensão que vale a pena pôr a sandbox à prova. A issue #32814, aberta a 10 de março de 2026, relatava que a extensão lançava o binário sem --sandbox, pelo que sandbox.enabled: true não aplicava nenhum perfil Seatbelt. Foi fechada automaticamente como duplicada quatro dias depois, e nós não voltámos a testar as versões atuais: pede ao agente que escreva fora do workspace e vê o que acontece.

Por que razão o --dangerously-skip-permissions falha como root ou com sudo?

Porque o Claude Code recusa essa combinação em Linux e macOS. O erro é --dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons, e a página de sandboxing dá o motivo: «o acesso root combinado com a ausência de pedidos de permissão permite modificar qualquer ficheiro ou serviço do sistema». A verificação é dispensada «automaticamente dentro de uma sandbox reconhecida».

É em Docker que se costuma tropeçar nisto, porque aí os processos correm como root se ninguém disser o contrário. A correção documentada: «confirma que remoteUser está definido para uma conta que não seja root».

A sandbox ainda te protege com as permissões desativadas?

Em parte. O modo de permissão decide se uma chamada de ferramenta corre; a sandbox integrada limita aquilo a que um comando Bash consegue chegar depois de estar a correr. São mecanismos independentes, e por isso os comandos de shell dentro da sandbox continuam confinados em modo bypass. Só que a sandbox cobre a shell e mais nada. Diz a página comparativa da Anthropic: «As ferramentas de ficheiros integradas, os servidores MCP e os hooks continuam a correr diretamente no teu host.»

Com a sandbox ligada e as permissões desativadas, o sistema operativo trava um comando de shell que acrescente uma linha ao ~/.zshrc. Não trava a ferramenta Edit a escrever no mesmo ficheiro: «Read, Edit e Write usam diretamente o sistema de permissões em vez de passarem pela sandbox», e esse sistema acabaste tu de o desligar.

Há ainda uma saída de emergência. Um comando que falhe dentro da sandbox pode ser repetido com dangerouslyDisableSandbox, e a repetição «passa pelo fluxo normal de permissões», fluxo esse que em modo bypass já não tem pergunta nenhuma. Põe sandbox.allowUnsandboxedCommands a false.

Daí a regra da documentação: as sessões em bypass correm «dentro de um contentor, de uma VM ou do sandbox runtime», onde as ferramentas de ficheiros, os servidores MCP e os hooks também ficam do lado de dentro da fronteira. O Codex traça a linha noutro sítio, com uma única flag a tirar aprovações e sandbox de uma vez: vê o nosso guia das flags do Codex.

O caminho mais curto é a Dev Container Feature da Anthropic, em .devcontainer/devcontainer.json, sem montar nenhum segredo do host:

{
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
  "remoteUser": "vscode",
  "features": {
    "ghcr.io/anthropics/devcontainer-features/claude-code:1.0": {}
  }
}

npm install -g @devcontainers/cli
devcontainer up --workspace-folder .
devcontainer exec --workspace-folder . \
  claude -p "run the test suite and fix what fails" --dangerously-skip-permissions

Inicia sessão uma vez dentro do contentor, ou passa uma ANTHROPIC_API_KEY de âmbito restrito. O que ganhas é um utilizador sem root e uma fronteira de processo, não uma política de saída de rede: o contentor de referência do repositório anthropics/claude-code acrescenta um script de firewall que recusa tudo por predefinição. A página sobre dev containers avisa que uma sessão em bypass continua a poder exfiltrar «tudo o que estiver acessível dentro do contentor, incluindo as credenciais do Claude Code guardadas em ~/.claude». Monta o repositório, nunca a tua pasta pessoal.

Como fazer o Claude Code parar de pedir permissão a toda a hora, sem a flag?

Com o modo auto, ou com regras. O modo auto troca o pedido de permissão por um modelo classificador e já é a predefinição nos planos Pro, Max e Team. Fora deles, as regras permissions.allow aprovam de antemão os comandos que corres o dia inteiro, o acceptEdits acaba com as perguntas nas edições de ficheiros, e o modo auto-allow da sandbox corre sem perguntar os comandos de shell que ficam lá dentro.

O argumento a favor de menos perguntas vem da própria Anthropic. O artigo de engenharia sobre o modo auto, de 25 de março de 2026, abre assim: «Os utilizadores do Claude Code aprovam 93 % dos pedidos de permissão.» Um ponto de controlo que diz que sim 93 vezes em 100 já é sobretudo hábito. O que interessa é o que vem ocupar o lugar dele, e para a flag a página de sandboxing responde: «Nada.»

Um ~/.claude/settings.json que elimina a maior parte das perguntas e fica com as perigosas:

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "disableBypassPermissionsMode": "disable",
    "allow": ["Bash(npm run *)", "Bash(git commit *)"],
    "ask": ["Bash(git push *)", "Bash(terraform *)"],
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Bash(curl *)"
    ]
  }
}

As regras são avaliadas por esta ordem: deny, depois ask, depois allow. Para o «aceitar tudo», o padrão documentado é um "Bash" sem argumentos em allow, mais um hook PreToolUse que rejeita os poucos comandos que não queres ver correr nunca. Já a chave disableBypassPermissionsMode é a que os administradores procuram: colocada nas definições geridas (managed settings) tranca a equipa inteira, e o Claude Code «rejeita então a flag --dangerously-skip-permissions».

Convém conhecer o limite das regras Bash(...). Comparam o texto do comando, e a página de permissões da Anthropic diz que uma regra deny «cobre a invocação que o Claude costuma produzir e não é uma fronteira de segurança em torno do programa»: Bash(rm *) trava rm -rf build/, mas não /bin/rm -rf build/ nem bash -c 'rm -rf build/'.

Que proteções do Claude Code ainda funcionam com as permissões desativadas?

Três: as regras deny, a verificação dos caminhos críticos no rm, e os hooks PreToolUse. O guia dos hooks afirma que estes hooks «disparam antes de qualquer verificação do modo de permissão, em todos os modos de permissão», e que um hook que devolva um deny «bloqueia a ferramenta mesmo em modo bypassPermissions ou com --dangerously-skip-permissions». Dos três, o hook é o único que corre lógica tua.

Um exemplo mínimo, registado em ~/.claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [{ "type": "command", "command": "$HOME/.claude/hooks/guard.sh" }]
      }
    ]
  }
}

#!/bin/bash
# ~/.claude/hooks/guard.sh: exit 2 bloqueia a chamada, o stderr volta para o Claude
CMD=$(jq -r '.tool_input.command')
if echo "$CMD" | grep -Eiq 'terraform[[:space:]]+destroy|drop[[:space:]]+(schema|database|table)|push[[:space:]].*--force'; then
  echo "Blocked: destructive command, ask the human to run it." >&2
  exit 2
fi
exit 0

Guarda-o nas settings de utilizador ou nas definições geridas: em modo bypass, a pasta .claude do projeto pode ser escrita sem qualquer pergunta, e o agente consegue portanto editar um hook que viva no repositório.

Agora os limites, porque este guarda compara texto. A nota de investigação GuardFall da Cloud Security Alliance, publicada a 11 de julho de 2026, contornou os guardas de comandos de dez agentes de código open source em onze, com cinco classes de injeção de shell. O Claude Code não fazia parte do conjunto testado, mas o raciocínio vale para qualquer comparador de texto: «Um guarda que inspeciona a string antes da transformação e uma shell que executa a string depois da transformação estão, na prática, a avaliar dois comandos diferentes.»

O nosso próprio guarda de comandos também erra, e para o outro lado. No nosso estudo controlado de 24 de agosto de 2026 verificou 1 769 comandos de shell e recusou 17: um caso real, o de um agente a deitar a mão a uma credencial guardada, três aplicações corretas da política, e 13 falsos positivos que custaram um turno cada ao agente, a maior parte por causa do token nc detetado dentro de um heredoc de Python. Um guarda de texto é um alarme para o caso comum. A fronteira que aguenta quando ele falha é o contentor.

O Claude Code já apagou mesmo uma base de dados de produção?

Já, e o caso mais bem documentado não teve nada que ver com a flag. A 26 de fevereiro de 2026, o Claude Code correu terraform destroy contra a infraestrutura de produção da DataTalks.Club e levou consigo a base de dados, 2,5 anos de trabalhos entregues nos cursos e todos os snapshots automáticos. O fundador, Alexey Grigorev, publicou o post-mortem a 6 de março; o suporte da AWS recuperou os dados cerca de 24 horas depois.

O agente avisou do que ia fazer: «Não consigo fazê-lo. Vou fazer um terraform destroy.» Grigorev escreve que aquilo «parecia lógico» e que, por isso, «não travei o agente». Em ponto nenhum do texto fala de permissões desativadas: havia uma pessoa no ponto de controlo, e o comando passou porque a justificação soava bem. O resumo dele, retomado também pela Tom's Hardware: «Tratei o plan, o apply e o destroy como coisas que podiam ser delegadas. Isso eliminou a última camada de segurança.»

93 %

dos pedidos de permissão aprovados pelos utilizadores do Claude Code (Anthropic, 25 de março de 2026)

65

issues com rm -rf no título no gestor de issues do Claude Code, 13 ainda abertas (API do GitHub, 20 de setembro de 2026)

17 %

das ações reais de excesso de zelo que escapam ao classificador do modo auto, pelas contas da própria Anthropic

Uma pesquisa por título por rm -rf no gestor de issues do Claude Code devolve 65 resultados a 20 de setembro de 2026, e um deles anuncia logo no título que o Claude Code executou um rm -rf e apagou a pasta pessoal inteira. São relatos de utilizadores, que não verificámos. Do lado da Anthropic, o registo de incidentes internos que vem no artigo sobre o modo auto inclui «tentar migrações contra uma base de dados de produção».

O que teria ajudado, do mais forte para o mais fraco: nenhuma credencial de produção na sessão e proteção contra eliminação na base de dados, que foi a correção do próprio Grigorev; uma regra ask sobre Bash(terraform *); o hook acima; o modo auto, cuja lista de bloqueios de origem inclui terraform destroy.

Se ninguém desativar as permissões, o Claude Code deixa de ser perigoso no trabalho?

Menos perigoso, sim. Resolvido, não. Há código que corre antes de o sistema de permissões ter uma palavra a dizer: a CVE-2025-59536 permitia a um projeto executar código antes de o diálogo de confiança do arranque ser aceite (corrigida na 1.0.111), e a investigação GitSpawn da Manifold, de 1 de setembro de 2026, fez correr o comando core.fsmonitor de um repositório «antes de o pedido de confiança no workspace ser aceite». Além disso, as permissões só decidem se uma ação pode correr; nunca leem o código que o agente escreve.

É por causa deste segundo limite que o artigo existe. Todos os controlos descritos acima decidem o que o Claude Code pode executar, e nenhum olha para o que ele escreve. Uma sessão em modo Manual, com cada pedido lido por um engenheiro atento, pode perfeitamente fazer commit de um endpoint sem verificação de autorização: um diff que compila não é um evento de permissão. Desativar as permissões tira o último ponto de controlo humano sobre as ações. Mantê-las não acrescenta nenhum ponto de controlo sobre o código. A página de segurança da Anthropic deixa essa parte contigo: «És responsável por rever o código e os comandos propostos, quanto à sua segurança, antes de os aprovares.»

É aí que se encaixa um controlo em agent-time. O VibeDefend corre como hooks dentro do mesmo ciclo: põe no contexto do modelo as regras relevantes para um ficheiro no momento da edição, devolve ao agente os resultados de SAST, SCA, segredos, IaC e CI/CD, e vigia os comandos dentro dos limites descritos acima. No estudo de 24 de agosto, o agente com a camada implementou de forma exata 57 de 64 valores concretos de regras avaliados (89 %), contra 8 de 65 (12 %) sem ferramenta nenhuma. O mesmo estudo regista uma tarefa em que a regra foi servida treze vezes e o agente desmontou na mesma as suas próprias salvaguardas: a injeção informa, não impõe.

Os pormenores estão em O Claude Code segue o CLAUDE.md?, em segurança de agentes de código de IA e no nosso guia de segurança do Claude Code.

Usa a flag de propósito, num contentor, com um utilizador sem root, com regras deny, um hook e alguma coisa a ler o diff, e tens uma configuração defensável. Num portátil, passa para o modo auto, e fala connosco sobre a parte que nenhum modo de permissão cobre.

Perguntas frequentes

Qual é o comando do dangerously skip permissions no Claude Code?

claude --dangerously-skip-permissions, ou o equivalente claude --permission-mode bypassPermissions, com -p "<prompt>" para uma execução não interativa. A Anthropic restringe-o a «ambientes isolados, como contentores, VMs ou dev containers sem acesso à internet».

O --dangerously-skip-permissions já vem ativado no Claude Code?

Não. A predefinição de origem é o modo auto nos planos Pro, Max e Team, e Manual em tudo o resto. O bypass exige a flag, um defaultMode ao nível do utilizador, ou uma opção explícita na extensão do VS Code e na aplicação de desktop. Desde a v2.1.257, as settings de um repositório já não o conseguem selecionar.

Consigo ligar o bypass permissions sem reiniciar o Claude Code?

Só se tiveres lançado a sessão com --allow-dangerously-skip-permissions, com a própria flag, ou com um defaultMode de utilizador igual a bypassPermissions. De outra forma, o modo nunca aparece no ciclo do Shift+Tab.

Como configurar o defaultMode no settings.json do Claude Code?

Põe "permissions": { "defaultMode": "acceptEdits" } em ~/.claude/settings.json. Valores aceites: default (alias manual), acceptEdits, plan, auto, dontAsk, bypassPermissions. auto e bypassPermissions são ignorados nas settings de projeto e nas locais, e a extensão do VS Code lê primeiro claudeCode.initialPermissionMode.

Como fazer o Claude Code aceitar todas as permissões sem usar a flag?

Acrescenta um "Bash" sem argumentos a permissions.allow e regista um hook PreToolUse que rejeite os comandos que nunca queres ver correr. As regras deny e ask continuam a ganhar. O modo auto é a alternativa que dá menos trabalho, embora a Anthropic declare que ele «não garante a segurança».

O Claude Code é perigoso no meu computador pessoal?

Em modo Manual ou auto, com regras deny sobre os ficheiros .env, o ~/.ssh e as pastas de credenciais cloud, não, para o trabalho de todos os dias. Com as permissões desativadas diretamente no host, sim: o agente age como o teu utilizador, com as chaves SSH e as credenciais cloud ao alcance da mão. Usa um contentor.

O Claude Code está pronto para uso empresarial?

Os controlos existem: um managed-settings.json (em /etc/claude-code/ no Linux) com disableBypassPermissionsMode, allowManagedPermissionRulesOnly e allowManagedHooksOnly, mais as chaves de sandbox impostas de forma central. Governam o que o agente pode executar. Nenhum deles revê o código que ele produz: esse trabalho continua a ser teu.