Sandbox para agentes de código: aísla Claude Code y Codex 2026

TL;DR: Un sandbox para agentes de código es un entorno de ejecución aislado (microVM, contenedor o sandbox del sistema operativo) que limita qué archivos, red y procesos puede tocar tu agente. En 2026, con OpenAI lanzando sandbox nativo para Codex en Windows y Claude Code permitiendo restringir directorios y permisos, dejar que un agente toque tu repo sin aislamiento ya no es aceptable. Esta guía explica los niveles de aislamiento, cuándo aplicar cada uno y cómo configurarlos sin romper tu flujo.

El problema: agentes con autonomía, máquina sin límites

Los agentes de código pasaron de "asistentes que sugieren" a "procesos que ejecutan". Claude Code escribe ficheros, lanza comandos, instala dependencias. Codex hace lo mismo desde Windows o macOS. Y la mayoría corre con el mismo usuario que tu sesión: acceso completo a tu home, tus llaves SSH, tu .env, tu historial de bash.

El patrón clásico que me he encontrado en proyectos reales es este: instalas un agente, pruebas con --dangerously-skip-permissions "para no pelearme con los prompts", y a las dos semanas tu agente está leyendo carpetas que no debería tocar. No es paranoia: es el modelo de amenaza que estás aceptando por defecto.

Las dos señales del mercado que cambian la conversación en mayo de 2026:

OpenAI publicó el sandbox nativo de Codex para Windows con restricted tokens, ACLs de filesystem y usuarios sandbox dedicados. Y lo hizo open source.
Docker Sandboxes ya empaqueta agentes de código dentro de microVMs con su propio daemon Docker aislado del host.
Claude Code permite restringir directorios permitidos y configurar redes desde su modo sandbox.

El mensaje es claro: si delegas tareas largas o tocas código sensible, el aislamiento ya es requisito, no extra.

¿Qué es un sandbox para agentes de código?

Un sandbox para agentes de código es un entorno de ejecución que aplica límites explícitos sobre filesystem, red, procesos y credenciales para que el agente solo pueda operar dentro de un perímetro definido. La frontera puede estar en el sistema operativo (procesos con tokens restringidos), en un contenedor (Docker, gVisor) o en una máquina virtual ligera (microVM como Firecracker).

Tres niveles a memorizar:

Nivel	Tecnología	Aislamiento	Cuándo usarlo
Ligero	Sandbox nativo (Claude Code, Codex Windows)	Tokens restringidos, ACLs, directorios permitidos	Tareas locales en tu repo de trabajo
Medio	Contenedor (Docker, devcontainers)	Filesystem propio, red controlada	Dependencias raras o repos no confiables
Fuerte	microVM (Firecracker, Docker Sandboxes)	Kernel propio, hardware boundary	Código no auditado, agentes con shell libre

Una regla simple: cuanto más autónomo es el agente, más fuerte debería ser el aislamiento.

Por qué ahora: el patrón se está estandarizando

Hasta hace poco, hablar de sandbox para un agente local sonaba a sobre-ingeniería. En 2026 ha cambiado por tres motivos concretos:

Tareas largas: los agentes ya operan minutos u horas sin supervisión. Un descuido se acumula.
Tool use real: con MCP, los agentes invocan APIs externas, escriben archivos y ejecutan binarios. La superficie crece.
Multi-agente: si corres dos agentes en paralelo, necesitas que cada uno tenga su propio worktree y workspace.

OpenAI, al abrir el código del sandbox de Codex en Windows, ha dado un empujón claro: "esto es lo mínimo que un agente debería tener". Y el resto del ecosistema está copiando el patrón.

Implementación paso a paso

1. Restringe directorios en Claude Code

El nivel más barato y útil. En tu settings.json defines qué rutas puede tocar el agente:

{
  "sandbox": {
    "enabled": true,
    "allowedDirectories": ["/home/sergio/proyectos/mi-app"],
    "networkAccess": "restricted"
  }
}

Con esto Claude Code no puede leer tu home, tus claves SSH ni otros proyectos. Si necesitas que toque rutas específicas, añádelas explícitamente.

2. Usa worktrees aislados por tarea

Antes de delegar una tarea larga, crea un worktree dedicado. Así el agente no toca tu rama de trabajo y puedes descartar todo si sale mal:

# Crea un worktree aislado para la tarea del agente
git worktree add ../mi-app-agent-task feature/refactor-auth
cd ../mi-app-agent-task
claude  # arranca el agente solo aquí

Es un patrón compatible con cualquier nivel de sandbox y resuelve el 80% de los problemas de "el agente me tocó algo que no debía".

3. Sube a contenedor cuando no confíes en el código

Si trabajas con un repo cliente o con dependencias que no has auditado, mete el agente en un devcontainer. Docker provee el aislamiento, el agente cree que tiene libertad y tu host se mantiene limpio.

{
  "name": "claude-sandbox",
  "image": "mcr.microsoft.com/devcontainers/python:3.12",
  "mounts": ["source=${localWorkspaceFolder},target=/workspace,type=bind"],
  "runArgs": ["--network=bridge", "--cap-drop=ALL"]
}

