Claude Code sandbox: aislamiento integrado, Docker y nube

Un Claude Code sandbox limita a qué puede acceder el agente mientras trabaja. Puedes habilitar el sandbox de shell integrado con /sandbox, ejecutar Claude Code dentro de un contenedor de Docker o darle una máquina separada en la nube. La elección correcta depende de los archivos, procesos y credenciales que necesite la sesión.

Para el trabajo local, comienza con el sandbox integrado. Para un entorno de desarrollo repetible, usa un contenedor de desarrollo. Para trabajos remotos o varios agentes trabajando a la vez, un sandbox en la nube le da a cada tarea su propio espacio de trabajo.

Qué protege el sandbox integrado de Claude Code

Claude Code usa controles del sistema operativo para restringir su herramienta de shell y los procesos que esta inicia. Usa Seatbelt en macOS y bubblewrap en Linux. El sandbox puede limitar la escritura en archivos y restringir el acceso a la red mediante un proxy de dominios permitidos.

Ese alcance importa cuando agregas herramientas. Las herramientas de archivos integradas de Claude Code, los hooks y los servidores MCP locales se ejecutan fuera del sandbox de shell. Para contener todo el proceso del agente y sus herramientas locales, ejecútalos dentro de un contenedor, una máquina virtual o un entorno de ejecución de sandbox configurado por separado. Un servicio MCP remoto mantiene los permisos que le hayas dado. Consulta la documentación sobre el sandboxing de Claude Code.

Habilitar el modo sandbox de Claude Code

En macOS, Claude Code usa el soporte de sandbox existente del sistema. En Linux o WSL2, instala primero los paquetes necesarios. Para un sistema Debian o Ubuntu:

sudo apt-get install bubblewrap socat

Inicia Claude Code en tu proyecto e ingresa:

/sandbox

Elige el modo que se adapte a tu proceso de revisión. El modo de auto-permiso deja que los comandos de shell en el sandbox se ejecuten sin pedir aprobación. Los permisos regulares mantienen el flujo de aprobación habitual mientras el sandbox de shell sigue activo. Windows nativo necesita WSL2 para este sandbox. La guía de configuración enumera los requisitos y restricciones de la plataforma.

Para una sesión que deba mantener los comandos de shell dentro del sandbox, inicia Claude Code con:

claude --settings '{"sandbox":{"enabled":true,"allowUnsandboxedCommands":false,"failIfUnavailable":true}}'

allowUnsandboxedCommands: false desactiva la vía de escape para los comandos que de otro modo se ejecutarían fuera del sandbox. failIfUnavailable: true hace que el inicio falle si falta el soporte de sandbox. Revisa también cualquier comando excluido en tu configuración. Las lecturas de archivos siguen siendo amplias por defecto; agrega restricciones de lectura si la sesión no debe ver archivos en otras partes de tu máquina.

Comprobar el límite antes de una ejecución larga

Pídele a Claude que ejecute estos comandos a través de su herramienta de shell:

touch ~/sandbox-probe
curl --noproxy '*' https://example.com

Ejecuta la prueba desde una carpeta de proyecto debajo de tu directorio de inicio. Con las restricciones previstas, el primer comando debería fallar porque escribe fuera de ese proyecto. El segundo prueba si un comando puede eludir el proxy de red. Debería fallar cuando el acceso directo a la red está bloqueado. Una solicitud permitida a través del proxy aún puede tener éxito.

Haz que Claude ejecute las comprobaciones. Escribir un comando manualmente en una terminal separada no prueba el sandbox de shell del agente.

Modo sandbox, modo automático y omisión de permisos

Los modos de permisos deciden cuándo Claude pide aprobación. El sandboxing controla lo que el sistema operativo le permite hacer a un comando.

El modo automático de Claude Code usa un clasificador para decidir qué acciones pueden continuar. Eso difiere del modo de auto-permiso del sandbox de shell. Revisa los modos de permisos antes de cambiar cualquier configuración.

--dangerously-skip-permissions omite las solicitudes de permisos de rutina. No crea un contenedor, no restringe el acceso a archivos ni establece una política de red. Las reglas de denegación explícitas y algunas comprobaciones aún pueden aplicarse. Si lo usas para trabajo desatendido, configura y prueba primero el aislamiento circundante. Nuestra guía sobre dangerously-skip-permissions cubre ese flujo de trabajo.

Ejecutar Claude Code en Docker

Un contenedor de desarrollo le da al equipo el mismo entorno inicial y mantiene los procesos del agente dentro de un contenedor. Instala Docker y usa un editor con soporte para Dev Containers. Agrega este archivo en .devcontainer/devcontainer.json en tu proyecto:

