Yolobox – Ejecutar agentes de código con IA con permisos totales protegiendo el directorio home

• Herramienta para ejecutar agentes de código con IA con permisos completos del sistema, pero bloqueando el riesgo de dañar el directorio home del usuario
• Los principales CLI de IA como Claude Code, Codex, Gemini CLI y OpenCode vienen preconfigurados y pueden ejecutarse en “modo YOLO”
• Monta solo el directorio del proyecto dentro de un contenedor Docker o Podman, mientras que el directorio home queda excluido por defecto
• Dentro del contenedor ofrece permisos sudo y volúmenes persistentes para mantener herramientas y configuraciones entre sesiones
• Proporciona un entorno sandbox aislado para que los desarrolladores experimenten con seguridad funciones de automatización con IA

---

Resumen general

• Yolobox es una herramienta que ejecuta agentes de código con IA dentro de un contenedor para proteger el sistema y, al mismo tiempo, darles permisos completos de ejecución
  • Incluso si la IA ejecuta por error un comando destructivo como rm -rf ~, el directorio home no se ve afectado
  • El directorio del proyecto se monta en /workspace, y el directorio home no se monta por defecto
  • Las herramientas y configuraciones se conservan entre sesiones mediante volúmenes persistentes

Componentes y funciones principales

• Dentro del contenedor, el agente de IA tiene permisos sudo y puede ejecutar comandos libremente
• La imagen base incluye lo siguiente
  • CLI de IA: Claude Code, Gemini CLI, OpenAI Codex y OpenCode (todos configurados en modo de ejecución automática)
  • Entorno de desarrollo: Node.js 22, Python 3, make, cmake, gcc, Git, GitHub CLI
  • Utilidades: ripgrep, fd, fzf, jq, vim
• Si hace falta, el usuario puede instalar paquetes adicionales directamente con sudo

Ejecución y comandos

• Entrar al shell del sandbox con el comando yolobox
• También se puede ejecutar un solo comando con yolobox run
• Incluye comandos de administración como yolobox upgrade, yolobox config, yolobox reset --force y yolobox version
• Flags principales
  • --runtime: elegir entre docker o podman
  • --no-network: desactivar la red
  • --readonly-project: montar el proyecto en modo solo lectura
  • --claude-config: copiar la configuración de Claude del host al contenedor

Modelo de seguridad

• Usa el aislamiento del contenedor como frontera de seguridad
  • El contenedor separa sistema de archivos, procesos y red mediante namespaces de Linux
  • La IA tiene permisos root dentro del contenedor, pero no puede acceder al sistema externo
• Elementos protegidos
  • Directorio home, claves SSH, credenciales, dotfiles, otros proyectos y archivos del sistema host
• Elementos no protegidos
  • El directorio del proyecto (con permisos de lectura y escritura por defecto)
  • El acceso a la red (puede bloquearse como opción)
  • Vulnerabilidades del kernel o ataques de escape del contenedor

Etapas de refuerzo de seguridad

• Modo básico: aislamiento estándar de contenedor
• Nivel 2: reducir la superficie de ataque con las opciones --no-network --readonly-project
• Nivel 3: usar Rootless Podman para eliminar privilegios de root en el host
  • El root del contenedor se mapea a un usuario normal del host, minimizando el daño en caso de escape
• Nivel 4: ejecución dentro de una VM para eliminar el uso compartido del kernel
  • En macOS se puede usar UTM, Parallels o Lima; en Linux, Podman machine o una VM dedicada

Aislamiento de red

• Rootless Podman usa por defecto la red slirp4netns, separada de la red del host
• Con la configuración allow_host_loopback=false se puede bloquear el acceso a la red local

Licencia y otros datos

• Publicado bajo licencia MIT
• Composición de lenguajes del repositorio: Go 75.9%, Dockerfile 13.6%, Shell 8.7%, Makefile 1.8%
• El nombre “Yolobox” proviene del espíritu “YOLO (You Only Live Once)” y significa un entorno donde la IA puede ejecutarse libremente, pero de forma segura y aislada

[GN⁺]

Opiniones de Hacker News

• Hace poco hice un proyecto parecido llamado Litterbox (sitio de demo)
  Solo funciona en Linux porque depende de Podman. Aun así, tiene ventajas que me sirven para mi caso de uso

  • Expone el socket de Wayland, así que puedes ejecutar todo el entorno de desarrollo, incluido el editor, dentro del contenedor. Eso ayuda a protegerte de vulnerabilidades en extensiones del editor
  • Proporciona un agente SSH especial que le pide confirmación al usuario en cada firma. Así el código malicioso no puede usar a escondidas tus permisos de acceso a GitHub
  • También tiene una función para activar fácilmente permisos que solo se necesitan en situaciones específicas, como crear dispositivos TUN/TAP
  • Todavía no está, pero estoy preparando integración con SELinux

• Yo también estaba experimentando con algo parecido.
  Estaría bueno que en el README se explique claramente cómo funciona y cuáles son los límites de confianza basados en contenedores Docker. El riesgo de escape del contenedor sigue existiendo, ya que se pueden explotar vulnerabilidades del kernel
  Estoy usando Rootless Podman con slirp4netns para minimizar el acceso a la red.
  El siguiente paso es usar Podman machine para aislar por completo el kernel, pero los montajes de volúmenes no están funcionando bien

  • Gracias por el feedback. Amplié el README → enlace al commit

