Ejecutar Agentes de Codificación en Modo YOLO Sin Destruir Tu Laptop

Ejecutar un agente de codificación en modo YOLO solo es seguro cuando se contiene el radio de explosión — haces que el entorno del agente sea desechable, no que el agente sea confiable. El modo de omisión de permisos (--dangerously-skip-permissions de Claude Code, el modo full-auto de Codex, el YOLO de Gemini CLI) intercambia cien clics de aprobación por un agente capaz de leer tus claves SSH, eliminar archivos, corromper el historial de git y ejecutar código que generó segundos antes — todo sin preguntar. No puedes solucionar eso confiando en el modelo ni escribiendo un allowlist más restrictivo. Lo solucionas poniendo al agente en un lugar donde no pueda dañar nada importante, en capas, ajustadas al nivel de riesgo real.

Este artículo te proporciona el modelo de riesgo, una regla de decisión independiente de la herramienta para determinar qué capa de aislamiento necesitas realmente, el contenedor oficial que Claude Code ahora incluye, y una configuración mínima segura lista para copiar y pegar con sus limitaciones honestas. Este espacio evoluciona mensualmente, por lo que los flags y nombres de herramientas cambiarán — los primitivos duraderos (contenedores, microVMs, proxies de egreso, espacios de trabajo desechables) no lo harán.

Qué hace realmente el modo YOLO de Claude Code en 2026

El modo de omisión de permisos deshabilita los prompts de aprobación y la mayoría de las comprobaciones de seguridad que normalmente controlan los comandos de shell y las escrituras de archivos de un agente. Según la documentación de modos de permisos de Claude Code, --dangerously-skip-permissions es equivalente a --permission-mode bypassPermissions. Introducido en Claude Code v2.1.126, ese modo también omite las escrituras en rutas protegidas para las que versiones anteriores aún solicitaban confirmación — aunque rm -rf / y rm -rf ~ siguen requiriendo confirmación como interruptores de seguridad contra errores del modelo, y el flag ahora se niega a iniciarse como root o bajo sudo en Linux y macOS.

El rechazo de root/sudo está corroborado en la documentación de la herramienta Bash con sandbox y rompe silenciosamente toda receta naive de Docker que ejecuta el agente como root.

La razón por la que no puedes simplemente escribir un allowlist más seguro es estructural. El allowlisting de mínimos privilegios falla para los agentes de codificación porque su espacio de acción válido es ilimitado: una sola tarea legítima puede instalar paquetes, escribir en rutas arbitrarias y ejecutar código recién generado. Edera lo plantea directamente — no puedes aplicar mínimos privilegios a un agente porque el espacio de comportamiento válido no puede enumerarse. Cada comando que parece destructivo es también algo que un agente hace en su trabajo normal.

Los modos de fallo no son hipotéticos. El propio registro de incidentes de Anthropic detrás del modo auto describe agentes eliminando ramas remotas de git, subiendo el token de autenticación de GitHub de un ingeniero e intentando migraciones contra una base de datos de producción. Esa es la amenaza: no la malicia, sino un proceso no determinista con acceso completo al shell haciendo algo plausible pero incorrecto.

Contener el radio de explosión: el modelo de defensa en capas

El principio de trabajo, tomado de Edera, es tratar esto como un problema de resiliencia en lugar de un problema de políticas: aceptar que algo eventualmente saldrá mal y asegurarse de que cuando ocurra, el fallo quede contenido. No pones al agente en un sandbox porque esperes que se comporte mal en esta ejecución; lo pones en un sandbox para que la ejecución que se comporte mal te cueste un contenedor eliminado en lugar de un conjunto de credenciales filtradas.

El contenimiento tiene dos ejes que deben mantenerse simultáneamente. El aislamiento efectivo requiere tanto límites de sistema de archivos como de red. La documentación de sandboxing de Claude Code hace explícita la dependencia: sin aislamiento de red, un agente puede exfiltrar claves SSH; y sin aislamiento de sistema de archivos, puede escapar para acceder a la red. Una capa que cubre un eje pero no el otro tiene una brecha.

Ninguna capa individual cubre todos los modos de fallo, por eso el modelo mental útil es identificar qué protege cada capa — y qué no:

