Preguntas frecuentes

¿Por qué necesito iniciar sesión?

Docker Sandboxes se basa en la idea de que tú y tus agentes son un equipo. Iniciar sesión le da a cada sandbox una identidad verificada, lo que le permite a Docker:

• Vincular los sandboxes a una persona real. La gobernanza es importante cuando los agentes pueden compilar contenedores, instalar paquetes y enviar código. Tu identidad de Docker es el ancla.
• Habilitar características de equipo. Las funciones a nivel de equipo, como la gobernanza de la organización, los entornos compartidos y los registros de auditoría, necesitan el concepto de "quién", y añadir eso más tarde sería peor para todos.
• Autenticarse contra la infraestructura de Docker. Los sandboxes descargan imágenes, ejecutan demonios y se comunican con los servicios de Docker. Una cuenta de Docker hace que eso sea transparente.

El correo electrónico de tu cuenta de Docker solo se utiliza para la autenticación, no para marketing.

¿Puedo aplicar políticas de sandbox en toda mi organización?

Sí. Los administradores pueden gestionar de forma centralizada las políticas de red y del sistema de archivos desde la Consola de Administración de Docker. Las reglas definidas allí se aplican a cada sandbox de la organización y tienen prioridad sobre las reglas locales configuradas con sbx policy. Los administradores tienen la opción de delegar ciertos tipos de reglas al control local para que los desarrolladores puedan añadir reglas de permiso adicionales.

Consulta Gobernanza de la organización. Esta característica requiere una suscripción de pago independiente: ponte en contacto con el equipo de ventas de Docker para comenzar.

¿Recopila telemetría la CLI?

La CLI sbx recopila datos de uso básicos sobre las invocaciones de la CLI:

• Qué comando ejecutaste
• Si tuvo éxito o falló
• Cuánto tiempo tardó
• Si has iniciado sesión, se incluye tu nombre de usuario de Docker

Docker Sandboxes no supervisa las sesiones, no lee tus prompts ni accede a tu código. Tu código permanece en el sandbox y en tu host.

Para desactivar todos los análisis, configura la variable de entorno SBX_NO_TELEMETRY:

$ export SBX_NO_TELEMETRY=1

¿Cómo configuro variables de entorno personalizadas dentro de un sandbox?

El comando sbx secret solo admite un conjunto fijo de servicios (Anthropic, OpenAI, GitHub y otros). Si tu agente necesita una variable de entorno que no está vinculada a un servicio compatible, como BRAVE_API_KEY o un token interno personalizado, escríbela en /etc/sandbox-persistent.sh dentro del sandbox. Este archivo se carga (source) en cada inicio de sesión de shell, por lo que la variable persiste a lo largo de las sesiones del agente durante la vida útil del sandbox.

Usa sbx exec para añadir la exportación:

$ sbx exec -d <nombre-sandbox> bash -c "echo 'export BRAVE_API_KEY=tu_clave' >> /etc/sandbox-persistent.sh"

El contenedor bash -c es necesario para que la redirección >> se ejecute dentro del sandbox en lugar de en tu host.

Note

A diferencia de sbx secret, que inyecta credenciales a través de un proxy en el host sin exponerlas al agente, este enfoque almacena el valor dentro del sandbox. El proceso del agente puede leerlo directamente. Usa esto únicamente para credenciales donde la inyección basada en proxy no esté disponible.

Las variables en /etc/sandbox-persistent.sh se cargan automáticamente cuando se ejecuta bash dentro del sandbox, incluyendo las sesiones interactivas y los agentes iniciados con sbx run. Si ejecutas un comando directamente con sbx exec <nombre> <comando>, el comando se ejecuta sin shell, por lo que el archivo de entorno persistente no se carga. Envuelve el comando en bash -c para cargar el entorno:

$ sbx exec <nombre-sandbox> bash -c "tu-comando"

Para verificar que la variable está configurada, abre un shell en el sandbox:

$ sbx exec -it <nombre-sandbox> bash
$ echo $BRAVE_API_KEY

¿Por qué los agentes se ejecutan sin avisos de aprobación?

El sandbox en sí es el límite de seguridad. Debido a que los agentes se ejecutan dentro de una microVM aislada con políticas de red, aislamiento de credenciales y sin acceso al sistema de tu host fuera del espacio de trabajo, las razones habituales para los avisos de aprobación (como prevenir comandos destructivos, accesos a la red o modificaciones de archivos) son gestionadas en su lugar por las capas de aislamiento del sandbox.

Si prefieres volver a habilitar los avisos de aprobación, cambia el modo de permisos dentro de la sesión. La mayoría de los agentes te permiten cambiar los modos de permisos después del inicio. En Claude Code, utiliza el comando /permissions para cambiar el modo de forma interactiva.

Para que los avisos de aprobación sean la opción predeterminada para cada sesión, define un kit de agente personalizado que anule el punto de entrada (entrypoint) del agente para eliminar la bandera que omite los permisos. Por ejemplo, un kit que lance Claude Code sin --dangerously-skip-permissions:

schemaVersion: "1"
kind: agent
name: claude-safe
agent:
  image: "docker/sandbox-templates:claude-code-docker"
  entrypoint:
    run: [claude]

Ejecútalo con sbx run claude-safe --kit ./claude-safe/. Consulta Kits de agentes para ver el patrón completo.

¿Cómo sé si mi agente se está ejecutando en un sandbox?

Pregúntale al agente. El agente puede ver si se está ejecutando dentro de un sandbox o no. En Claude Code, usa el comando de barra oblicua /btw para preguntar sin interrumpir una tarea en progreso:

/btw ¿te estás ejecutando en un sandbox?

¿Por qué el sandbox no utiliza la configuración de mi agente a nivel de usuario?

Los sandboxes no heredan la configuración del agente a nivel de usuario desde tu host. Esto incluye directorios como ~/.claude para Claude Code o ~/.codex para Codex, donde se almacenan los hooks, las skills y otros ajustes. Solo la configuración a nivel de proyecto en el directorio de trabajo está disponible dentro del sandbox.

Para hacer que la configuración esté disponible en un sandbox, copia o mueve lo que necesites a tu directorio de proyecto antes de iniciar una sesión:

$ cp -r ~/.claude/skills .claude/skills

No uses enlaces simbólicos: un agente en un sandbox no puede seguir enlaces simbólicos a rutas fuera del sandbox.

Colocar las skills y otra configuración del agente junto con el proyecto en sí es una buena práctica independientemente de los sandboxes. De este modo, se realiza un seguimiento de versiones junto con el código y evoluciona con el proyecto a medida que cambia.