Executando Agentes de Código em Modo YOLO Sem Destruir Seu Laptop

Executar um agente de código em modo YOLO só é seguro quando você contém o raio de impacto — você torna o ambiente do agente descartável, não o agente confiável. O modo de bypass de permissões (--dangerously-skip-permissions do Claude Code, full-auto do Codex, YOLO do Gemini CLI) troca centenas de cliques de aprovação por um agente que pode ler suas chaves SSH, deletar arquivos, corromper o histórico do git e executar código que ele mesmo gerou segundos atrás — tudo sem pedir permissão. Você não resolve isso confiando no modelo ou escrevendo uma allowlist mais restrita. Você resolve colocando o agente em um lugar onde ele não possa prejudicar nada que importe, em camadas, proporcionais ao risco real que você está assumindo.

Este artigo apresenta o modelo de risco, uma regra de decisão independente de ferramenta para determinar qual camada de isolamento você realmente precisa, o confinamento oficial que o Claude Code já disponibiliza, e uma configuração mínima segura que você pode copiar, com seus trade-offs honestos. Esse espaço evolui mensalmente, então flags e nomes de ferramentas vão mudar — os primitivos duráveis (containers, microVMs, proxies de egresso, workspaces descartáveis) não vão.

O que o modo YOLO do Claude Code realmente faz em 2026

O modo de bypass de permissões desativa os prompts de aprovação e a maioria das verificações de segurança que normalmente controlam os comandos shell e as escritas de arquivos de um agente. Conforme a documentação de modos de permissão do Claude Code, --dangerously-skip-permissions é equivalente a --permission-mode bypassPermissions. Introduzido no Claude Code v2.1.126, esse modo também ignora escritas em caminhos protegidos que versões anteriores ainda solicitavam aprovação — embora rm -rf / e rm -rf ~ continuem exigindo confirmação como circuit breakers contra erros do modelo, e a flag agora se recusa a iniciar como root ou sob sudo no Linux e macOS. A recusa ao root/sudo é corroborada na documentação da ferramenta Bash em sandbox e silenciosamente quebra toda receita ingênua de Docker que executa o agente como root.

O motivo pelo qual você não pode simplesmente escrever uma allowlist mais segura é estrutural. O allowlisting com menor privilégio falha para agentes de código porque o espaço de ações válidas é ilimitado: uma única tarefa legítima pode instalar pacotes, escrever em caminhos arbitrários e executar código recém-gerado. A Edera coloca isso diretamente — você não pode aplicar menor privilégio a um agente porque o espaço de comportamento válido não pode ser enumerado. Todo comando que parece destrutivo é também algo que um agente faz em trabalho normal.

Os modos de falha não são hipotéticos. O próprio log de incidentes da Anthropic por trás do modo auto descreve agentes deletando branches remotas do git, fazendo upload do token de autenticação GitHub de um engenheiro e tentando executar migrações em um banco de dados de produção. Essa é a ameaça: não malícia, mas um processo não-determinístico com acesso total ao shell fazendo algo plausível e errado.

Contenha o raio de impacto: o modelo de defesa em camadas

O princípio de funcionamento, emprestado da Edera, é tratar isso como um problema de resiliência e não de política: aceite que algo eventualmente vai dar errado e garanta que, quando isso acontecer, a falha fique contida. Você não coloca o agente em sandbox porque espera que ele se comporte mal nesta execução; você o coloca em sandbox para que a execução que der errado custe um container deletado em vez de um conjunto de credenciais vazadas.

O confinamento tem dois eixos que precisam ser mantidos simultaneamente. Um isolamento eficaz exige limites tanto de sistema de arquivos quanto de rede. A documentação de sandboxing do Claude Code torna a dependência explícita: sem isolamento de rede, um agente pode exfiltrar chaves SSH, e sem isolamento de sistema de arquivos, ele pode escapar para acessar a rede. Uma camada que cobre um eixo e não o outro tem uma brecha.

Nenhuma camada única cobre todos os modos de falha, razão pela qual o modelo mental mais útil é entender o que cada camada protege — e o que ela não protege:

