Docker Sandboxes para ejecutar agentes de programación

Docker Sandboxes ejecuta un agente de programación como Claude Code, Codex, Copilot o Cursor dentro de una microVM local. La microVM tiene su propio kernel y su propio motor de Docker, solo comparte con el host el directorio de tu proyecto y ejecutarla en local es gratis.

Si alguna vez has aprobado cien solicitudes de ls y npm test en una sola tarde, conoces la tentación del flag para omitir permisos. Probablemente también conoces la preocupación por lo que el agente podría hacerle a tu portátil una vez activado ese flag.

Este artículo explica qué aísla el sandbox, cómo configurarlo desde la instalación hasta la primera sesión, cómo recuperar los cambios del agente, cómo se compara con otras opciones y cuánto cuesta. La herramienta aún no ha llegado a la versión 1.0 y sigue cambiando rápidamente.

Por qué la autonomía total en tu portátil es arriesgada

Un agente de programación en modo de autonomía total ejecuta comandos de shell, instala paquetes y edita archivos sin preguntar, y hace todo esto con tu cuenta de usuario. Eso significa que tu directorio personal, tus claves SSH, tus credenciales de la nube y tus servicios locales están a su alcance. Un solo rm -rf o git reset --hard equivocado puede borrar el trabajo sin confirmar.

Las solicitudes de aprobación son la defensa habitual, pero anulan el propósito de un agente. Las tareas largas se detienen en cada comando y, tras la vigésima solicitud, la mayoría de la gente aprueba sin leer. Una mejor solución es trasladar al agente a un lugar donde no pueda causar mucho daño, en lugar de confiar más en él. Los argumentos generales a favor de aislar a los agentes se tratan en cómo ejecutar agentes de programación en modo YOLO de forma segura. Este artículo se centra en una herramienta concreta.

Por qué Docker Sandboxes usa una microVM y no un contenedor

Un contenedor de Docker normal comparte el kernel del host. Cualquier proceso que pueda acceder al socket de Docker puede iniciar un contenedor privilegiado que monte tu sistema de archivos. La propia documentación de Docker sobre la superficie de ataque del daemon advierte que el daemon se ejecuta como root y que solo usuarios de confianza deberían controlarlo. Los agentes a menudo necesitan Docker, así que el atajo obvio de montar /var/run/docker.sock les entrega la máquina entera.

La documentación de Docker sobre las capas de aislamiento indica que cada sandbox es una microVM con su propio kernel de Linux y su propio Docker Engine. El agente puede ejecutar docker build y docker run dentro del sandbox sin la configuración privilegiada que requiere Docker-in-Docker, y el daemon de tu host nunca interviene.

Configurar un Docker Sandbox de principio a fin

Instala la CLI sbx, inicia sesión en Docker, proporciona al agente las credenciales del modelo y ejecuta sbx run desde el directorio de tu proyecto. El tutorial oficial señala que tu host no necesita Docker Desktop ni Docker Engine.

Instala con el comando correspondiente a tu sistema operativo:

# macOS
brew trust docker/tap && brew install docker/tap/sbx

# Windows
winget install Docker.sbx

# Ubuntu: add Docker's apt repo, install, then grant KVM access
curl -fsSL https://get.docker.com | sudo REPO_ONLY=1 sh
sudo apt-get install docker-sbx
sudo usermod -aG kvm $USER
newgrp kvm

Linux necesita KVM, y tu usuario debe pertenecer al grupo kvm. Docker prueba y da soporte a sbx en Ubuntu. Para otras distribuciones, el repositorio sbx-releases ofrece archivos de las versiones, pero Docker no garantiza que esas distribuciones funcionen. Consulta la página de instalación para conocer los requisitos de cada plataforma.

A continuación, inicia una sesión de Claude Code:

sbx login
sbx secret set anthropic        # skip if you use a Claude subscription
cd ~/my-project
sbx run --name my-project claude

• Clave de API: sbx secret set anthropic guarda la clave en tu host. El proxy del sandbox la añade a las solicitudes de API del agente, de modo que el agente nunca maneja la clave en bruto. Para Codex, usa sbx secret set openai. Si ya exportaste la clave en tu shell, sbx secret import --dry-run muestra las claves que sbx puede ver, y sbx secret import las guarda después de que confirmes cada una.
• Suscripción: no necesitas ningún secreto. Con Claude, escribe /login después de que Claude Code se inicie en el sandbox. Con Codex, sbx ejecuta primero el inicio de sesión de OpenAI en tu host y solo después crea el sandbox.

En la primera ejecución, sbx te pide que elijas una política de red predeterminada. Después, el agente se inicia en su modo de autonomía total, por lo que Claude Code no pedirá permiso y no tienes que pasar ningún flag. Para otro agente, sustituye claude por codex, copilot, cursor o gemini.

La carpeta de tu proyecto es la única parte de tu máquina en la que el agente puede escribir, y puede borrar cualquier cosa que haya en ella. Haz commit o push antes de empezar.

¿Cómo se recupera el trabajo del agente?

En el modo predeterminado, las modificaciones del agente de un Docker Sandbox aparecen de inmediato en tu árbol de trabajo del host. Revísalas como lo harías normalmente:

git diff

Las guías más antiguas, incluido el repositorio de ejemplo del quickstart de Docker, muestran un flag --branch que situaba al agente en un worktree del host bajo .sbx/. Ese flag se eliminó en sbx v0.31.0 en favor del modo clone. Si lo usas ahora, devuelve un error que te indica que uses --clone.