La clave: --cap-drop=ALL y red controlada. El agente puede hacer lo que quiera dentro, pero no escapa.

4. microVM para tareas críticas

Si el agente va a ejecutar código no auditado o ataca un repo público, usa Docker Sandboxes o un proveedor cloud como E2B. Cada sesión arranca en una microVM con su propio kernel, su propio daemon Docker y red proxyficada. Es la única defensa real contra escapes de contenedor.

En Producción

Lo que aprendes cuando dejas de ser un tutorial y empiezas a delegar trabajo real:

Coste: microVMs cuestan más en tiempo de arranque (segundos vs milisegundos) y en RAM. Para tareas cortas locales no compensa.
Red: bloquear todo es atractivo, pero los agentes necesitan npm, pip, GitHub. Permite hosts concretos, no "todo o nada".
Credenciales: nunca montes tu ~/.ssh ni tu .env raíz dentro del sandbox. Inyecta solo lo que la tarea necesita, por variable de entorno temporal.
Logs y rollback: graba qué comandos lanza el agente. Sin auditoría, el sandbox solo limita el daño, no te dice qué pasó.
Concurrencia: si corres dos agentes en paralelo, dales sandboxes separados. Compartir filesystem es el camino más rápido a una pisada.

Si te interesa profundizar en cómo organizar permisos y rollback en estos flujos, escribí sobre guardrails en Claude Code con Security beta y cómo definirlos sin romper la productividad.

Errores comunes y depuración

Error: el agente falla con "permission denied" al instalar paquetes → Causa: sandbox bloquea escritura en /usr → Solución: usa un virtualenv dentro del directorio permitido.
Error: Docker no funciona dentro del sandbox de Claude Code → Causa: el sandbox local y Docker son incompatibles por diseño → Solución: usa un devcontainer en lugar del sandbox nativo cuando necesites Docker.
Error: el agente pide aprobación constantemente → Causa: permisos demasiado estrictos → Solución: añade hooks pre-aprobados para comandos seguros en lugar de bajar el nivel global de aislamiento. Cubrí el patrón en hooks en Claude Code para checks automáticos.
Error: --dangerously-skip-permissions sin sandbox → Causa: es la combinación que más daño hace, da control total → Solución: nunca uses esa bandera fuera de un contenedor o microVM.

Aplicación práctica: un flujo real con Claude Code

El setup que uso para tareas medianas, donde el agente puede tirar varias horas:

Worktree dedicado con la rama de la tarea.
Sandbox nativo de Claude Code apuntando solo a ese worktree.
Red restringida: permito github.com, npmjs.com, pypi.org y poco más.
.env con secretos falsos durante la sesión; los reales solo cuando el merge se cierra.
Hooks que validan que el agente no toque carpetas fuera del worktree.

Para entender por qué este aislamiento conecta con otras decisiones del flujo (memoria, contexto, secrets), el secret scanning en GitHub MCP resuelve el lado de "qué hago si el agente se trae una clave por accidente". Y si tu agente toca infraestructura, las reglas de separación de responsabilidades en arquitectura aplican igual: separar capas, separar permisos.

Preguntas frecuentes

¿Necesito un sandbox si solo uso Claude Code en proyectos personales?

Sí, al menos el nivel ligero. Aunque el riesgo de fuga sea bajo, restringir directorios evita que un comando mal interpretado borre archivos en otra carpeta del home. El coste de activarlo es un campo en settings.json.

¿Cuál es la diferencia entre devcontainer y sandbox nativo?

El sandbox nativo limita procesos y rutas en tu sistema operativo sin virtualización. El devcontainer es un contenedor Docker completo: aísla filesystem, red y dependencias, pero arranca más lento y consume más recursos. Devcontainer gana cuando trabajas con código no confiable; sandbox nativo gana en velocidad para tu trabajo diario.

¿microVMs como Firecracker rompen el flujo del agente?

Casi nada, si los integras bien. La latencia extra es de segundos al iniciar, no en cada turno. Para tareas cortas no compensa; para sesiones largas o multi-agente sí, porque el aislamiento entre sesiones es real.

Conclusión

Hemos visto que un sandbox para agentes de código no es paranoia, sino el coste lógico de delegar más autonomía. La pieza simple es restringir directorios y red en Claude Code o Codex. La pieza fuerte es subir a microVM cuando el agente toca código que no controlas. Lo importante es elegir el nivel adecuado al riesgo de cada tarea, no aplicar el más alto siempre.

Si vas a delegar más trabajo a tu agente en los próximos meses, empieza por restringir directorios hoy y graba qué comandos lanza tu agente. El siguiente salto natural es combinar sandbox con políticas de memoria persistente, donde decides qué del trabajo aislado promocionas al contexto duradero.

¿Cómo tienes configurado el aislamiento de tu agente? Cuéntamelo en los comentarios o en Twitter @sergiomarquezp_.