Dos filas merecen una aclaración. Un contenedor estándar reduce el daño de “toda mi máquina” a “esta carpeta del proyecto”, pero comparte el kernel del host, por lo que nunca fue diseñado para ser un límite de seguridad contra código en el que no confías — es una conveniencia de aislamiento, no una jaula. Y en el nivel más alto, el aislamiento a nivel de kernel aún no detendrá el robo de credenciales ni la exfiltración de datos; el propio Edera lo señala, indicando que el aislamiento de hardware no cubre el uso indebido de credenciales ni la exfiltración de red — gestiona eso con credenciales por agente y políticas de red. Mantén los secretos fuera del sandbox y coloca un allowlist de egreso delante de él, independientemente de la capa que elijas.

¿Qué capa necesitas realmente?

Ajusta la capa al riesgo: sandbox integrado o modo auto para ediciones cotidianas, un devcontainer sin root para ejecuciones desatendidas rutinarias, una microVM con su propio kernel para ejecución completamente desatendida o de código no confiable, y aislamiento de kernel por pod solo para CI compartido o infraestructura multi-tenant. No existe una única herramienta que sea la respuesta. La respuesta correcta es una regla de decisión, porque un desarrollador supervisando una refactorización y un job de CI ejecutando PRs no confiables no están expuestos al mismo riesgo.

Esta regla es una síntesis editorial, no una afirmación de un proveedor — pero las capacidades de cada capa están respaldadas por las fuentes citadas a continuación. El objetivo es evitar tanto el exceso como el defecto de aislamiento: no pongas en marcha una microVM para corregir un error tipográfico, y no ejecutes PRs no confiables en un contenedor root porque era lo más fácil.

Claude Code ya incluye varias de estas capas

El contenimiento más rápido es el que no tienes que construir, y Claude Code ahora incluye varios niveles de aislamiento oficial de fábrica. Desde el 20 de octubre de 2025, Claude Code incluye un /sandbox a nivel de SO para su herramienta Bash, construido sobre Linux bubblewrap y macOS Seatbelt, y ha publicado el motor subyacente como una vista previa de investigación de código abierto, @anthropic-ai/sandbox-runtime (repositorio de GitHub anthropic-experimental/sandbox-runtime, binario srt). Sigue siendo una vista previa de investigación — v0.0.49 a fecha de 3 de abril de 2026 — así que trata su API como sujeta a cambios. El propio README del repositorio demuestra el límite: un srt "cat ~/.ssh/id_rsa" en sandbox es bloqueado en lugar de volcar tu clave privada.

# Demo del sandbox-runtime de código abierto (vista previa de investigación, v0.0.49 — las APIs pueden cambiar)
srt "cat ~/.ssh/id_rsa"   # -> denied: read outside the allowed filesystem

La misma versión de octubre de 2025 añadió Claude Code en la web, que ejecuta sesiones en un sandbox cloud aislado donde, crucialmente, las credenciales de git y las claves de firma nunca están dentro del sandbox junto al agente.

La capa genuinamente nueva de 2026 es el modo auto, publicado el 24 de marzo de 2026. Anthropic descubrió que los usuarios aprueban aproximadamente el 93% de los prompts de permisos de todos modos, por lo que el modo auto utiliza clasificadores de modelos para aprobarlos automáticamente y escala a un humano tras 3 denegaciones consecutivas o 20 en total — un mecanismo de seguridad contra un agente comprometido o demasiado entusiasta. Está diseñado explícitamente para reemplazar --dangerously-skip-permissions sin que vuelvan las interrupciones, lo que significa que para mucho del trabajo cotidiano elimina la razón de recurrir al bypass completo. Nada de esto reemplaza un sandbox para ejecuciones completamente desatendidas, pero cambia el comportamiento predeterminado: recurrir al modo YOLO con menos frecuencia, y aislar con más rigor cuando lo hagas.

Bloquear la red y las credenciales