{
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
  "remoteUser": "vscode",
  "features": {
    "ghcr.io/devcontainers/features/node:1": {
      "version": "22"
    },
    "ghcr.io/anthropics/devcontainer-features/claude-code:1.0": {}
  }
}

Abre el proyecto en el contenedor, deja que se compile, luego ejecuta claude en su terminal e inicia sesión. Esta configuración instala Claude Code y Node.js 22. Agrega cualquier otro entorno de ejecución y dependencias que necesite tu proyecto. La versión de la característica no fija la versión de Claude Code que instala.

Probamos una compilación limpia de esta configuración exacta. Luego, Claude arregló una prueba de Node.js que fallaba intencionalmente, y una ejecución separada de node --test pasó. Incluir explícitamente la característica de Node.js es importante: nuestra primera compilación limpia solo con la característica de Claude Code falló al instalar Node.js y npm.

Revisa los montajes antes de entregarle trabajo al agente. Un montaje de proyecto con permisos de escritura le permite cambiar los archivos en tu host. Evita montar tu directorio de inicio, credenciales de producción o el socket de Docker del host. Esta configuración mínima no agrega una lista de permitidos de red. Consulta la guía de contenedores de desarrollo de Anthropic y la documentación de seguridad de Docker para conocer los controles que necesita tu configuración.

Los contenedores de Docker y Docker Sandboxes difieren

Docker también ofrece un producto llamado Docker Sandboxes. Su arquitectura documentada usa microVMs y un demonio de Docker aislado. Un contenedor de desarrollo ordinario no obtiene esas propiedades solo por usar Docker. La sincronización del espacio de trabajo también depende del modo de Docker Sandboxes que elijas. Lee su arquitectura y modelo de seguridad antes de tratar ambas configuraciones como equivalentes.

Cuándo ayuda un sandbox en la nube

Un espacio de trabajo remoto ayuda cuando la tarea debe seguir ejecutándose después de que tu computadora portátil se desconecta, cuando los agentes necesitan árboles de trabajo separados o cuando tu aplicación crea un espacio de trabajo para cada usuario. Puedes copiar un repositorio, ejecutar el agente, inspeccionar sus cambios y recuperar los archivos que deseas conservar.

Lizard Sandboxes ejecuta cada sandbox como una microVM de Firecracker con su propio kernel.

Una máquina separada mantiene el trabajo lejos de los archivos que no has compartido desde tu computadora portátil. Las credenciales y los archivos que sí pones dentro de esa máquina permanecen disponibles para el código que se ejecuta allí. Ajusta su alcance para que coincida con la tarea.

Ejecutar Claude Code en Lizard Sandboxes

Instala Lizard CLI, inicia sesión y elige un proyecto. Necesitas una clave API de Anthropic o un token de suscripción de Claude compatible para las llamadas al modelo.

Para registrar una clave API de Anthropic, ejecuta:

lizard agents add anthropic

Para una suscripción de Claude, crea un token y regístralo con Lizard CLI:

claude setup-token
lizard agents add claude

Pega la credencial en el aviso. Mantenla fuera de tu repositorio y del historial de comandos. Los comandos a continuación asumen que el registro tuvo éxito; nuestra prueba en vivo usó un token de suscripción de Claude existente.

Crear el espacio de trabajo

Reemplaza YOUR_PROJECT_ID con el ID de tu proyecto:

lizard sandbox create \
  --project YOUR_PROJECT_ID \
  --template claude \
  --size small \
  --timeout 3600000 \
  --json

Establece SB con el ID del sandbox de esa respuesta:

SB=YOUR_SANDBOX_ID

El tiempo de espera aquí le da al espacio de trabajo una vida útil de una hora. El valor predeterminado es de cinco minutos, y la ejecución de comandos no lo extiende. Establece suficiente tiempo para el trabajo y guarda tu progreso antes de que expire. Consulta la referencia de la CLI para los comandos del ciclo de vida.

Copiar un repositorio confirmado sin un token de GitHub

Desde el repositorio local, crea un paquete de Git y súbelo:

BUNDLE_DIR=$(mktemp -d)
git bundle create "$BUNDLE_DIR/app.bundle" HEAD
lizard sandbox files put \
  "$SB" "$BUNDLE_DIR/app.bundle" /workspace/app.bundle
lizard sandbox exec "$SB" -- \
  git clone /workspace/app.bundle /workspace/app

El paquete incluye el historial confirmado accesible desde HEAD. Excluye los archivos no confirmados y no rastreados, pero cualquier secreto confirmado en ese historial viaja con él. Revisa el repositorio antes de transferirlo. Clonar este paquete puede dejar el checkout en un HEAD separado; aún puedes inspeccionar las ediciones del agente y exportar los archivos modificados.

