Boas práticas
Permissões totais sem destruir a sua máquina
Os pedidos de aprovação são o que torna um agente inútil quando você está longe, e desligá-los no seu notebook é como as pessoas perdem uma tarde inteira. A solução não é coragem. É colocar o agente num lugar que você não se importaria de reconstruir.
Resposta rápida
--dangerously-skip-permissions executa todas as chamadas de ferramentas sem perguntar. A Anthropic diz para usá-lo só em contêineres ou VMs isolados, e o Claude Code se recusa a usá-lo como root. Rode-o com um usuário não root num servidor ou contêiner descartável, sem segredos de produção. Ou use o modo auto, em que um classificador aprova as ações seguras. O app mobile da Anthropic não consegue colocar uma sessão em bypass.
O Claude Code pergunta antes de fazer qualquer coisa importante. Na mesa, tudo bem: você dá uma olhada, aprova e segue. Longe da mesa, isso trava o trabalho. O agente para no passo três de uma tarefa de vinte minutos e espera um toque que só chega quarenta minutos depois, quando a ideia de delegar era justamente você não precisar ficar olhando.
Então as pessoas recorrem ao --dangerously-skip-permissions. Essa flag é perigosa na máquina errada e razoável na máquina certa, e a diferença não está no seu cuidado. Está no que o agente consegue alcançar quando faz algo que você não pretendia. Esta página mostra o que a flag realmente faz, por que ela não roda como root, a configuração que a torna defensável e os equivalentes no Codex, OpenCode, Grok Build e Antigravity.
O que o bypass realmente permite
O Claude Code tem seis modos de permissão. A página de modos de permissão da Anthropic os descreve assim. A tabela segue a ordem da documentação: default é o nome de configuração do modo Manual, não o modo em que uma sessão começa.
| Modo | Executa sem perguntar | "Ideal para", segundo a Anthropic |
|---|---|---|
default (Manual) | Só leituras | Trabalho sensível |
acceptEdits | Leituras, edições de arquivos, comandos comuns de sistema de arquivos | Iterar sobre código que você está revisando |
plan | Leituras, mais comandos aprovados pelo classificador quando o modo auto está disponível | Explorar antes de mudar |
auto | Tudo, com verificações de segurança em segundo plano | Tarefas longas, menos pedidos |
dontAsk | Leituras e ferramentas pré-aprovadas; todo o resto é negado | CI bem fechado |
bypassPermissions | Tudo | Só contêineres e VMs isolados |
O bypass executa cada chamada de ferramenta na hora, inclusive escritas em caminhos protegidos como .git e a própria configuração do Claude. Algumas coisas continuam valendo:
- Regras de negação nas suas configurações bloqueiam em todos os modos, inclusive no bypass. Regras de permissão não têm efeito nele.
- Regras explícitas de perguntar continuam pedindo confirmação.
rmermdirapontados para caminhos críticos continuam pedindo confirmação: a raiz do sistema de arquivos, diretórios de primeiro nível, o seu diretório home, e o diretório de trabalho e os diretórios acima dele.
O que o bypass não oferece é qualquer defesa contra prompt injection ou contra um comando errado executado com confiança. A documentação da Anthropic é direta: use-o só em ambientes isolados, onde o Claude Code não possa danificar o seu host.
Desde o Claude Code v2.1.283, o modo auto é o modo inicial padrão das sessões interativas no terminal e no VS Code. Um segundo modelo revisa cada ação e bloqueia as arriscadas, como exclusão em massa num armazenamento na nuvem, force pushes ou iniciar outro loop de agente com aprovações e sandbox desativados. Ele elimina a maioria dos pedidos sem eliminar todas as verificações. Ele precisa de um modelo compatível, e uma organização pode desativá-lo. Se o modo auto basta para a sua tarefa, talvez você nem precise do bypass.
Duas flags parecidas
--dangerously-skip-permissionsinicia a sessão já em bypass. É equivalente a--permission-mode bypassPermissions.--allow-dangerously-skip-permissionssó adiciona o bypass ao ciclo do Shift+Tab. A sessão começa num modo normal, e você muda para o bypass quando quiser.
A segunda importa porque você não consegue entrar em bypass numa sessão que não foi iniciada com ele habilitado. Se você talvez queira usá-lo depois, precisa decidir ao iniciar. A forma --allow- é o jeito cuidadoso de fazer isso: a sessão se comporta normalmente até você mudar de modo deliberadamente.
A primeira execução interativa com o bypass habilitado mostra um diálogo de aviso. Aceitá-lo grava skipDangerousModePermissionPrompt: true em ~/.claude/settings.json; recusar faz o Claude Code encerrar. Execuções não interativas com -p pulam o diálogo. Administradores podem bloquear o modo para todos com permissions.disableBypassPermissionsMode: "disable" nas configurações gerenciadas.
Por que ele falha como root
No Linux e no macOS, o Claude Code se recusa a iniciar no modo bypass como root ou com sudo:
--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasonsA verificação é ignorada dentro de um sandbox que o Claude Code reconhece, e o dev container da Anthropic o executa com um usuário não root por esse motivo. Numa VPS comum em que você entra como root, crie primeiro um usuário normal. Nosso guia de configuração de VPS traz os três comandos.
Aprendemos três coisas práticas rodando o Claude Code sob o daemon do Maude em muitos servidores diferentes:
- Como root, a forma
--allow-também falhou. Nos nossos testes com o Claude Code 2.1.x, o processo encerrava logo ao iniciar, em vez de só deixar o bypass fora do ciclo. Qualquer wrapper que adicione a flag precisa verificar o ID do usuário antes, senão todas as sessões num servidor root morrem. - Versões antigas rejeitam a flag de cara. Uma CLI que não conhece a flag encerra do mesmo jeito. Confira se ela aparece em
claude --helpantes de passá-la. - Teste numa máquina nova. O seu próprio
~/.claude/settings.jsonprovavelmente já temskipDangerousModePermissionPromptdesde o dia em que você clicou no aviso. Num servidor novo, esse diálogo aparece antes do prompt, e uma sessão sem supervisão fica parada esperando nele. Teste num contêiner limpo, não no seu notebook.
O padrão do servidor descartável
Antes de afrouxar permissões em qualquer lugar, faça uma pergunta: se este processo executasse agora um comando destrutivo qualquer, o que eu perderia?
Num notebook típico, a resposta honesta é desconfortável: suas chaves SSH, credenciais de nuvem em ~/.aws e ~/.config, perfis de navegador com sessões ativas, um .env com URLs de produção e todos os outros repositórios que você tem clonados. Numa VPS descartável com um único projeto, a resposta é esse projeto, que já está no remoto de qualquer forma, mais uma hora para reconstruir. Esse é um risco que dá para aceitar. Veja três lugares para colocar o agente:
Um contêiner na sua própria máquina
É a opção mais barata e mais próxima. Rode um contêiner Linux com Docker ou OrbStack, instale o Claude Code dentro dele com um usuário não root e monte só o projeto que você quer que ele mexa. Não monte o seu diretório home, não passe credenciais do host e não use --privileged nem monte o socket do Docker, porque os dois devolvem o host para o agente.
Uma VPS dedicada
É a opção em que a maioria das pessoas acaba ficando: uma máquina pequena rodando um ou dois projetos e nada mais. Ela fica sempre ligada, então o trabalho continua enquanto as suas máquinas estão desligadas. Se algum dia ela for comprometida, você a destrói e cria outra. Mantenha a reconstrução sem graça, com um script de configuração curto em vez de uma máquina que você ajustou à mão durante um ano. O guia de compra de VPS trata do dimensionamento.
Um sandbox efêmero na nuvem
As sessões na nuvem da Anthropic rodam cada tarefa numa VM isolada, com as credenciais do git mantidas fora do sandbox e acesso à rede limitado por padrão. É um isolamento forte sem nada para manter. Mas o bypass não está disponível lá. As sessões na nuvem oferecem Accept edits, Plan e Auto, e ignoram bypassPermissions definido nas configurações de um repositório.
Segredos para manter fora da máquina
- Credenciais de produção. Aponte para staging ou para uma cópia local. A falha contra a qual você está se protegendo não é má-fé; é um erro cometido com confiança contra uma connection string que por acaso estava dando sopa.
- Sua chave SSH pessoal. Dê ao servidor a própria deploy key ou um token granular, restrito aos repositórios de que ele precisa. Também não use encaminhamento do agente SSH para dentro dele: isso empresta as suas chaves à máquina enquanto você estiver conectado.
- Tokens de nuvem amplos. Nada de chaves de admin da AWS nem tokens do GitHub com acesso à organização inteira. Se uma tarefa precisar de um, restrinja o escopo e deixe que expire.
- Qualquer coisa que só exista lá. Faça push com frequência, para que perder o servidor não custe nada que você não possa recriar.
Uma credencial precisa ficar na máquina: o login do próprio agente. O Claude Code o guarda em ~/.claude/.credentials.json, então qualquer pessoa com um shell como esse usuário pode usar o seu plano. É mais um motivo para dar ao agente um usuário só dele.
Equivalentes no Codex e em outros agentes
Todo agente de código tem a sua versão desse interruptor, e nem todas significam a mesma coisa:
| Agente | Pular todos os pedidos | Meio-termo mais seguro |
|---|---|---|
| Claude Code | --dangerously-skip-permissions (recusado como root) | Modo auto; acceptEdits; regras de negação |
| Codex | --dangerously-bypass-approvals-and-sandbox, alias --yolo: "Use apenas dentro de um ambiente protegido externamente" | --sandbox workspace-write com aprovações sob demanda (rede desativada por padrão). --full-auto agora é um alias obsoleto disso |
| OpenCode | opencode --auto (as regras de negação continuam valendo) | allow / ask / deny por ferramenta no opencode.json. Note que a maioria das ferramentas tem allow como padrão |
| Grok Build | grok --always-approve (regras de negação e hooks PreToolUse continuam valendo) | Modo auto (um classificador aprova as ferramentas seguras); um sandbox separado limita as chamadas aprovadas |
| Antigravity CLI | agy --dangerously-skip-permissions | Listas de permitir, perguntar e negar (negar prevalece); o preset padrão coloca os comandos de terminal num sandbox sem rede no macOS e no Linux |
Fontes: referência da Codex CLI e aprovações e segurança, permissões do OpenCode, permissões do Grok Build, permissões do Antigravity e o codelab da Antigravity CLI do Google, consultados em outubro de 2026. O Codex e o Antigravity usam sandbox por padrão, então desligar os pedidos e desligar o sandbox são decisões separadas. Desligar o sandbox é a que exige a máquina descartável.
Posso ativar o bypass pelo celular?
Não pelo app do Claude. A documentação mobile da Anthropic diz que não dá para selecionar Bypass permissions pelo app, nem em sessões na nuvem nem no Remote Control, e o Remote Control pelo app também não oferece Auto. Para um cliente de uso geral, é um padrão sensato.
O Maude foi feito para o outro caso, um servidor que é seu e que você poderia reconstruir, então ele oferece o modo de acesso total de cada agente como "yolo", ao lado dos outros modos do agente. No caso do Claude, ele só tem efeito quando o daemon roda com um usuário não root e o Claude Code instalado suporta a flag. Caso contrário, a sessão continua num modo normal. O Maude inicia a sessão num modo normal e muda para o bypass depois de iniciar, nunca ao criar o processo. Num servidor que só tem root, um botão no app cria um usuário não root para você. Você pode definir um modo padrão para cada agente ou mudá-lo por sessão.
Permissões totais são uma decisão sobre onde o agente roda, não uma configuração de risco. Coloque o Claude Code num usuário não root, numa máquina sem nada que valha a pena roubar e sem nada que você não possa reconstruir, e você pode deixá-lo rodar sem supervisão sem se preocupar. Deixe-o na máquina que guarda as suas chaves e o trabalho dos seus clientes, e nenhum cuidado torna isso uma boa troca.
Comande pelo celular
Se você já montou o servidor descartável, Claude Code no celular mostra como o Maude o roda lá. Como aprovar permissões de agentes pelo celular trata da abordagem oposta: manter os pedidos ativos e respondê-los a partir de uma notificação.
Perguntas frequentes
O --dangerously-skip-permissions é seguro?
Por que ele falha como root?
--allow-dangerously-skip-permissions como root também fez o processo encerrar logo ao iniciar.Qual é o equivalente no Codex?
codex --dangerously-bypass-approvals-and-sandbox, também escrito --yolo, que desativa tanto as aprovações quanto o sandbox. A OpenAI diz para usá-lo só dentro de um ambiente protegido externamente. O padrão de baixo atrito é --sandbox workspace-write com aprovações sob demanda. O antigo --full-auto está obsoleto e mostra um aviso.Posso ativar o bypass pelo celular?
Qual a diferença entre as duas flags de skip-permissions?
--dangerously-skip-permissions inicia a sessão no modo bypass. --allow-dangerously-skip-permissions a inicia num modo normal e só adiciona o bypass ao ciclo do Shift+Tab, para você poder mudar para ele depois. Numa sessão iniciada sem nenhuma das duas, não dá para entrar em bypass de jeito nenhum.O que mudou
- — Reescrito: restrição a root, --allow-dangerously-skip-permissions vs --dangerously-skip-permissions, o modo auto como meio-termo padrão, o que o bypass ainda bloqueia, equivalentes no Codex/OpenCode/Grok Build/Antigravity e o que o app mobile da Anthropic e o Maude permitem.
- — Primeira publicação.