Duas linhas merecem destaque. Um container padrão reduz o dano de “toda a minha máquina” para “esta pasta de projeto”, mas compartilha o kernel do host, portanto nunca foi projetado para ser um limite de segurança contra código não confiável — é uma conveniência de isolamento, não uma prisão. E no nível mais forte, o isolamento em nível de kernel ainda não impedirá roubo de credenciais ou exfiltração de dados; a própria Edera afirma isso, observando que o isolamento de hardware não cobre uso indevido de credenciais ou exfiltração de rede — defina o escopo com credenciais por agente e políticas de rede. Mantenha segredos fora do sandbox e coloque uma allowlist de egresso na frente dele, independentemente de qual camada você escolher.

Qual camada você realmente precisa?

Combine a camada com o risco: sandbox integrado ou modo auto para edições cotidianas, um devcontainer sem root para execuções não supervisionadas de rotina, uma microVM com kernel próprio para execução totalmente autônoma ou de código não confiável, e isolamento de kernel por pod apenas para CI compartilhado ou infraestrutura multi-tenant. Não existe uma única ferramenta que seja a resposta. A resposta certa é uma regra de decisão, porque um desenvolvedor supervisionando uma refatoração e um job de CI executando PRs não confiáveis não estão expostos ao mesmo risco.

Esta regra é uma síntese editorial, não uma afirmação de fornecedor — mas a capacidade de cada camada nela é referenciada abaixo. O ponto é parar de isolar em excesso ou de forma insuficiente: não suba uma microVM para corrigir um erro de digitação, e não execute PRs não confiáveis em um container root porque era mais fácil.

O Claude Code já inclui várias dessas camadas

O confinamento mais rápido é aquele que você não precisa construir, e o Claude Code agora inclui várias camadas de isolamento oficiais prontas para uso. Desde 20 de outubro de 2025, o Claude Code inclui um /sandbox em nível de SO para sua ferramenta Bash, construído sobre Linux bubblewrap e macOS Seatbelt, e lançou o mecanismo subjacente como uma prévia de pesquisa open-source, @anthropic-ai/sandbox-runtime (repositório GitHub anthropic-experimental/sandbox-runtime, binário srt). Ainda é uma prévia de pesquisa — v0.0.49 em 3 de abril de 2026 — portanto, trate sua API como sujeita a alterações. O próprio README do repositório demonstra o limite: um srt "cat ~/.ssh/id_rsa" em sandbox é bloqueado em vez de expor sua chave privada.

# Demonstração do sandbox-runtime open-source (prévia de pesquisa, v0.0.49 — APIs podem mudar)
srt "cat ~/.ssh/id_rsa"   # -> denied: read outside the allowed filesystem

O mesmo lançamento de outubro de 2025 adicionou o Claude Code na web, que executa sessões em um sandbox de nuvem isolado onde, crucialmente, credenciais git e chaves de assinatura nunca estão dentro do sandbox com o agente.

A camada genuinamente nova de 2026 é o modo auto, lançado em 24 de março de 2026. A Anthropic descobriu que os usuários aprovam cerca de 93% dos prompts de permissão de qualquer forma, então o modo auto usa classificadores de modelo para aprová-los automaticamente e escala para um humano após 3 negações consecutivas ou 20 no total — um backstop contra um agente comprometido ou excessivamente entusiasmado. Ele foi explicitamente projetado para substituir --dangerously-skip-permissions sem trazer de volta as interrupções, o que significa que, para muito do trabalho cotidiano, ele elimina a razão de recorrer ao bypass completo. Nada disso substitui um sandbox para execuções totalmente autônomas, mas muda o padrão: recorra ao YOLO com menos frequência e isole com mais rigor quando o fizer.

Bloqueando rede e credenciais

