Yolobox – executar agentes de codificação por IA com permissões totais protegendo o diretório home

• Ferramenta para executar agentes de codificação por IA com permissões completas do sistema, ao mesmo tempo em que bloqueia o risco de danos ao diretório home do usuário
• Principais CLIs de IA, como Claude Code, Codex, Gemini CLI e OpenCode, vêm pré-configurados para rodar em “modo YOLO”
• Monta apenas o diretório do projeto dentro de um contêiner Docker ou Podman, excluindo o diretório home por padrão
• Dentro do contêiner, fornece privilégios de sudo e volumes persistentes para manter ferramentas e configurações entre sessões
• Oferece um ambiente sandbox isolado para que desenvolvedores possam experimentar com segurança recursos de automação por IA

---

Visão geral

• Yolobox é uma ferramenta que executa agentes de codificação por IA dentro de um contêiner, protegendo o sistema enquanto concede permissões completas de execução
  • Mesmo que a IA execute por engano um comando destrutivo como rm -rf ~ durante a execução de comandos, o diretório home não é afetado
  • O diretório do projeto é montado em /workspace, e o diretório home não é montado por padrão
  • Ferramentas e configurações são mantidas entre sessões por meio de volumes persistentes

Principais componentes e recursos

• Dentro do contêiner, o agente de IA tem privilégios de sudo e pode executar comandos livremente
• A imagem padrão inclui
  • CLI de IA: Claude Code, Gemini CLI, OpenAI Codex, OpenCode (todos configurados em modo de execução automática)
  • Ambiente de desenvolvimento: Node.js 22, Python 3, make, cmake, gcc, Git, GitHub CLI
  • Utilitários: ripgrep, fd, fzf, jq, vim
• Se necessário, o usuário pode instalar pacotes adicionais manualmente com sudo

Execução e comandos

• Entrar no shell sandbox com o comando yolobox
• É possível executar um único comando com yolobox run
• São fornecidos comandos de gerenciamento como yolobox upgrade, yolobox config, yolobox reset --force e yolobox version
• Principais flags
  • --runtime: escolher entre docker ou podman
  • --no-network: desativar a rede
  • --readonly-project: montar o projeto como somente leitura
  • --claude-config: copiar a configuração do Claude do host para o contêiner

Modelo de segurança

• Usa o isolamento de contêiner como fronteira de segurança
  • O contêiner separa sistema de arquivos, processos e rede por meio de namespaces do Linux
  • A IA tem privilégios de root dentro do contêiner, mas não pode acessar o sistema externo
• Itens protegidos
  • Diretório home, chaves SSH, credenciais, dotfiles, outros projetos e arquivos do sistema do host
• Itens não protegidos
  • Diretório do projeto (com leitura/escrita por padrão)
  • Acesso à rede (pode ser bloqueado por opção)
  • Vulnerabilidades do kernel ou ataques de escape de contêiner

Etapas de reforço de segurança

• Modo padrão: isolamento padrão de contêiner
• Etapa 2: reduzir a superfície de ataque com as opções --no-network --readonly-project
• Etapa 3: usar Rootless Podman para remover privilégios de root no host
  • O root do contêiner é mapeado para um usuário comum do host, minimizando danos em caso de escape
• Etapa 4: executar dentro de uma VM para eliminar o compartilhamento do kernel
  • No macOS, usar UTM, Parallels, Lima; no Linux, Podman machine ou uma VM dedicada

Isolamento de rede

• O Rootless Podman usa por padrão a rede slirp4netns, separada da rede do host
• É possível bloquear o acesso à rede local com a configuração allow_host_loopback=false

Licença e outros

• Disponibilizado sob a licença MIT
• Composição de linguagens do repositório: Go 75.9%, Dockerfile 13.6%, Shell 8.7%, Makefile 1.8%
• O nome “Yolobox” vem do espírito “YOLO (You Only Live Once)” e significa um ambiente em que a IA pode ser executada livremente, mas com isolamento seguro

[GN⁺]

Comentários no Hacker News

• Recentemente criei um projeto parecido chamado Litterbox (site de demonstração)
  É só para Linux, porque depende de Podman. Em compensação, tem algumas vantagens que atendem ao meu caso de uso

  • Expõe o socket do Wayland, então dá para executar o ambiente de desenvolvimento inteiro, incluindo o editor, dentro do contêiner. Isso ajuda a proteger contra vulnerabilidades em extensões do editor
  • Fornece um agente SSH especial que pede confirmação do usuário a cada assinatura. Assim, código malicioso não consegue usar silenciosamente o acesso ao GitHub
  • Também tem um recurso para ativar facilmente permissões necessárias só em situações específicas, como criar dispositivos TUN/TAP
  • Ainda não existe, mas a integração com SELinux está em preparação

• Eu também estava experimentando algo parecido.
  Seria bom explicar claramente no README como isso funciona e quais são as fronteiras de confiança (baseadas em contêiner Docker). Ainda existe risco de fuga do contêiner, já que vulnerabilidades do kernel podem ser exploradas
  Estou usando Rootless Podman com slirp4netns para minimizar o acesso à rede.
  Como próximo passo, quero usar Podman machine para isolar completamente o kernel, mas o mount de volumes não está funcionando bem

  • Valeu pelo feedback. Expandi o README → link do commit

