Usas más de un agente
ai-jail: un solo archivo de política, cualquier comando, todo el proceso dentro. Instalar.
Comparar
Tu agente ya tiene un sandbox. Cubre otra mitad.
Los sandboxes integrados y las solicitudes de permiso vigilan los comandos que ejecuta el modelo. ai-jail decide qué puede ver en tu máquina el programa del agente entero, y está pensado para los errores de un agente de confianza. Los dos trabajan juntos.
Para quien elige entre herramientas. Las seis situaciones de arriba responden casi todo.
Última revisión: 15 de octubre de 2026. Los otros productos cambian rápido, así que cada afirmación sobre ellos enlaza a la documentación del propio fabricante.
En resumen
Seis situaciones, una respuesta para cada una. El resto de la página muestra la evidencia.
Solo usas Claude Code
El sandbox-runtime de la propia Anthropic también envuelve el proceso entero, en beta; ai-jail añade un home vacío y una red cerrada. Mira las tarjetas.
Quieres el sandbox y las solicitudes del propio agente
Déjalos activados. Funcionan dentro de ai-jail. Usa los dos.
Quieres políticas por herramienta, aprobaciones en tiempo de ejecución y un registro de auditoría firmado
nono llega más lejos ahí, a cambio de un lenguaje de políticas y un supervisor. Compara los wrappers.
Aíslas desde código, una llamada a herramienta a la vez
zerobox tiene SDKs para eso; deja las lecturas abiertas y no tiene ninguna versión nueva desde mayo de 2026. Compara los wrappers.
No confías en el código en absoluto
Una máquina virtual desechable. Todas las herramientas de esta página comparten tu kernel. Docker, contenedores y VMs.
Dónde está el muro
Al momento de escribir esto, el sandbox de Claude Code se aplica a los comandos de shell y a sus procesos hijos. Sus herramientas de archivos usan en cambio el sistema de permisos, y su documentación dice que los servidores MCP y los hooks corren sin restricciones en el host. ai-jail arranca al propio agente dentro del muro, así que todo lo que él lanza también queda dentro.
↔ Desliza hacia un lado para ver el diagrama completo
Codex también aísla los comandos que lanza y deja fuera el proceso codex. Su documentación dice que los servidores MCP usan su propio proceso o transporte, fuera del sandbox.
Una solicitud de permiso es otro tipo de protección
Una solicitud le pregunta a una persona, y a una persona se la puede apurar o engañar. Un sandbox le pregunta al kernel, que responde lo mismo todas las veces.
↔ Desliza hacia un lado para ver el diagrama completo
Modos que sacan a la persona del medio
Al momento de escribir esto, cada uno de estos agentes tiene un modo que deja de preguntar. Sin la solicitud, el sandbox es la única protección que queda, si hay uno activado.
| Agente | Modo | Qué dice el fabricante que hace |
|---|---|---|
| Claude Code | auto | Todo se ejecuta y un segundo modelo revisa las acciones en tu lugar. La documentación llama a este clasificador un control por acción, no una frontera de aislamiento. |
| Claude Code | bypassPermissions, también --dangerously-skip-permissions | Todo se ejecuta sin comprobaciones. La documentación dice que se use solo en contenedores y VMs aislados. |
| Codex CLI | Política de aprobación never | El agente nunca pregunta. El modo de sandbox sigue aplicándose. Mira aprobaciones y seguridad. |
| Codex CLI | danger-full-access, o --yolo | El sandbox está apagado. Con --yolo tampoco hay aprobaciones. |
Lado a lado
Todo lo que aparece aquí describe la documentación de cada producto al momento de escribir esto. Cuando la documentación que leímos no responde una pregunta, la celda lo dice.
| Sandbox de Claude Code | Sandbox de Codex CLI | Sandbox de Gemini CLI | ai-jail | |
|---|---|---|---|---|
| Lo que añade envolver al agente entero | ||||
| Qué hay dentro del muro | Los comandos de Bash, PowerShell y Monitor y sus hijos. El proceso claude, sus herramientas de archivos, los servidores MCP y los hooks quedan fuera. | Los comandos que lanza el agente. El proceso codex queda fuera. La documentación dice que los servidores MCP, locales y remotos, usan su propio proceso o transporte, así que también quedan fuera. | El proceso entero de la CLI, o solo la shell y las herramientas de escritura con security.toolSandboxing. | Todo el árbol de procesos: el agente, sus herramientas de archivos, los servidores MCP, los hooks y cada comando. |
| Activado por defecto | No. Lo activas con /sandbox o sandbox.enabled. Si falta una dependencia, avisa y ejecuta los comandos sin sandbox, salvo que definas sandbox.failIfUnavailable. | Sí. workspace-write es el modo por defecto. | Lo activas con -s, GEMINI_SANDBOX o tools.sandbox. | Está activado siempre que arrancas al agente a través de él. Si la configuración es inválida, se niega a arrancar. |
¿El código aislado puede leer ~/.ssh por defecto? | Sí. La documentación dice que la configuración por defecto sigue permitiendo leer archivos de credenciales como ~/.aws/credentials y ~/.ssh/. Las reglas de denegación son opt-in. | Sí en Linux, donde todo el sistema de archivos se monta en solo lectura. Un perfil de permisos puede añadir reglas deny para rutas como **/.env*, y la configuración endurecida de la propia OpenAI lo hace. Valor por defecto en macOS: no documentado. | El perfil por defecto en macOS, permissive-open, permite lecturas amplias de archivos. Los perfiles más estrictos son opt-in. | No. El agente recibe un directorio home nuevo y vacío. --ssh es opt-in. |
| Variables de entorno | Los comandos aislados heredan por defecto el entorno del proceso padre, credenciales incluidas. sandbox.credentials puede denegarlas o enmascararlas. | No documentado | No documentado | Una lista de permitidos mínima con variables de terminal, locale y toolchain, más la clave de API del propio harness que arrancas, copiada por defecto junto con su login; --no-agent-state lo impide. Añades otras por su nombre con --env. |
| Vía de escape que el modelo puede usar | El modelo puede reintentar un comando con dangerouslyDisableSandbox, que pasa por el flujo normal de permisos. allowUnsandboxedCommands: false lo desactiva. | Con la política on-request el agente pide salir del sandbox para editar fuera del workspace o para usar la red. | No documentado | Ninguna. Defines la política antes de que el agente arranque, y el archivo .ai-jail del proyecto puede endurecerla pero nunca abrirla. |
| Funciona con cualquier agente | Solo Claude Code | Solo Codex | Solo Gemini CLI | Cualquier comando, con un solo archivo de política para todos tus agentes. |
| Modelo de red | Un proxy con una lista de permitidos por dominio. Un dominio nuevo te pide confirmación, y cada comando sigue teniendo su propia aprobación. La documentación señala que el proxy confía en el hostname que envía el cliente, así que el domain fronting puede saltárselo. | Apagada por defecto en workspace-write. Un ajuste la activa, y un proxy opcional añade reglas de permitir y denegar por dominio. La documentación dice que el proxy no filtra las conexiones de los servidores MCP, la búsqueda web ni el navegador. | El perfil por defecto permite la red. Los perfiles más estrictos y los que usan proxy son opt-in. | Tres modos. El modo por defecto está cerrado salvo el host de la API de un agente conocido en ambas plataformas y, en Linux con las toolchains activadas, una lista fija de registries de paquetes que incluye github.com, así que git clone por HTTPS funciona; --no-network cierra ambas cosas. --allow-host añade hosts y sus subdominios, aplicado por el namespace de red en Linux o por una regla de endpoint de seatbelt en macOS, a través de un proxy que resuelve cada nombre una sola vez y marca la dirección que comprobó. --network abre todo. El filtro es solo TCP, no tiene reglas por ruta y nunca pregunta: un host fuera de la lista se deniega y --audit-log registra el intento. Un host permitido es de confianza por completo. En Linux, --forward-port reenvía un puerto del loopback del host hacia el sandbox, sin ninguna regla sobre lo que pasa. |
| Lo que los sandboxes integrados hacen mejor | ||||
| Aprobación de cada comando | Sí. Modos de permisos, un modo plan, un modelo clasificador y políticas gestionadas por la organización. | Sí. Políticas de aprobación, reglas por categoría y un agente revisor opcional. | No documentado | Ninguna. ai-jail nunca ve los comandos individuales y nunca pregunta. |
| Rutas protegidas dentro del proyecto | Sí. .git/hooks, .git/config, los ajustes de .claude, .mcp.json, los archivos rc de la shell y otros quedan en solo lectura. | Sí. .git, .agents y .codex bajo las raíces escribibles quedan en solo lectura. | No documentado | Ninguna integrada. Todo el proyecto es escribible, .git/ incluido, y el git del host confía en lo que encuentra ahí. Enmascaras o deniegas rutas tú mismo con --mask y deny_paths. Por qué importa .git/. |
| Ocultar secretos al agente sin dejar de usarlos | El enmascaramiento de credenciales puede inyectar el secreto real en el proxy. Requiere un ajuste experimental. | No documentado | No documentado | Sí, desde la 2.2, con --secret KEY=host. El sandbox guarda un marcador de posición y el proxy pone el valor real solo en las peticiones a ese único host. Cubre a los clientes que envían HTTP plano al proxy para ese host; los túneles HTTPS no se tocan. Un archivo enmascarado sigue siendo un archivo vacío. |
| Plataformas | macOS, Linux, WSL2. Ni Windows nativo ni WSL1. | macOS, Linux, WSL2 y Windows nativo. | Seatbelt en macOS, Docker o Podman, gVisor, LXC (experimental) y Windows nativo. | Linux y macOS. En Windows, solo WSL2. |
| Instalación | Viene con el agente. En Linux necesita bubblewrap y socat. | Viene con el agente. | Viene con el agente. Los backends de contenedores necesitan Docker o Podman. | Un binario aparte. En Linux necesita bubblewrap. |
Fuentes: Claude Code sandboxing, Claude Code sandbox environments, Codex approvals and security, Codex permissions, Codex Linux sandbox, Gemini CLI sandbox, Antigravity terminal sandbox, Antigravity permissions, nono security model, zerobox README.
Otros agentes, una tarjeta cada uno
Usa los dos
Un agente conocido no necesita que abras nada. Su login se monta por defecto y el proxy filtrado deja pasar el host de la API de su modelo, más los registros de paquetes en Linux. Añade hosts con --allow-host, o abre toda la red, cuando una herramienta necesite más.
cd ~/Projects/my-appai-jail claudeai-jail --network claudeai-jail conoce el host de la API de un agente conocido y lo permite por defecto, junto con los registries de paquetes en Linux. Una lista explícita con --allow-host se suma a ese valor por defecto, así que el host de la API sigue permitido. El login se monta por defecto; --no-agent-state da una ejecución sin sesión. Todos los flags están en Configurar.
↔ Desliza hacia un lado para ver el diagrama completo
Lo que siguen haciendo los controles del agente
Las solicitudes de permiso, las reglas de permitir y denegar y el modo plan son parte del programa del agente, así que funcionan dentro de la jaula igual que fuera. Atrapan el comando que tú no habrías aprobado.
Lo que ai-jail garantiza por debajo
El agente, sus servidores MCP y sus hooks nunca ven tu directorio home, tus claves ni los tokens de tu shell, apruebes lo que apruebes. La única excepción es el login y la clave de API del propio agente, montados por defecto para que arranque con la sesión iniciada. Lo que el agente puede leer, todavía puede enviarlo al host de su propia API y a cualquier host que hayas permitido, así que enmascara los secretos dentro del proyecto.
Docker, dev containers y máquinas virtuales
Estas también son buenas respuestas, y una máquina virtual es una más fuerte. Se diferencian en lo que tienes que construir y mantener al día.
| Qué te da | Qué cuesta | |
|---|---|---|
| Contenedor Docker | Su propio sistema de archivos, su lista de procesos y su red. El agente ve solo lo que montas. | Una imagen que construir y mantener, con tus toolchains instaladas por segunda vez. Si montas el socket de Docker, el contenedor equivale a root en el host. |
| Dev container | El mismo aislamiento que un contenedor, descrito en un archivo que tu editor entiende y tu equipo puede compartir. | El mismo mantenimiento de imágenes, más un editor o una herramienta que entienda el formato. |
| Máquina virtual | Su propio kernel. Es la frontera más fuerte de esta lista, y la correcta para código que crees hostil. | La opción más pesada: un sistema invitado que instalar, actualizar, al que darle memoria y al que copiar tu proyecto. |
| ai-jail | Un sandbox alrededor de un comando, con los compiladores y runtimes que ya tienes en tu máquina. No necesita imagen, daemon ni root. | Comparte tu kernel, así que un exploit del kernel o de un driver queda fuera de su frontera. Es más débil que una máquina virtual. |
La propia documentación de ai-jail lo llama una capa útil, no un reemplazo de una VM desechable. Lee el modelo de amenazas.
Para evaluadores: otros wrappers y plataformas
Dos wrappers de código abierto y una plataforma de runtime, cada uno con sus fuentes, para quien esté sopesando las alternativas.
Mostrar detalles de los wrappers y las plataformas
Plataformas de runtime para agentes
NVIDIA OpenShell es otra categoría: un gateway en ejecución que le da a cada agente su propio contenedor o MicroVM, con un motor de políticas delante de la red. ai-jail es un proceso que envuelve un comando y termina con él. Esto sigue la documentación de OpenShell al momento de escribir esto, cuando todavía no había llegado a su versión 1.0.
| OpenShell | ai-jail | |
|---|---|---|
| Qué ejecuta el sandbox | Un daemon gateway sobre Docker, Podman, Kubernetes o KVM. El agente vive en una imagen de contenedor empaquetada. | Nada más que el binario. El agente corre sobre tu proyecto con los compiladores y runtimes que ya tienes en tu máquina. |
| Red | Denegada por defecto. Las reglas coinciden por programa, host y puerto, con inspección opcional de métodos, rutas y herramientas MCP. Un endpoint denegado se puede aprobar desde el lado del operador. | Apagada, filtrada por host o abierta. El filtro es una valla de namespace y un proxy CONNECT; ve hosts y puertos, pero no el contenido, y un host permitido es de confianza por completo. Un puerto del loopback del host reenviado con --forward-port también es de confianza por completo, sin ninguna regla encima. |
| Credenciales | Las gestiona el gateway y las inyecta en cada petición; nunca se escriben en el disco del sandbox. | Ambientales. El login del propio harness se monta por defecto, en lectura y escritura, y lo que pasas con --env o --env-from-file es visible para todo lo que hay dentro; --no-agent-state da una ejecución sin sesión. Las credenciales de herramientas (--github, --aws, --kube, --gcloud, --docker-config) son montajes opt-in en solo lectura, y la documentación dice que solo lectura no impide usarlas. |
| Techo de aislamiento | Un driver de MicroVM da una frontera de máquina virtual real, y los sandboxes pueden detenerse, reiniciarse y conservar su workspace. | Comparte tu kernel y es de un solo uso por diseño. Para código hostil, su propia documentación dice que uses una VM desechable. |
| macOS | Corre dentro de la VM Linux de Docker Desktop. El host macOS queda fuera de la política. | Perfiles nativos de seatbelt generados en el host. |
| Telemetría y estabilidad | Telemetría anónima activada por defecto, con opt-out. El formato de políticas todavía cambia. | Sin telemetría. Cada versión nueva sigue leyendo las configs que escribieron las anteriores, y los tests lo garantizan. Dos auditorías de código independientes en septiembre de 2026, publicadas en el repositorio, llevaron a las correcciones de la 2.4.0. |
La comparación del repositorio de ai-jail, docs/openshell-comparison.md, está escrita en ambas direcciones y es de donde salió la lista de hosts permitidos.
Preguntas sobre usarlos juntos
¿Debo desactivar el sandbox y las solicitudes de mi agente?
Conserva las solicitudes y las reglas. Revisan comandos sueltos, cosa que ai-jail nunca hace. El sandbox del sistema operativo del agente es otro asunto en Linux: ai-jail bloquea las llamadas al sistema que necesita un sandbox de bubblewrap anidado, y su documentación no dice que la combinación funcione. Si el agente informa que su sandbox no está disponible dentro de la jaula, la jaula sigue ahí.
¿ai-jail es más seguro que Docker?
Son la misma clase de frontera. Ambos comparten tu kernel y ninguno es una máquina virtual. ai-jail arranca con todo cerrado y no necesita imagen, daemon ni root. Un contenedor monta lo que le digas, y un socket de Docker montado equivale a root en el host. Para código que crees hostil, usa una VM desechable.
¿En qué difiere la lista de hosts de la de los agentes?
Los proxies de los agentes son algo que el programa aislado tiene que elegir usar. En ai-jail la valla es el kernel: en Linux el sandbox conserva un namespace de red privado cuya única salida es el proxy, y en macOS una regla de seatbelt permite tráfico saliente solo hacia el puerto del proxy, así que un programa que ignora
http_proxy no llega a ningún lado. No cubre UDP, así que en Linux el DNS dentro del sandbox falla y en macOS el resolver del sistema no está vallado, y no inspecciona el contenido de una conexión, así que un host permitido es de confianza por completo. No se puede combinar con --network ni --browser.Solo uso Claude Code. ¿Igual necesito ai-jail?
Tienes tres opciones, al momento de escribir esto. El sandbox integrado cubre los comandos de shell.
@anthropic-ai/sandbox-runtime de Anthropic, una beta en research preview, envuelve el proceso entero. ai-jail también envuelve el proceso entero, arranca con tu directorio home y tus variables de entorno cerrados, y usa la misma política para cualquier otro agente que pruebes después. Mira la comparación de entornos de sandbox de Anthropic.Pon a tu agente tras las rejas
ai-jail es un único binario que no necesita daemon ni root. Añades una palabra delante del comando que ya usas.
brew tap akitaonrails/tap && brew install ai-jailai-jail claude