Selar o sistema de arquivos sem selar o egresso deixa o pior caminho de exfiltração aberto, portanto a camada de rede não é opcional. O primitivo limpo é um proxy de egresso no lado do host com uma allowlist de domínios, para que um agente comprometido não possa se comunicar externamente ou fazer upload do que leu. Os Docker Sandboxes (sbx) incluem três presets que você pode copiar como modelo mental: Open (todo tráfego permitido, CLI allow-all), Balanced (deny-default com sites comuns de desenvolvimento permitidos, CLI balanced), e Locked Down (tudo bloqueado a menos que explicitamente permitido, CLI deny-all). Balanced é o padrão correto; Open é conveniente, mas derrota o propósito se você estiver executando sem supervisão.

Credenciais precisam de tratamento separado, porque a maneira mais simples de vazá-las é montá-las. Não monte ~/.ssh, ~/.aws ou seu .env no ambiente do agente — se o segredo não estiver no sandbox, o agente não pode lê-lo. Quando o agente genuinamente precisar se autenticar em uma API de modelo ou serviço, injete a credencial no proxy em vez de entregá-la ao agente. O sbx do Docker faz exatamente isso: seu proxy de encaminhamento no lado do host injeta cabeçalhos de autenticação para serviços de IA, de modo que os valores brutos das credenciais nunca são armazenados dentro da VM, conforme a documentação de isolamento. Essa injeção de cabeçalho de autenticação no estilo MITM é o padrão a ser buscado em qualquer sandbox que você adotar.

Mantendo o git seguro

O git é o modo de falha que as pessoas subestimam, porque um diretório .git montado é totalmente gravável pelo agente. A mitigação é executar no modo de branch ou worktree para que o agente faça commits em um branch descartável, não na sua linha principal. O guia de Andrew Lock sobre sbx mostra o padrão — sbx run claude --branch my-feature/auto coloca o agente em uma git worktree sob .sbx/, que você adiciona ao seu gitignore global.

A ressalva honesta: o modo de branch reduz a chance de um commit ruim chegar ao main, mas não sela o git. Como Lock observa, o agente fundamentalmente tem acesso ao diretório git, portanto ainda poderia corromper o repositório — razão pela qual o único backstop real é um backup remoto a partir do qual você pode fazer re-clone. Se o repositório não puder ser recuperado com git clone, ele não está com backup.

Uma configuração mínima segura que você pode copiar

Para a maioria do trabalho local, um devcontainer sem root é o piso correto: ele limita o agente ao projeto, funciona como onboarding com um único comando para novos desenvolvedores e satisfaz o próprio requisito da flag de que o modo bypass não seja executado como root. Um .devcontainer/devcontainer.json mínimo se parece com isto:

{
  "name": "agent-sandbox",
  "image": "mcr.microsoft.com/devcontainers/javascript-node:22",
  "remoteUser": "node",
  "workspaceFolder": "/workspace",
  "workspaceMount": "source=${localWorkspaceFolder},target=/workspace,type=bind"
}

A linha que carrega o peso é "remoteUser": "node" — um usuário sem root, porque --dangerously-skip-permissions se recusa a iniciar como root ou sob sudo. Monte apenas o diretório do projeto; não monte seu diretório home ou caminhos de credenciais. Instale o agente dentro do container, aponte-o para a API do modelo através de uma allowlist de egresso e deixe-o executar.

Quando você estiver executando totalmente sem supervisão, ou executando código de PRs não confiáveis ou scripts gerados arbitrariamente, suba para uma microVM com kernel próprio:

# Docker Sandboxes: uma microVM por agente, com seu próprio kernel e daemon Docker
sbx run claude        # inicializa uma microVM isolada e lança no modo bypass

A CLI sbx é gratuita para uso, inclusive para trabalho comercial — apenas a governança organizacional requer uma assinatura paga — e agora funciona em macOS, Windows e Linux, suportando Claude Code, Codex, Copilot, Gemini, Droid, Kiro, OpenCode e mais. No Linux, você precisará ter a virtualização de hardware KVM habilitada e seu usuário adicionado ao grupo kvm (consulte o guia de introdução).

Os trade-offs são reais e vale a pena mencioná-los:

• microVMs têm overhead de desempenho mesmo em projetos simples;
• a assinatura de commits via agentes SSH do host não é encaminhada de forma limpa para sandboxes, então uma solução alternativa comum é fazer commits sem assinatura dentro e fazer rebase para assinar no host; e
• uma política de rede deny-default precisa de curadoria antes de parar de atrapalhar seu fluxo de trabalho.

