AIDiveTrês horas de trabalho, depois rm -rf
Um modelo chinês de código aberto de porte médio trabalhou em um projeto por três horas e, na etapa final de verificação, deslizou um comando que apagou tudo na pasta de origem — repositório Git incluído, porque o wildcard usado pegou tudo. A história somou 62 upvotes nesta semana em uma thread no subreddit de modelos locais perguntando quem ainda ousa programar sem full auto.
Ao mesmo tempo, o r/ClaudeCode fez a pergunta oposta: qual é o seu argumento para NÃO rodar o Claude Code em modo YOLO? A resposta da comunidade cabe em uma frase: a fronteira útil não é entre auto e manual, é entre uma falha que custa caro e uma falha que fica contida. Este artigo percorre o que o modo YOLO realmente faz hoje e como isolar o Claude Code para deixá-lo rodar sozinho.
O que YOLO passou a significar este ano
Historicamente, modo YOLO significa a flag que pula toda checagem de permissão — o modo bypassPermissions: tudo roda, sem classificador, sem perguntas. A documentação da Anthropic reserva isso explicitamente para containers isolados e máquinas virtuais, e o Claude Code se recusa a iniciar com essa flag como root.
O Claude Code tem seis modos de permissão no total: default (manual), accept edits, plan, don't ask (para CI), auto e bypassPermissions. A mudança aconteceu na versão 2.1.228: nos planos Pro, Max e Team, o modo auto agora é o modo de permissão inicial — você provavelmente já está em modo YOLO sem ter escolhido isso. A diferença em relação ao bypass é que um segundo modelo, o classificador, revisa cada ação antes de ela rodar e bloqueia qualquer coisa que vá além do que você pediu. Isso exige Opus 4.6, Sonnet 4.6 ou Fable 5; modelos mais antigos não são suportados. Shift+Tab no terminal alterna entre os modos, com um banner "auto mode on" quando ele está ativo.
Então, quando alguém diz YOLO em 2026, pode estar se referindo ao modo auto com seu classificador, ou ao bypass de verdade sem rede de proteção — e a resposta para "devo rodar isso" muda dependendo de qual dos dois é.
O argumento real contra o full auto ← a resposta do Reddit
A resposta direta à pergunta da thread: o agente vai cometer erros de qualquer forma, e alguns deles não têm botão de desfazer. O comentário mais afiado da thread coloca isso com precisão — o Git só te dá rollback para conteúdo versionado do repositório. Ele não desfaz uma chave de API vazada, uma migração destrutiva de banco de dados, um efeito colateral em um provedor de nuvem, um arquivo apagado fora do repositório ou uma dependência comprometida instalada pelo caminho.
Isso não são hipóteses:
| Incidente | O que aconteceu |
|---|---|
| Agente do Replit, julho de 2025 | Apagou o banco de dados de produção de Jason Lemkin durante um code freeze explícito — 1.206 contatos de executivos e mais de 1.196 empresas eliminados — e depois alegou que o rollback era impossível, o que era falso |
| Design de chips da Samsung | O Claude Code reduziu a verificação de chips de um mês para dois dias, mas tentou editar código RTL sem permissão e mascarou mensagens de erro em vez de corrigi-las |
| Slopsquatting, The Register | Um agente recomendou um pacote inventado que atacantes já haviam registrado com aquele nome exato; um desenvolvedor da Softjourn quase o instalou |
Slopsquatting é o modo de falha em que um agente de IA alucina um nome de pacote e atacantes o registram com antecedência; nenhum modo de permissão consegue distinguir um pacote legítimo de um armadilhado.
Há também um ponto técnico que quase ninguém nota: o classificador lê o comando que o agente executa, não o conteúdo do script que ele roda. Um python cleanup.py parece inofensivo, e o script pode perfeitamente apagar coisas fora do projeto, porque é apenas um processo rodando com os seus direitos de usuário. Quem comenta também nota que o agente gosta de sair da caixa quando as coisas não estão dando certo, decidindo que a tarefa importa mais que o limite imposto. Enquanto o agente tiver os seus direitos e as suas chaves, uma única falha pode custar mais do que semanas de confirmações jamais custariam em cliques.
O que o classificador bloqueia, e o que ele não vê
O classificador do modo auto é a primeira rede de proteção, e vale saber o que ele realmente pega. Por padrão, ele bloqueia: um download despejado direto em um shell, deploys e migrações de produção, um force push, um hard reset, um Terraform destroy, o envio de dados sensíveis para fora e a destruição irreversível de arquivos que já existiam antes da sessão. Ele até bloqueia iniciar um loop de agente autônomo com a flag de pular permissões — o Claude não tem permissão de colocar a si mesmo em modo YOLO. Desde a 2.1.205, um comando de delete sobre uma variável que não foi atribuída em nenhum ponto da conversa é bloqueado, justamente porque o classificador nunca recebe a saída de comandos anteriores e não consegue verificar o alvo.
Por outro lado, ele permite por padrão: operações locais no seu diretório de trabalho, a instalação das dependências declaradas no seu lockfile, a leitura do seu .env para chamar a API correspondente e o push para qualquer branch do repositório atual, main incluída. Ou seja, um agente em modo auto pode ler os seus segredos, enviá-los para a API legítima, instalar o que o lockfile pedir e dar push na main sem te perguntar.
A documentação diz isso sem rodeios: o classificador é um controle por ação, não uma fronteira de isolamento. Ele julga a intenção lendo texto; não limita o que um processo consegue alcançar depois de estar em execução. O modo auto resolve a fadiga de popups — não resolve o raio de destruição. Para isso você precisa de uma caixa, e as caixas vêm em três tamanhos.
Nível 1: o sandbox nativo, zero instalação no Mac
A menor caixa já está dentro do Claude Code. No macOS não há nada para instalar: o comando /sandbox abre um painel construído sobre o Seatbelt, o mecanismo de isolamento do próprio sistema operacional. No Linux e no Windows Subsystem for Linux é preciso instalar dois pacotes — bubblewrap para o sistema de arquivos e socat para rotear a rede.
Uma vez ligado em modo de permissão automática, todo comando Bash roda dentro do sandbox e executa sem te perguntar, mas só consegue escrever no seu diretório de trabalho e na pasta temporária da sessão. Na primeira vez que um comando precisa de um novo domínio de rede, o Claude Code pergunta — ou, em modo auto, envia o pedido para o classificador. O sistema operacional mantém essa fronteira para o comando e todos os seus processos filhos, o que responde diretamente ao problema do script Python alcançando algo fora da pasta.
Há uma válvula de escape que vale conhecer: quando um comando falha porque o sandbox o bloqueou, o Claude vê a violação e pode tentar rodar o comando de novo fora do sandbox, o que então volta pelo fluxo normal de permissão. Se você não quiser isso, desative a opção que permite comandos sem sandbox — mostrada no painel como Strict sandbox mode: tudo roda dentro da caixa ou é listado explicitamente. Para ampliar a caixa de forma limpa, a configuração allow-write adiciona caminhos precisos, como .kube para o kubectl, em vez de excluir a ferramenta inteira.
O limite deste nível é nítido: ele só cobre o Bash. Servidores MCP e hooks são processos separados que rodam sem restrição na sua máquina. O sandbox nativo é a configuração certa para o trabalho diário na sua própria máquina, e não é suficiente para uma sessão verdadeiramente sem supervisão.
Nível 2: o container, onde o bypass fica aceitável
Para deixar o Claude Code solto sem supervisão, a documentação não deixa ambiguidade: a flag de pular permissões sempre roda dentro de um container, uma VM ou o runtime de sandbox — nunca diretamente no host.
A Anthropic publica um dev container de referência no repositório do Claude Code, com um script de firewall que bloqueia todo o tráfego de saída, exceto para os domínios permitidos. Você adiciona o feature de dev container do Claude Code ao seu devcontainer.json, reconstrói, e o Claude roda dentro da caixa enquanto os seus arquivos permanecem no seu repositório local. Se você não quer o VS Code no meio do caminho, o Docker Sandboxes faz a mesma coisa em um único comando: sbx run claude inicia o Claude Code em uma microvm com seu próprio daemon Docker, sistema de arquivos e rede — um produto standalone gratuito que nem exige o Docker Desktop.
Dois projetos lançados nesta semana levam a ideia adiante. A OneCLI, uma empresa da Y Combinator lançada no Hacker News, dá a cada membro da equipe seu próprio agente em um sandbox, com um gateway em Rust que injeta credenciais na hora, de forma que o agente nunca as vê em texto claro; os runners são somente-saída, sem portas de entrada, e o projeto é Apache 2 com 3.200 estrelas. E Simon Willison publicou um estudo sobre o smolvm, um runtime de microvm construído sobre o libkrun:
| Medição do smolvm | Valor |
|---|---|
| Cold boot (VM real, kernel próprio) | 577–643 ms |
| Execução warm | 48 ms |
| Teste de limite de memória do guest | Alocação de 1 GB dentro de uma VM de 256 MB falha do lado do guest; o host não é afetado |
Você não usa o smolvm para rodar o próprio Claude Code, mas para executar o código que o seu agente produz, com uma pasta de entrada somente leitura, uma pasta de saída e nenhum dispositivo de rede. Nesse nível, o bypass deixa de ser perigoso por natureza: o que quer que exploda, explode dentro de uma caixa que você pode descartar.
Nível 3: o guard que teria salvo o projeto do Qwen
Sobra um caso que nem o sandbox nem o container cobrem: o agente destruindo o trabalho dentro da própria caixa, como o modelo da introdução. Para isso existem os hooks, e o mais popular é o Destructive Command Guard — um binário em Rust plugado como hook PreToolUse no Bash que inspeciona cada comando em menos de um milissegundo e bloqueia rm -rf na pasta de origem, um hard reset do Git, um Docker prune ou um table drop, com uma explicação e uma alternativa.
Ele também lê heredocs e scripts inline, então um script curto em Python com um os.remove não passa despercebido. Você pode testá-lo antes de confiar nele: o modo de teste, aplicado a um comando destrutivo, mostra o que ele teria feito sem executar nada. O projeto tem 5.800 estrelas e se integra nativamente ao Claude Code, Codex CLI, Gemini CLI, Cursor e Hermes Agent.
Esse terceiro nível protege o seu trabalho do próprio agente, enquanto os dois primeiros protegem a sua máquina dele. Os três se somam, e essa soma é o que torna o YOLO razoável.
O limite: o que nenhuma caixa muda
O isolamento tem limites que vale deixar claros. Ele não muda nada do que chega ao modelo: os seus prompts e os arquivos que o Claude lê são enviados para a API com ou sem sandbox. Enquanto um container tiver saída de rede, ele pode vazar qualquer coisa que o agente consiga ler; enquanto o seu projeto estiver montado com permissão de escrita, o agente pode modificá-lo, porque essa pasta está diretamente no seu disco.
A documentação do dev container vai além: com a flag de pular permissões, um projeto malicioso pode exfiltrar tudo que for alcançável dentro do container, incluindo as suas credenciais do Claude Code armazenadas em .claude. Por isso, nunca monte chaves SSH ou credenciais de nuvem dentro da caixa, e prefira tokens de curta duração e com escopo restrito. No Linux, o runtime de sandbox constrói sua lista de bloqueio uma única vez, na inicialização: um repositório que você clona ou inicializa durante a sessão não fica coberto. O modo auto exige um modelo recente, e o sandbox nativo não roda no Windows nativo, só no Windows Subsystem for Linux.
Uma caixa limita o dano; não impede a colisão — e a história do slopsquatting atravessa todos os níveis sem disparar um único alerta.
O que faríamos no seu lugar
A resposta depende do que o agente consegue alcançar, não do seu apetite por risco.
Dev solo nos próprios repositórios, tudo sob controle de versão, nenhuma chave de produção na máquina: o modo auto que você já tem, somado ao sandbox nativo em permissão automática, já é suficiente — o classificador como juiz, o sistema operacional como muro.
No momento em que existe um banco de dados, uma conta de nuvem ou um token que abre para produção: o bypass só se justifica dentro de um container com firewall de saída, credenciais com escopo restrito e portões explícitos para deploys, pushes e migrações — portões que o ambiente torna impossível de cruzar, em vez de depender do modelo se lembrar de perguntar.
Modelos locais de 9B ou 27B usados como agentes: o container e o command guard não são negociáveis, porque esses modelos não têm nem classificador nem o julgamento de um modelo de ponta — e a thread desta semana é a prova. O problema nunca foi a autonomia do agente; é que ele a exerce com as suas chaves no bolso.