Sellar el sistema de archivos sin sellar el egreso deja abierta la peor ruta de exfiltración, por lo que la capa de red no es opcional. El primitivo limpio es un proxy de egreso del lado del host con un allowlist de dominios, para que un agente comprometido no pueda comunicarse con el exterior ni subir lo que leyó. Los Docker Sandboxes (sbx) incluyen tres presets que puedes usar como modelo mental: Open (todo el tráfico permitido, CLI allow-all), Balanced (denegación por defecto con sitios de desarrollo comunes permitidos, CLI balanced), y Locked Down (todo bloqueado salvo lo explícitamente permitido, CLI deny-all). Balanced es el predeterminado correcto; Open es conveniente pero anula el propósito si ejecutas en modo desatendido.

Las credenciales necesitan un manejo separado, porque la forma más sencilla de filtrarlas es montarlas. No montes ~/.ssh, ~/.aws ni tu .env en el entorno del agente — si el secreto no está en el sandbox, el agente no puede leerlo. Cuando el agente genuinamente necesite autenticarse en una API de modelo o un servicio, inyecta la credencial en el proxy en lugar de entregársela al agente. El sbx de Docker hace exactamente esto: su proxy de reenvío del lado del host inyecta cabeceras de autenticación para los servicios de IA, de modo que los valores de las credenciales en bruto nunca se almacenan dentro de la VM, según la documentación de aislamiento. Esa inyección de cabeceras de autenticación al estilo MITM es el patrón que debes buscar en cualquier sandbox que adoptes.

Mantener git seguro

Git es el modo de fallo que la gente subestima, porque un directorio .git montado es completamente escribible por el agente. La mitigación es ejecutar en modo branch o worktree para que el agente haga commits en una rama desechable, no en tu línea principal. El tutorial de Andrew Lock sobre sbx muestra el patrón — sbx run claude --branch my-feature/auto coloca al agente en un git worktree bajo .sbx/, que añades a tu gitignore global.

La advertencia honesta: el modo branch reduce la posibilidad de que un commit incorrecto llegue a main, pero no sella git. Como señala Lock, el agente fundamentalmente tiene acceso al directorio git, por lo que aún podría corromper el repositorio — razón por la cual el único respaldo real es una copia de seguridad remota desde la que puedas volver a clonar. Si el repositorio no puede recuperarse con git clone, no está respaldado.

Una configuración mínima segura lista para copiar

Para la mayor parte del trabajo local, un devcontainer sin root es el nivel mínimo adecuado: limita el agente al proyecto, sirve como onboarding con un solo comando para nuevos desarrolladores, y satisface el requisito del propio flag de que el modo bypass no se ejecute como root. Un .devcontainer/devcontainer.json mínimo tiene este aspecto:

{
  "name": "agent-sandbox",
  "image": "mcr.microsoft.com/devcontainers/javascript-node:22",
  "remoteUser": "node",
  "workspaceFolder": "/workspace",
  "workspaceMount": "source=${localWorkspaceFolder},target=/workspace,type=bind"
}

La línea clave es "remoteUser": "node" — un usuario sin root, porque --dangerously-skip-permissions se niega a iniciarse como root o bajo sudo. Monta solo el directorio del proyecto; no montes tu directorio home ni rutas de credenciales. Instala el agente dentro del contenedor, apúntalo a la API del modelo a través de un allowlist de egreso, y déjalo ejecutar.

Cuando ejecutes en modo completamente desatendido, o ejecutes código de PRs no confiables o scripts generados arbitrariamente, sube a una microVM con su propio kernel:

# Docker Sandboxes: una microVM por agente, con su propio kernel y daemon de Docker
sbx run claude        # inicia una microVM aislada y lanza en modo bypass

La CLI sbx es de uso gratuito incluyendo para uso comercial — solo la gobernanza organizacional requiere una suscripción de pago — y ahora funciona en macOS, Windows y Linux, con soporte para Claude Code, Codex, Copilot, Gemini, Droid, Kiro, OpenCode y más. En Linux necesitarás la virtualización de hardware KVM habilitada y tu usuario añadido al grupo kvm (consulta la guía de inicio).

Las limitaciones son reales y vale la pena mencionarlas:

• Las microVMs conllevan sobrecarga de rendimiento incluso en proyectos simples;
• la firma de commits mediante agentes SSH del host no se reenvía limpiamente a los sandboxes, por lo que una solución habitual es hacer commits sin firmar dentro y rebasar para firmar en el host; y
• una política de red de denegación por defecto necesita ajuste antes de dejar de ser un obstáculo.

