Índice
- 1. O que é "bypass" afinal?
- 2. O verdadeiro motivo: o sistema de permissões de 2 camadas
- 3. Camada 1: IU de permissões de ferramentas (controlável com bypass)
- 4. Camada 2: julgamento de segurança da IA (não controlável com bypass)
- 5. Padrões de operações em que o Claude pergunta por conta própria
- 6. Por que duas camadas? A filosofia de design
- 7. Formas práticas de reduzir as confirmações
- 8. Resumo
- FAQ
Você configurou a flag --dangerously-skip-permissions no Claude Code, mas o Claude ainda manda uma mensagem no chat perguntando "Posso executar esta operação?" Parece familiar?
O instinto é pensar "o bypass não está funcionando" — mas não é isso que está acontecendo. O sistema de permissões do Claude Code tem duas camadas independentes, e o modo bypass só controla uma delas.
Este artigo cobre tudo: desde "o que é o bypass de verdade" até a diferença entre as duas camadas de permissão, os tipos de operações em que o Claude pergunta por conta própria e formas práticas de reduzir as confirmações ao automatizar tarefas.
1. O que é "bypass" afinal?
Em software, "bypass" significa pular o fluxo normal de confirmação ou aprovação para prosseguir diretamente. Pense no botão "comprar agora" de uma loja online que pula a tela de revisão — isso é um bypass do fluxo de confirmação.
No modo Manual do Claude Code (valor de configuração default), um diálogo de confirmação aparece antes de qualquer edição de arquivo ou execução de comando shell. A partir do Claude Code v2.1.283, porém, as sessões no terminal e no VS Code começam por padrão no modo Auto em todos os planos e provedores, em que um classificador revisa a maioria das ações em vez de perguntar a você (nas versões anteriores, só nos planos Pro, Max e Team; se um administrador tiver desativado o modo automático ou o modelo não for compatível, começam no Manual).
# Modo Manual: confirmação antes de cada ação
$ claude --permission-mode default
> Please fix index.js
[Claude Code] May I edit index.js? → Yes / NoO modo de bypass de permissões pula (bypassa) esse fluxo de confirmação.
# Modo bypass: quase nenhum diálogo de confirmação
$ claude --dangerously-skip-permissions
# or
$ claude --permission-mode bypassPermissionsNote que a flag inclui a palavra dangerously. A Anthropic posiciona este modo como destinado apenas a containers ou ambientes isolados — não é recomendado para o desenvolvimento local do dia a dia. Para uma análise completa dos riscos do modo bypass, veja Modo bypass do Claude Code: riscos e uso seguro.
Se os diálogos de confirmação continuarem aparecendo com frequência, verifique primeiro se você está mesmo no modo bypass. Enquanto ele está ativo, a barra de status do terminal mostra ⏵⏵ bypass permissions on. Se não mostrar, há duas causas comuns.
- Você configurou nas configurações do projeto: definir
bypassPermissionscomodefaultModeem.claude/settings.jsonou.claude/settings.local.jsonnão tem efeito, e a sessão começa no modo Manual (v2.1.257 e posteriores). Coloque-o nas suas configurações de usuário (~/.claude/settings.json) ou nas configurações gerenciadas, ou passe a flag ao iniciar - Você tentou mudar no meio da sessão: o bypass só pode ser escolhido em uma sessão que o tinha habilitado ao iniciar. Em uma sessão iniciada sem ele, pressionar Shift+Tab nunca chega ao bypass
Além disso, na primeira vez que você inicia uma sessão interativa em bypass, o Claude Code mostra um aviso, uma única vez, pedindo que você aceite a responsabilidade pelas ações executadas sem verificação de permissões (a sua aceitação fica salva nas configurações de usuário).
2. O verdadeiro motivo: o sistema de permissões de 2 camadas
A resposta para "por que a confirmação aparece mesmo com o bypass ativado" é que o sistema de permissões do Claude Code é construído sobre duas camadas independentes.
Sistema de Permissões do Claude Code: Arquitetura de 2 Camadas
O modo bypass só desativa a Camada 1 (e até nela restam algumas confirmações)
--dangerously-skip-permissions desativa quase toda a Camada 1 (restam as regras ask, a exclusão de caminhos críticos e pouco mais). A Camada 2 não pode ser ignorada.
Confundir essas duas camadas é a causa raiz do equívoco de que "o bypass não está funcionando". Vamos ver cada uma em detalhes.
3. Camada 1: IU de permissões de ferramentas (controlável com bypass)
A primeira camada é o diálogo de confirmação exibido antes da execução de uma ferramenta — a IU interativa que aparece quando o Claude Code está prestes a editar um arquivo ou executar um comando shell.
| Ferramenta | Exemplo de diálogo de confirmação |
|---|---|
| Edição de arquivo | "Posso modificar index.js?" |
| Execução de Bash | "Posso executar npm install?" |
| Acesso à web | "Posso acessar https://...?" |
É exatamente essa a camada que o modo bypass desativa. Com --dangerously-skip-permissions, diálogos como esses quase nunca aparecem e o Claude pode executar ferramentas livremente. Até a escrita em caminhos protegidos como .git e .claude passa sem confirmação no modo bypass. Nesse sentido, o modo bypass está funcionando corretamente.
Confirmações que aparecem mesmo no modo bypass (exceções da Camada 1)
A palavra-chave é "quase". A documentação oficial afirma que o Claude Code não aprova automaticamente o seguinte em nenhum modo, incluindo o bypass (fonte: página oficial do Claude Code "Choose a permission mode", em 22 de setembro de 2026).
- Ações que correspondem a uma regra ask: o que você colocou em
permissions.asknas configurações (por exemplo,Bash(git push *)) pede confirmação toda vez, mesmo no modo bypass - Ferramentas que precisam da sua participação:
AskUserQuestion, em que o Claude faz a você uma pergunta com opções; ferramentas MCP marcadas como exigindo interação do usuário; e ferramentas de conectores que a sua organização configurou como ask rmermdirapontados para caminhos críticos: exclusões que miram a raiz do sistema de arquivos e seus diretórios de primeiro nível (como/usr), o seu diretório pessoal ou o seu diretório de trabalho e os diretórios acima dele. A documentação chama isso de disjuntor (circuit breaker) contra erros do modelo, e nenhuma regra allow nem hook consegue aprová-lo. No entanto, no aplicativo Desktop e no VS Code, a partir da v2.1.309, esses comandos são recusados imediatamente, sem pedir confirmação, e a recusa traz dicas para reescrever o comando, para não travar sessões em que ninguém está presente (histórico de alterações oficial).- Outros: as salvaguardas de mensagens entre sessões e os comandos Bash que leem fora dos seus diretórios de trabalho enquanto
permissions.blockReadsOutsideWorkingDirectoriesestá ativado
As regras também contam. As regras deny continuam valendo no modo bypass e bloqueiam as ações correspondentes. Já as regras allow não têm efeito no modo bypass (tudo já passa). Em execuções não interativas com -p, essas poucas confirmações são negadas em vez de esperar uma resposta.
Observação: existem 6 modos de permissão
O Claude Code tem seis modos de permissão: Manual (default), Aceitar edições (acceptEdits), Plano (plan), Auto (auto) e Ignorar permissões (bypassPermissions), além do dontAsk, que nunca aparece no ciclo do Shift+Tab e nega automaticamente tudo o que pediria confirmação (pensado para CI). O bypass (bypassPermissions) é o menos restritivo. Para mais detalhes sobre cada modo, veja o artigo sobre os modos de permissão.
4. Camada 2: julgamento de segurança da IA (não controlável com bypass)
A segunda camada é o julgamento de segurança autônomo do Claude. Ela é completamente separada da IU de confirmação de ferramentas.
Quando o Claude determina que uma operação pode ter consequências significativas, ele envia uma mensagem de confirmação no chat como texto simples. Isso não é um mecanismo de execução de ferramentas — é o comportamento conversacional do Claude como IA.
--dangerously-skip-permissions pula os diálogos de IU da Camada 1, mas não tem nenhum efeito sobre esse julgamento de IA da Camada 2 — porque a Camada 2 é um princípio comportamental integrado ao próprio modelo do Claude.
Equívoco comum
"Ativei o modo bypass, mas o Claude parou → o bypass não está funcionando"
→ Mais precisamente, diferencie pela forma como o Claude parou. Se o Claude perguntou com texto no chat: "A IU da Camada 1 está desativada, mas o julgamento de IA da Camada 2 está solicitando confirmação." Se apareceu no terminal um diálogo pedindo permissão, é uma das confirmações da Camada 1 que o bypass mantém, como uma regra ask ou a exclusão de um caminho crítico. Nos dois casos, o bypass está funcionando normalmente (se não for nenhum dos dois e as confirmações continuarem, talvez você nem tenha iniciado no modo bypass).
A Camada 2, porém, não é uma garantia de segurança. Se o Claude pergunta ou não é uma decisão do momento, e ele não vai necessariamente parar antes de uma ação perigosa. A documentação oficial também alerta que o modo bypass não oferece nenhuma proteção contra injeção de prompt nem contra ações indesejadas. O que nunca pode ser executado deve ser bloqueado com uma regra deny.
5. Padrões de operações em que o Claude pergunta por conta própria
Por Tipo de Operação: Qual Camada Faz a Confirmação?
Camada 1 (IU de permissão de ferramentas) vs Camada 2 (Julgamento de IA)
Os critérios internos do Claude para "devo confirmar isso" se enquadram em três categorias principais.
① Irreversibilidade
Operações que não podem ser desfeitas deixam o Claude mais cauteloso. Exclusão permanente de arquivos, git push --force e DROP TABLE são exemplos clássicos. Como os erros são difíceis de recuperar, o Claude faz uma pausa e pergunta.
② Raio de impacto
Ações que afetam ambientes de produção, grandes quantidades de arquivos ou outros usuários geram verificações mais frequentes. Modificar um único arquivo local raramente provoca uma pergunta; alterar o schema de um banco de dados de produção quase sempre provoca.
③ Risco de segurança
Operações que enviam arquivos .env, tokens de autenticação ou chaves de API para sistemas externos são sinalizadas como alto risco de segurança pelo Claude, que perguntará antes de prosseguir.
Algumas exclusões, porém, não ficam a cargo do julgamento do Claude: rm e rmdir apontados para caminhos críticos, como a raiz, o seu diretório pessoal ou o próprio diretório de trabalho, são interrompidas pelo próprio Claude Code (Camada 1), mesmo no modo bypass (a CLI mostra uma confirmação, enquanto o aplicativo Desktop e o VS Code recusam diretamente a partir da v2.1.309). É uma das poucas confirmações que o bypass não remove.
Esses julgamentos estão integrados ao modelo de IA do Claude e não podem ser completamente desativados via configuração. Para saber mais sobre como os agentes de IA são projetados para operar com segurança, veja O que é um agente de IA?.
6. Por que duas camadas? A filosofia de design
Por que 2 Camadas? — Filosofia de Design
Entenda com a analogia do pedreiro
Aqui está uma analogia que torna o design de duas camadas intuitivo.
Imagine que você contrata um pedreiro para reformar um cômodo e lhe dá uma chave reserva, dizendo "você pode fazer o que precisar." Isso equivale a conceder permissões de ferramenta.
Mas quando o pedreiro está prestes a derrubar uma parede e pergunta "Esta parede é estrutural? Tem certeza de que quer que eu a remova?" — ele está perguntando com base no seu próprio julgamento profissional, não porque perdeu a chave.
Dar a chave a ele não impede o pedreiro de pensar. O seu julgamento profissional e a consciência de segurança operam de forma independente da chave.
O Claude funciona da mesma forma. O modo bypass dá ao Claude "a chave para usar ferramentas", mas não interrompe o julgamento de IA do Claude. Na verdade, o Claude fazer uma pausa antes de operações de alto risco é um recurso de segurança intencional, não uma falha.
7. Formas práticas de reduzir as confirmações
Em pipelines de CI/CD e outros cenários de automação, pode ser necessário que o Claude conclua as tarefas sem parar. Aqui estão as abordagens mais eficazes.
Abordagem 1: usar o CLAUDE.md para fornecer contexto
Crie um arquivo CLAUDE.md na raiz do seu projeto explicando o ambiente e as restrições. Quando o Claude entende que "este é um ambiente seguro e isolado", a frequência de confirmações cai significativamente.
# About This Environment
This repository runs inside a CI/CD pipeline test environment.
- Runtime: fully isolated Docker container
- Production impact: none
- All changes are rollback-safe
Please proceed without asking for extra confirmation.Abordagem 2: dar instruções pequenas e específicas
Instruções vagas aumentam a incerteza do Claude e geram mais confirmações.
| Tipo de instrução | Exemplo | Frequência de confirmação |
|---|---|---|
| Vaga | "Limpe este projeto" | Alta |
| Específica | "Remova os imports não usados em src/" | Baixa |
| Vaga | "Faça o deploy" | Alta |
| Específica | "Execute npm run deploy:staging no ambiente de staging" | Baixa |
Abordagem 3: experimentar o modo auto primeiro
Antes de recorrer ao modo bypass completo, experimente o modo auto. Ele executa um classificador de segurança em segundo plano enquanto aprova automaticamente a maioria das operações, e também incentiva o Claude a continuar trabalhando em vez de parar para fazer perguntas de esclarecimento (o Claude ainda pergunta quando o seu prompt ou uma skill depende disso). Se o único motivo pelo qual você usa o bypass é "estou cansado das confirmações", o modo auto pode ser suficiente. As ações que correspondem a uma regra ask continuam pedindo confirmação no modo auto.
Aviso importante
Nenhuma configuração pode reduzir o julgamento de segurança do Claude a zero absoluto. Isso é intencional — não é um bug nem uma limitação. Para operações de alto risco, o Claude pedir confirmação é o comportamento correto. Aceite isso como parte do design. A Camada 1 também mantém algumas confirmações que o bypass não remove, como as regras ask e a exclusão de caminhos críticos.
8. Resumo
| Item | Detalhe |
|---|---|
| O que é o bypass | Pular quase todos os diálogos de confirmação pré-ferramenta (Camada 1) |
| O que o bypass desativa | A IU de permissões de ferramentas ("Posso executar este comando?"), incluindo as confirmações para escrever em caminhos protegidos como .git e .claude |
| O que o bypass NÃO desativa | O julgamento de segurança de IA do Claude (confirmação enviada como texto no chat) e as exceções da Camada 1 (regras ask, rm/rmdir em caminhos críticos, AskUserQuestion) |
| Regras no modo bypass | deny continua bloqueando; allow não tem efeito |
| Critérios de confirmação do Claude | Irreversibilidade, raio de impacto, risco de segurança |
| Como reduzir confirmações | Contexto no CLAUDE.md / instruções específicas / modo auto |
| Por que duas camadas | Permissão de ferramenta e julgamento de IA são conceitos fundamentalmente distintos |
Quando o Claude pede confirmação mesmo no modo bypass, não significa que o bypass parou de funcionar — dois sistemas independentes simplesmente estão fazendo seu trabalho. Entender essa distinção ajuda a prever o comportamento do Claude Code com precisão e a utilizá-lo de forma mais eficiente.
Para entender as diferenças entre os produtos Claude, veja Claude.ai vs Claude Code: qual é a diferença?.
FAQ
Posso obter zero confirmações com o modo bypass?
Você pode desativar quase todos os diálogos de IU de execução de ferramentas (Camada 1), mas continuam aparecendo as confirmações de ações que correspondem a uma regra ask, de rm ou rmdir em caminhos críticos e de perguntas via AskUserQuestion. Também não é possível eliminar completamente as confirmações do julgamento de segurança de IA da Camada 2. Isso é um recurso de segurança intencional. No entanto, documentar bem seu ambiente no CLAUDE.md e dar instruções específicas pode reduzir significativamente a frequência com que o Claude pergunta.
O Claude pedir confirmação é um bug?
Não. O modo bypass pula a IU de permissões de ferramentas, não o julgamento de IA do Claude. O Claude fazer uma pausa antes de operações irreversíveis, ambientes de produção ou dados sensíveis é um comportamento de segurança intencional — não uma falha. Não é "o bypass não funcionando", é "dois sistemas operando de forma independente". Se, em vez de texto no chat, aparecer um diálogo pedindo permissão, é uma das confirmações da Camada 1 que o bypass mantém, como uma regra ask ou a exclusão de um caminho crítico.
Como evito que o Claude pare em pipelines de CI/CD?
Três coisas funcionam bem: ① declare explicitamente no CLAUDE.md ou no prompt do sistema que "este é um ambiente de CI/CD completamente isolado e todas as operações são executadas com segurança", ② dê instruções de tarefa pequenas e específicas (instruções vagas geram mais confirmações), ③ combine o modo bypass com isolamento de container Docker. No ③, execute o Claude Code com um usuário que não seja root: no Linux e no macOS, o modo bypass se recusa a iniciar como root ou com sudo. Com -p, as poucas confirmações que o bypass mantém são negadas em vez de esperar uma resposta. Se você só quer que rodem ações aprovadas de antemão, a documentação oficial também indica --permission-mode dontAsk com --allowedTools para CI. Observe que, mesmo com tudo isso, o Claude pode fazer alguma pausa.
Consigo distinguir visualmente um diálogo de ferramenta da confirmação do Claude?
Sim. Os diálogos de permissão de ferramentas da Camada 1 aparecem no terminal do Claude Code como uma IU interativa que mostra o comando ou a edição junto com opções como Yes e No. As confirmações do julgamento de IA da Camada 2 aparecem como texto de conversa normal do Claude (por exemplo, "Isso vai modificar o banco de dados de produção — pode ser?"). O caso que confunde é o AskUserQuestion, em que o Claude faz uma pergunta com opções: a pergunta vem do Claude, mas aparece como um diálogo e espera a sua resposta mesmo no modo bypass, porque a Camada 1 nunca a aprova automaticamente. Os formatos de exibição são diferentes, então é fácil distingui-los depois que você se familiariza.