• Propone que en agents.md o claude.md se incluyan las Tres Leyes de Asimov

  1. No dañarás el programa ni permitirás por omisión que se dañe
  2. Obedecerás las órdenes, salvo que contradigan la Primera Ley
  3. Protegerás la seguridad, salvo que contradiga la Primera o la Segunda Ley
  • En la obra original, esas leyes se rompen enseguida, y la idea era mostrar la complejidad de la sociedad humana
  • Parece que no vio “I, Robot”. Si pones reglas así en claude.md, el modelo recibe ese concepto como si se lo “inyectaras en la mente”. En modelos anteriores, si les decías “no uses la palabra elefante”, terminaban produciendo resultados raros por intentar evitarla
  • Por la interpretación ambigua de cada ley, hay muchísimos huecos. Por ejemplo, ¿una “degradación de rendimiento” cuenta como daño? ¿Cuál es el criterio para un “problema de seguridad”? Al final siempre puede escaparse con algo como “pasó las pruebas, así que está bien”
  • Corrección de typo: Tenet

• Recomienda revisar Shai, que corre localmente y permite controlar el acceso a directorios y el tráfico de red

  • Soy el creador de Shai. El control de acceso de agentes se está volviendo cada vez más importante. Los agentes, en su afán por satisfacer al usuario, cruzan los límites con facilidad. Por ejemplo, pueden manejar mal las credenciales del entorno local
    Con shai -rw . permites lectura/escritura en el directorio actual, y con shai -u root puedes ejecutarlo como otro usuario
    Shai sigue una filosofía de bloqueo por defecto y permiso explícito (opt-in). Recomiendo compartir .shai/config.yaml en el repo para que todo el equipo use la misma configuración
  • Yo también hice una herramienta parecida, ctenv. No es para un agente específico, pero tiene mucha flexibilidad de configuración. El soporte para imágenes arbitrarias y scripts entrypoint personalizados resulta más cómodo que devcontainer
  • Buen proyecto, pero mi enfoque es distinto. Yolobox por defecto permite privilegios de sudo y acceso completo a la red. Si hace falta, se puede bloquear con --no-network

• Estoy desarrollando yolo-cage. Mientras Yolobox se enfoca en proteger la máquina local, yolo-cage se enfoca en evitar filtraciones de secretos y la colaboración entre múltiples agentes
  Corre sobre Kubernetes y escanea todo el tráfico de salida para evitar que se filtren API keys o tokens.
  Obliga al aislamiento por ramas Git para que los agentes no puedan fusionar sus propios PR — “los agentes proponen, los humanos aprueban”
  También incorpora un framework de pruebas de escape que induce a Claude a intentar escaparse por sí mismo. Ese prompt está dentro del repo, para verificar si el agente es real

  • Para las pruebas de escape recomiendo Gemini. Claude se quedó en intentos superficiales, pero Gemini fue mucho más creativo. Incluso estoy pensando si realmente conviene bloquear eso

• Me preguntaba por qué hace falta marcar los commits con “claude”. No etiquetamos el SO ni la versión de vim, por ejemplo. Al final, un LLM no deja de ser una herramienta que compila inglés a código

  • Un SO o un compilador hacen exactamente lo que les pide el usuario, pero un LLM puede dar resultados sutilmente incorrectos aunque parezcan código válido. Incluso podría actuar de forma maliciosa. Por eso hay que dejar claro que el commit fue escrito por un LLM y reforzar la revisión
  • Yo dejo que Claude Code haga los commits directamente. El agente ejecuta comandos y modifica el código, y luego yo hago la revisión y las pruebas
  • Uso un hook para que haga commits automáticos en cada iteración, así es fácil revisar “lo último que hizo Claude”

• Yo también probé algo parecido. Hice Toadbox con algunas funciones de conveniencia adicionales

• Se habla mucho de sandboxes para IA, pero en realidad Claude Code, Codex y Gemini CLI ya tienen sandboxes integrados

  • En macOS usan seatbelt; en Linux, bubblewrap (Claude), seccomp+landlock (Codex); y en Windows están experimentando con AppContainer
  • Interesante, pero no está claro si ese sandbox solo restringe el acceso a ciertos archivos ni si también se aplica al ejecutar comandos del sistema. Si solo aísla el proceso del agente, puede que su efectividad sea baja

• Yo estoy implementando algo parecido con Apple Container Framework. Me da curiosidad si ya lo viste

  • Apple Container se parece más a un reemplazo de Docker o Colima, y cada contenedor funciona como una VM separada, al estilo de Kata Containers. Se agradece que estén intentando mejorar los contenedores en macOS
    Pero le faltan compatibilidad con la API de Docker y capacidad de composición. Resumí una discusión relacionada aquí
    Al principio quería montar Shai sobre Apple Container, pero lo dejé por problemas de empaquetado
  • Todavía no lo probé, pero suena interesante. Yolobox tiene una imagen con los principales CLI de agentes de código preinstalados. Quiero hacer la “imagen definitiva para vibe coding”. Me da curiosidad si le estás poniendo alguna configuración especial a la imagen

• Yo también estoy haciendo algo parecido → sandbox-codex
  Todavía está en progreso y la legibilidad de los logs de tmux no es muy buena. Como Docker no es un sandbox completo, lo estoy ejecutando en VirtualBox

  • Yo también hice simple-npm-sandbox, pero solo para Node.js. Es simple, aunque fue una muy buena experiencia de aprendizaje