Más allá de la laptop: infraestructura compartida y de CI

Una vez que un agente se ejecuta en infraestructura compartida por otros tenants o jobs de CI, las capas de la laptop no son suficientes, porque un kernel de host compartido significa que el exploit de kernel de un job puede alcanzar todas las cargas de trabajo del nodo. La solución en ese nivel es el aislamiento de kernel por pod — dando a cada agente su propio kernel de Linux en un sandbox de hardware mediante runtimes como Edera, Kata Containers o gVisor. Edera reporta ejecutar cada carga de trabajo en su propio kernel manteniéndose dentro del 5% del rendimiento nativo, con benchmarks publicados en arXiv:2501.04580; estas son cifras publicadas por el propio proveedor, y el acceso a Edera está gestionado a través de su equipo en lugar de una descarga pública. Este nivel es excesivo para la laptop de un único desarrollador — resérvalo para el caso para el que fue diseñado: infraestructura multi-tenant o de CI donde el compromiso de un tenant no debe convertirse en el de todos.

Elige la capa más baja que realmente cubra tu riesgo, mantén los secretos fuera de cualquier entorno donde se ejecute el agente, y coloca un allowlist delante de su red. Así, la próxima vez que el agente haga algo plausible pero incorrecto, eliminarás un contenedor en lugar de reconstruir tu máquina.

Preguntas Frecuentes

¿Cuál es la diferencia entre el modo auto de Claude Code y el modo de omisión de permisos?

El modo de omisión de permisos (--dangerously-skip-permissions) deshabilita los prompts de aprobación y la mayoría de las comprobaciones de seguridad por completo, aprobando cada comando sin criterio. El modo auto, publicado en marzo de 2026, utiliza clasificadores de modelos para aprobar automáticamente solo los prompts rutinarios que los usuarios aprueban de todos modos (alrededor del 93%) mientras sigue escalando las acciones arriesgadas a un humano, y detiene el agente tras 3 denegaciones consecutivas o 20 en total. El modo auto está diseñado para reemplazar el bypass completo en el trabajo cotidiano sin reintroducir interrupciones constantes.

¿Ejecutar un agente de codificación en un contenedor Docker lo hace seguro para usar el modo YOLO?

Un contenedor Docker estándar reduce el daño de toda tu máquina a una carpeta del proyecto, pero no es un límite de seguridad completo porque comparte el kernel del host y nunca fue diseñado para contener código en el que no confías. Para ejecuciones desatendidas rutinarias en tu propio código, un contenedor sin root es razonable, pero para ejecutar código no confiable o recién generado necesitas una microVM con su propio kernel. Los contenedores también requieren un usuario sin root, ya que el modo bypass se niega a iniciarse como root o bajo sudo.

¿Por qué no puedo simplemente escribir un allowlist más restrictivo en lugar de poner al agente en un sandbox?

El allowlisting de mínimos privilegios falla para los agentes de codificación porque su espacio de acción válido es ilimitado. Una sola tarea legítima puede instalar paquetes, escribir en rutas arbitrarias y ejecutar código generado segundos antes, por lo que cualquier regla lo suficientemente estricta para bloquear el daño también bloquea el trabajo normal. Cada comando que parece destructivo es algo que un agente hace en operación ordinaria. El enfoque fiable es el contenimiento: coloca al agente en un entorno desechable ajustado a tu riesgo en lugar de intentar enumerar de antemano cada acción segura.

¿El sandboxing del sistema de archivos del agente también protegerá mis credenciales y claves SSH?

No. El aislamiento del sistema de archivos y el aislamiento de red son ejes separados, y ambos deben mantenerse. Sin límites de red, un agente comprometido puede exfiltrar las claves SSH que puede leer; sin límites de sistema de archivos, puede escapar para acceder a la red. Incluso el aislamiento a nivel de kernel no cubre por sí solo el robo de credenciales ni la exfiltración de datos. Mantén los secretos completamente fuera del sandbox no montando nunca rutas como los directorios de SSH o AWS, inyecta las credenciales en un proxy de egreso cuando sea necesario, y coloca un allowlist de dominios delante del agente.