El modo clone mantiene al agente fuera de tu árbol de trabajo. Como explica la documentación sobre el flujo de trabajo con Git, sbx crea un clon privado de Git dentro del sandbox y el agente trabaja sobre esa copia. Nada cambia en tu host hasta que hagas fetch de la rama del agente o el agente haga push a un remoto. Solo puedes elegir el modo clone al crear un sandbox, así que pasa --clone la primera vez que lo ejecutes. No puedes cambiar un sandbox existente a este modo más adelante.

Preguntas prácticas

¿Qué política de red debería elegir?

Docker Sandboxes ofrece tres políticas de red locales:

• Open permite todo el tráfico.
• Balanced deniega el tráfico de forma predeterminada, pero permite los servicios de desarrollo habituales.
• Locked Down bloquea todo lo que no permitas explícitamente.

Elige Balanced para la mayor parte del trabajo de frontend. Cubre los registros de paquetes, las plataformas de alojamiento de código y las API de los proveedores de IA. Si tu agente necesita un sitio que no está en la lista, como un sitio de documentación, ejecuta sbx policy check network <domain> para ver si está bloqueado y luego permítelo con sbx policy allow network <domain>. Ejecuta sbx policy ls para ver tus reglas y elimina una con sbx policy rm. Los kits de agentes integrados también pueden añadir sus propias reglas de permiso para cada sandbox, incluso con Locked Down.

¿Se conserva el estado?

Sí. Las herramientas que instala el agente y cualquier cambio que haga en el sistema operativo permanecen en el sandbox hasta que lo elimines. Ejecutar sbx rm my-project borra el entorno y los secretos asociados a ese sandbox. Tus secretos globales y la carpeta de tu proyecto no se tocan.

¿Cómo me vuelvo a conectar?

Para volver a conectarte a un Docker Sandbox existente, ejecuta sbx run --name my-project. No necesitas repetir el nombre del agente, porque se lee del sandbox existente. Ejecutar sbx sin argumentos abre un panel interactivo.

Docker Sandboxes frente a contenedores, devcontainers y VM remotas

Cada alternativa renuncia al menos a una de estas tres cosas: aislamiento del kernel, acceso seguro a Docker o una política de salida integrada.

Si lo que realmente necesitas es controlar qué herramientas puede invocar un agente, en lugar de aislar su entorno, consulta Docker MCP para agentes de IA.

Limitaciones y coste de Docker Sandboxes

Ejecutar sandboxes locales es gratis. Según las notas de la versión v0.45.0, los sandboxes en la nube son experimentales y requieren una suscripción activa a Docker Agentic Platform. La inferencia del modelo la pagas con tu propia clave o suscripción. Necesitas una cuenta de Docker para ejecutar sbx login. El producto es reciente, así que los precios y los flags pueden cambiar.

• El directorio del proyecto es totalmente escribible, por lo que el trabajo sin confirmar no está protegido.
• Todo lo que el agente envíe con push, o mande a un dominio permitido, sale del sandbox.
• Configura los recursos con --memory y --cpus. En local, la memoria predeterminada es la mitad de la RAM de tu host, hasta un máximo de 32 GiB. El valor predeterminado documentado de 2 CPU y 4 GiB se aplica a los sandboxes en la nube.
• La firma de commits con SSH funciona mediante el reenvío del agente SSH, que está activado de forma predeterminada cuando SSH_AUTH_SOCK está definido en tu host. Aun así, tienes que indicarle a Git dentro del sandbox que firme con la clave reenviada.
• Andrew Lock informó en abril de 2026 de que ejecutar en un sandbox ralentizaba considerablemente incluso los proyectos sencillos.

Conclusión

Docker Sandboxes proporciona a un agente de programación su propio kernel, su propio motor de Docker y una red controlada por políticas, y la única parte de tu máquina a la que puede acceder es la carpeta de tu proyecto. Para empezar, confirma tu trabajo con commit, instala sbx, elige Balanced y ejecuta sbx run --name my-project claude en un repositorio que puedas permitirte perder. Pasa al modo clone cuando quieras que los cambios del agente se mantengan fuera de tu árbol de trabajo hasta que los revises.

Preguntas frecuentes

¿Cómo abro un servidor de desarrollo que el agente inicia dentro de un Docker Sandbox?

Publica su puerto con sbx ports. Ejecutar sbx ports my-project --publish 3000:8080 asigna el puerto 3000 del host al puerto 8080 del sandbox, y --publish 8080 por sí solo elige un puerto efímero del host. Tu navegador no puede acceder a los servicios dentro del sandbox hasta que hagas esto. Además, el servidor de desarrollo debe enlazarse a 0.0.0.0 en lugar de a 127.0.0.1, por lo que muchos frameworks necesitan el flag --host 0.0.0.0.

¿Puede el agente leer otros directorios sin poder modificarlos?

Sí. Añade rutas adicionales después del espacio de trabajo principal y pon :ro al final de cada una para que sea de solo lectura, por ejemplo sbx run claude ~/project-a ~/shared-libs:ro ~/docs:ro. El agente se inicia en la primera ruta. Cada espacio de trabajo aparece dentro del sandbox en la misma ruta absoluta que tiene en tu host. Los espacios de trabajo adicionales se montan directamente desde el host, incluso cuando el espacio de trabajo principal usa el modo clone.

¿Cómo saco los commits de un sandbox en modo clone?

Haz fetch desde el remoto de Git que sbx añade a tu repositorio del host, cuyo nombre es sandbox- seguido del nombre del sandbox. Después, haz diff o merge como con cualquier otro remoto. El servidor de Git del clon reside dentro del sandbox, por lo que git fetch falla mientras el sandbox está detenido. sbx rm también elimina ese remoto, así que haz fetch o push de todo lo que quieras conservar antes de eliminar el sandbox.