Darle a Claude una tarea pequeña

lizard sandbox prompt "$SB" \
  --agent claude \
  --cwd /workspace/app \
  "Run the tests. Fix one failing test with the smallest reasonable change. Report what changed and which tests passed."

Mantén --agent claude: omitir la opción del agente puede seleccionar el agente predeterminado en su lugar. El ejecutor de Lizard usa la omisión de permisos dentro del espacio de trabajo remoto para que la tarea pueda ejecutarse sin avisos interactivos. Por lo tanto, el límite del espacio de trabajo y las credenciales que proporciones deben coincidir con la tarea. El código en su interior puede leer la credencial del modelo disponible para el proceso.

En nuestra prueba, una función de Python restaba dos números cuando su prueba esperaba su suma. Claude cambió esa función, y una ejecución de prueba independiente pasó después.

Revisar y recuperar el resultado

lizard sandbox exec "$SB" -- \
  git -C /workspace/app status --short
lizard sandbox exec "$SB" -- \
  git -C /workspace/app diff
lizard sandbox files get \
  "$SB" /workspace/app/path/to/changed-file ./changed-file.review

Reemplaza path/to/changed-file con el archivo que deseas descargar. Ejecuta las pruebas del proyecto tú mismo antes de fusionar los cambios. Comprobamos el diff remoto, volvimos a ejecutar la prueba y descargamos el archivo corregido; su contenido coincidía con el resultado remoto.

Cuando hayas guardado el resultado, pausa el espacio de trabajo:

lizard sandbox pause "$SB"

Espera hasta que su estado sea paused. Una pausa exitosa detiene la facturación de computación. Exporta el trabajo antes de eliminar un sandbox y usa Persistent Volumes cuando los datos deban sobrevivir a la eliminación del sandbox. Los datos almacenados aún pueden generar cargos.

Cuánto cuesta el espacio de trabajo en la nube

Las tarifas de computación publicadas de Lizard el 18 de octubre de 2026 eran:

Con la tarifa Pequeño, 100 horas de sandbox consumen $1.62 de uso de computación. Las llamadas al modelo, el almacenamiento y cualquier otro recurso facturado son independientes.

Lizard Pro cuesta $19 al mes, impuestos incluidos, e incluye $19 de uso. El uso por encima de esa cantidad es pay as you go. Las cuentas nuevas obtienen una prueba de siete días con $5 de uso; se requiere una tarjeta. Los cargos de la suscripción de Claude o la API de Anthropic son independientes de los cargos de Lizard. Revisa los precios actuales antes de dimensionar un trabajo.

Un sandbox en ejecución sigue consumiendo computación mientras está inactivo. Páusalo correctamente cuando termines; el almacenamiento de Persistent Volumes puede seguir siendo facturable mientras la computación está pausada.

Problemas comunes de configuración

Qué probamos

El 18 de octubre de 2026, ejecutamos Claude Code 2.1.286 en macOS y en un nuevo sandbox Small con Firecracker a través de Lizard CLI 4.0.58. La comprobación de macOS permitió una escritura en el espacio de trabajo y bloqueó tanto una escritura fuera del proyecto como una solicitud de red directa que eludía el proxy.

La prueba en la nube cubrió la subida del paquete de Git, la clonación, la corrección de Claude de una prueba de Python que fallaba, una repetición de prueba independiente, la revisión del diff, la descarga de archivos y la pausa. Confirmamos que el sandbox alcanzó paused.

La prueba de Docker usó Docker Engine 28.1.1 en ARM64, Dev Containers CLI 0.89.0, Node.js 22.23.3 y Claude Code 2.1.302. La configuración corregida se compiló desde un contenedor limpio, y Claude arregló una prueba de Node.js que fallaba y que pasó en una repetición separada. También verificamos el comando de instalación de paquetes de Linux.

La autenticación usó un token de suscripción de Claude existente. No repetimos la inscripción inicial de OAuth ni probamos el aislamiento nativo de Windows/WSL. Estas comprobaciones cubren los comandos y resultados descritos aquí; no son una auditoría de seguridad.

Qué configuración deberías elegir

Comienza con el sandbox integrado de Claude Code para tareas de shell locales donde puedas definir las rutas y dominios necesarios. Usa un contenedor de desarrollo cuando tu equipo necesite una configuración de desarrollo compartida. Elige un espacio de trabajo en la nube cuando las tareas necesiten computación remota o entornos separados para agentes simultáneos.

Para una primera ejecución en Lizard, copia un repositorio pequeño, pídele a Claude que arregle una prueba que falla, revisa el diff y pausa el espacio de trabajo. La guía de Claude Code tiene los pasos de configuración actuales.