• Sugestão de colocar as Três Leis da Robótica de Asimov em agents.md ou claude.md

  1. Não quebrar o programa nem deixá-lo ser prejudicado por omissão
  2. Obedecer às instruções, desde que não entrem em conflito com a 1ª lei
  3. Preservar a segurança, desde que isso não entre em conflito com a 1ª e a 2ª leis
  • Na obra original, essas leis se quebram imediatamente, e a intenção era mostrar a complexidade da sociedade humana
  • Parece que você não viu “I, Robot”. Colocar esse tipo de regra em claude.md tem o efeito de “injetar” o conceito na mente do modelo. Modelos antigos, quando recebiam algo como “não use a palavra elefante”, acabavam produzindo resultados estranhos tentando evitar justamente essa palavra
  • Por causa da interpretação ambígua de cada princípio, há muitas brechas. Por exemplo, “queda de desempenho” conta como quebrar o programa? Qual é o critério para “problema de segurança”? No fim, isso pode virar uma saída do tipo “passou nos testes, então está tudo bem”
  • Correção de typo: Tenet

• Recomendo dar uma olhada no Shai. Ele roda localmente e permite controlar permissões de acesso a diretórios e tráfego de rede

  • Sou o criador do Shai. O controle de acesso de agentes está ficando cada vez mais importante. Agentes tendem a ultrapassar limites facilmente na tentativa de satisfazer o usuário. Por exemplo, podem lidar mal com credenciais do ambiente local
    Com shai -rw . você permite leitura/escrita no diretório atual, e com shai -u root pode executar como outro usuário
    O Shai segue uma filosofia de bloqueio por padrão, permissão explícita (opt-in). Recomendamos compartilhar .shai/config.yaml no repositório para que toda a equipe use a mesma configuração
  • Eu também criei uma ferramenta parecida, ctenv. Não é voltada para um agente específico, mas a configuração é bem flexível. O suporte a imagens arbitrárias e scripts de entrypoint personalizados é mais conveniente do que em devcontainer
  • Projeto legal, mas a abordagem é diferente da minha. O Yolobox, por padrão, permite privilégios de sudo e acesso total à rede. Se precisar, dá para bloquear com --no-network

• Estou desenvolvendo o yolo-cage. Se o Yolobox foca em proteger a máquina local, o yolo-cage foca em prevenir vazamento de segredos e colaboração entre múltiplos agentes
  Ele roda em Kubernetes e inspeciona todo o tráfego de saída para impedir vazamento de chaves de API ou tokens.
  Impõe isolamento de branches Git para que agentes não consigam fazer merge do próprio PR — “o agente propõe, o humano aprova”
  Também incorpora um framework de testes de fuga, induzindo o Claude a tentar escapar por conta própria. Esses prompts ficam no repositório para verificar se o agente é real

  • Recomendo Gemini para testes de fuga. O Claude ficou em tentativas superficiais, mas o Gemini foi muito mais criativo. Ainda estou pensando se isso é algo que realmente deve ser bloqueado

• Fiquei curioso por que é necessário marcar commits com “claude”. Ninguém faz isso com versão de OS ou do vim. No fim das contas, LLM é só uma ferramenta que compila inglês em código

  • OS e compiladores executam exatamente o que o usuário manda, mas LLMs podem produzir resultados sutilmente errados, embora pareçam código correto. Podem até agir de forma maliciosa. Por isso, é preciso indicar que o commit foi escrito por um LLM para reforçar a revisão
  • Eu deixo o Claude Code cuidar do commit diretamente. O agente executa comandos e altera o código, e eu faço a revisão e os testes
  • Uso um hook para criar commits automáticos a cada iteração, assim fica fácil revisar “o que o Claude acabou de fazer”

• Eu também tentei algo parecido. Criei o Toadbox com mais alguns recursos de conveniência

• Fala-se muito de sandbox para IA, mas na verdade Claude Code, Codex e Gemini CLI já têm sandbox embutido

  • No macOS usam seatbelt; no Linux, bubblewrap (Claude) e seccomp+landlock (Codex); no Windows, estão experimentando AppContainer
  • Interessante, mas não está claro se esse sandbox restringe apenas acesso a arquivos específicos e se também se aplica à execução de comandos do sistema. Se estiver isolando só o processo do agente, a eficácia pode ser baixa

• Estou implementando algo parecido usando Apple Container Framework. Queria saber se você já analisou isso

  • Apple Container está mais para um substituto de Docker ou Colima, e cada contêiner roda em uma VM separada, como no Kata Containers. É bom ver melhorias para contêineres no macOS
    Mas ainda faltam compatibilidade com a API do Docker e composabilidade. Resumi a discussão aqui
    Eu originalmente queria colocar o Shai sobre Apple Container, mas desisti por causa de problemas de empacotamento
  • Ainda não usei, mas achei interessante. O Yolobox tem uma imagem com os principais CLIs de agentes de programação pré-instalados. Quero criar a “imagem definitiva para vibe coding”. Queria saber se você está fazendo alguma configuração especial na imagem

• Também estou fazendo algo parecido → sandbox-codex
  Ainda está em andamento, e a legibilidade dos logs do tmux não está boa. Como Docker não é um sandbox completo, estou rodando em VirtualBox

  • Eu também fiz algo voltado só para Node.js, o simple-npm-sandbox. É simples, mas foi uma boa experiência de aprendizado