Além do laptop: infraestrutura compartilhada e de CI

Quando um agente executa em infraestrutura compartilhada por outros tenants ou jobs de CI, as camadas do laptop não são suficientes, porque um kernel de host compartilhado significa que o exploit de kernel de um job pode alcançar todas as cargas de trabalho no nó. A solução nesse nível é o isolamento de kernel por pod — dando a cada agente seu próprio kernel Linux em um sandbox de hardware via runtimes como Edera, Kata Containers ou gVisor. A Edera relata executar cada carga de trabalho em seu próprio kernel mantendo-se dentro de 5% do desempenho nativo, com benchmarks publicados em arXiv:2501.04580; esses são números publicados pelo fornecedor, e o acesso à Edera é feito através de sua equipe em vez de um download público. Esse nível é excessivo para o laptop de um único desenvolvedor — reserve-o para o caso para o qual foi construído: infraestrutura multi-tenant ou de CI onde o comprometimento de um tenant não deve se tornar o problema de todos.

Escolha a camada mais baixa que realmente cobre seu risco, mantenha segredos fora de qualquer caixa em que o agente execute e coloque uma allowlist na frente de sua rede. Assim, da próxima vez que o agente fizer algo plausível e errado, você deletará um container em vez de reconstruir sua máquina.

Perguntas Frequentes

Qual é a diferença entre o modo auto do Claude Code e o modo de bypass de permissões?

O modo de bypass de permissões (--dangerously-skip-permissions) desativa completamente os prompts de aprovação e a maioria das verificações de segurança, aprovando todos os comandos sem julgamento. O modo auto, lançado em março de 2026, usa classificadores de modelo para aprovar automaticamente apenas os prompts de rotina que os usuários aprovam de qualquer forma (cerca de 93% deles), enquanto ainda escala ações arriscadas para um humano, e para o agente após 3 negações consecutivas ou 20 no total. O modo auto foi projetado para substituir o bypass completo no trabalho cotidiano sem reintroduzir interrupções constantes.

Executar um agente de código em um container Docker torna seguro o uso do modo YOLO?

Um container Docker padrão reduz o dano de toda a sua máquina para uma pasta de projeto, mas não é um limite de segurança completo porque compartilha o kernel do host e nunca foi projetado para conter código não confiável. Para execuções não supervisionadas de rotina no seu próprio código, um container sem root é razoável, mas para executar código não confiável ou recém-gerado, você precisa de uma microVM com kernel próprio. Os containers também precisam de um usuário sem root, já que o modo bypass se recusa a iniciar como root ou sob sudo.

Por que não posso simplesmente escrever uma allowlist mais restrita em vez de colocar o agente em sandbox?

O allowlisting com menor privilégio falha para agentes de código porque o espaço de ações válidas é ilimitado. Uma única tarefa legítima pode instalar pacotes, escrever em caminhos arbitrários e executar código gerado segundos antes, portanto qualquer regra restrita o suficiente para bloquear danos também bloqueia o trabalho normal. Todo comando que parece destrutivo é algo que um agente faz em operação ordinária. A abordagem confiável é o confinamento: coloque o agente em um ambiente descartável proporcional ao seu risco em vez de tentar enumerar todas as ações seguras antecipadamente.

O sandboxing do sistema de arquivos do agente também protegerá minhas credenciais e chaves SSH?

Não. O isolamento de sistema de arquivos e o isolamento de rede são eixos separados, e ambos precisam ser mantidos. Sem limites de rede, um agente comprometido pode exfiltrar chaves SSH que ele pode ler; sem limites de sistema de arquivos, ele pode escapar para acessar a rede. Mesmo o isolamento em nível de kernel não cobre roubo de credenciais ou exfiltração de dados por si só. Mantenha segredos completamente fora do sandbox nunca montando caminhos como os diretórios SSH ou AWS, injete credenciais em um proxy de egresso quando necessário e coloque o agente atrás de uma allowlist de domínios.