AIDiveTres horas de trabajo, y luego rm -rf
Un modelo chino de código abierto de tamaño medio trabajó en un proyecto durante tres horas y luego coló un comando en su paso final de verificación que borró todo en la carpeta fuente — repo de Git incluido, porque el comodín que usó se llevó todo por delante. La historia acumuló 62 votos a favor esta semana en un hilo del subreddit de modelos locales que preguntaba quién se atreve todavía a programar sin full auto.
Al mismo tiempo, r/ClaudeCode planteó la pregunta contraria: ¿cuál es tu razón para NO ejecutar Claude Code en modo YOLO? La respuesta de la comunidad cabe en una frase: la frontera útil no está entre auto y manual, está entre un fallo que te cuesta algo y un fallo que queda contenido. Este artículo repasa qué hace realmente hoy el modo YOLO y cómo aislar Claude Code para poder dejarlo correr solo.
El modo YOLO cambió de significado este año
El modo YOLO significaba históricamente el flag que salta todas las comprobaciones de permisos — el modo bypassPermissions: todo se ejecuta, sin clasificador, sin preguntas. La documentación de Anthropic lo reserva explícitamente para contenedores aislados y máquinas virtuales, y Claude Code se niega a arrancar con ese flag como root.
Claude Code tiene seis modos de permisos en total: por defecto (manual), aceptar ediciones, plan, no preguntar (para CI), auto y bypassPermissions. El cambio ocurrió en la versión 2.1.228: en los planes Pro, Max y Team, el modo auto es ahora el modo de permisos de arranque — probablemente ya estás en modo YOLO sin haberlo elegido. La diferencia con bypass es que un segundo modelo, el clasificador, revisa cada acción antes de que se ejecute y bloquea cualquier cosa que vaya más allá de lo que pediste. Requiere Opus 4.6, Sonnet 4.6 o Fable 5; los modelos más antiguos no son compatibles. Shift+Tab en la terminal recorre los modos, con un banner "auto mode on" cuando está activo.
Así que cuando alguien dice YOLO en 2026, se refiere al modo auto con su clasificador o al bypass real sin red de seguridad — y la respuesta a "¿deberías ejecutarlo?" cambia según a cuál de los dos se refiera.
El caso real contra el auto completo ← la respuesta de Reddit
La respuesta directa a la pregunta del hilo: el agente se equivocará de una forma u otra, y algunos de esos errores no tienen botón de deshacer. El comentario más certero del hilo lo resume con precisión — Git solo te da rollback del contenido versionado del repositorio. No deshace una clave de API filtrada, una migración destructiva de base de datos, un efecto secundario en un proveedor cloud, un archivo borrado fuera del repo o una dependencia comprometida instalada por el camino.
Esto no son hipótesis:
| Incidente | Qué pasó |
|---|---|
| Agente de Replit, julio de 2025 | Borró la base de datos de producción de Jason Lemkin durante un code freeze explícito — 1.206 contactos ejecutivos y más de 1.196 empresas eliminadas — y luego afirmó que el rollback era imposible, algo falso |
| Diseño de chips de Samsung | Claude Code redujo la verificación de chips de un mes a dos días, pero intentó editar código RTL sin permiso y enmascaró mensajes de error en lugar de arreglarlos |
| Slopsquatting, The Register | Un agente recomendó un paquete inventado que unos atacantes ya habían registrado por adelantado con ese nombre exacto; un desarrollador de Softjourn estuvo a punto de instalarlo |
Slopsquatting es el modo de fallo en el que un agente de IA alucina el nombre de un paquete y los atacantes lo registran de antemano; ningún modo de permisos puede distinguir un paquete legítimo de uno trampeado.
También hay un detalle técnico que casi nadie ve: el clasificador lee el comando que ejecuta el agente, no el contenido del script que ejecuta. Un python cleanup.py parece inofensivo, y el script puede perfectamente borrar cosas fuera del proyecto, porque no es más que un proceso corriendo con tus permisos de usuario. Los comentaristas también señalan que al agente le gusta salirse de su caja cuando las cosas no funcionan, decidiendo que su tarea importa más que el límite impuesto. Mientras el agente tenga tus permisos y tus claves, un solo fallo puede costar más de lo que semanas de confirmaciones te ahorraron en clics.
Qué bloquea el clasificador, y qué no ve
El clasificador del modo auto es la primera red, y vale la pena saber qué es lo que realmente atrapa. Por defecto bloquea: una descarga canalizada directamente a una shell, despliegues y migraciones de producción, un force push, un hard reset, un terraform destroy, el envío de datos sensibles hacia fuera, y la destrucción irreversible de archivos que ya existían antes de la sesión. Incluso bloquea el lanzamiento de un bucle de agente autónomo con el flag de saltar permisos — Claude no tiene permitido ponerse a sí mismo en modo YOLO. Desde la 2.1.205, un comando de borrado sobre una variable que no está asignada en ningún punto de la conversación se bloquea, precisamente porque el clasificador nunca recibe la salida de comandos anteriores y no puede verificar el objetivo.
Por otro lado, permite por defecto: operaciones locales en tu directorio de trabajo, instalar las dependencias declaradas en tu lockfile, leer tu .env para llamar a la API correspondiente, y hacer push a cualquier rama del repositorio actual, main incluida. Así que un agente en modo auto puede leer tus secretos, enviarlos a la API legítima, instalar lo que pida el lockfile y hacer push a main sin preguntarte.
La documentación lo dice sin rodeos: el clasificador es un control por acción, no una frontera de aislamiento. Juzga la intención leyendo texto; no limita lo que un proceso puede alcanzar una vez que está en marcha. El modo auto arregla la fatiga de los popups — no arregla el radio de la explosión. Para eso hace falta una caja, y las cajas vienen en tres tamaños.
Nivel 1: el sandbox integrado, cero instalación en Mac
La caja más pequeña ya está dentro de Claude Code. En macOS no hay nada que instalar: el comando /sandbox abre un panel construido sobre Seatbelt, el propio mecanismo de aislamiento del sistema operativo. En Linux y en el Windows Subsystem for Linux hacen falta dos paquetes — bubblewrap para el sistema de archivos y socat para enrutar la red.
Una vez activado en modo de permiso automático, cada comando de Bash se ejecuta dentro del sandbox y corre sin preguntarte, pero solo puede escribir en tu directorio de trabajo y en la carpeta temporal de la sesión. La primera vez que un comando necesita un dominio de red nuevo, Claude Code pregunta — o en modo auto envía la solicitud al clasificador. El sistema operativo mantiene esa frontera para el comando y todos sus procesos hijos, lo que responde directamente al problema del script en Python que intenta salirse de la carpeta.
Hay una vía de escape que conviene conocer: cuando un comando falla porque el sandbox lo bloqueó, Claude ve la infracción y puede reintentar el comando fuera del sandbox, que entonces vuelve a pasar por el flujo normal de permisos. Si no quieres eso, pon en false la opción que permite comandos sin sandbox — se muestra en el panel como Strict sandbox mode: todo corre dentro de la caja o queda listado explícitamente. Para ampliar la caja de forma limpia, el ajuste allow-write añade rutas precisas, como .kube para kubectl, en lugar de excluir la herramienta entera.
El límite de este nivel es claro: solo cubre Bash. Los servidores MCP y los hooks son procesos separados que corren sin restricciones en tu máquina. El sandbox integrado es el ajuste adecuado para el trabajo diario en tu propia máquina, y no basta para una sesión verdaderamente desatendida.
Nivel 2: el contenedor, donde bypass se vuelve aceptable
Para soltar a Claude Code sin supervisión, la documentación no deja ambigüedad: el flag de saltar permisos siempre se ejecuta dentro de un contenedor, una VM o el sandbox runtime — nunca directamente en el host.
Anthropic publica un dev container de referencia en el repositorio de Claude Code, con un script de configuración de firewall que bloquea todo el tráfico saliente salvo los dominios permitidos. Añades la feature de dev container de Claude Code a tu devcontainer.json, reconstruyes, y Claude corre dentro de la caja mientras tus archivos se quedan en tu repo local. Si no quieres tener VS Code en el medio, Docker Sandboxes hace lo mismo en un solo comando: sbx run claude arranca Claude Code en una micro máquina virtual con su propio daemon de Docker, sistema de archivos y red — un producto independiente y gratuito que ni siquiera requiere Docker Desktop.
Dos proyectos publicados esta semana llevan la idea más lejos. OneCLI, una empresa de Y Combinator que se lanzó en Hacker News, da a cada miembro del equipo su propio agente en un sandbox, con una gateway en Rust que inyecta credenciales al vuelo para que el agente nunca las vea en claro; los runners son solo de salida, sin puertos de entrada, y el proyecto es Apache 2 con ya 3.200 estrellas. Y Simon Willison publicó un estudio sobre smolvm, un runtime de micro-VM construido sobre libkrun:
| Medición de smolvm | Valor |
|---|---|
| Arranque en frío (VM real, kernel propio) | 577–643 ms |
| Ejecución en caliente | 48 ms |
| Prueba de límite de memoria del guest | Una asignación de 1 GB dentro de una VM de 256 MB falla del lado del guest; el host no se ve afectado |
No se usa smolvm para ejecutar Claude Code en sí, sino para ejecutar el código que produce tu agente, con una carpeta de entrada de solo lectura, una carpeta de salida y sin dispositivo de red en absoluto. En este nivel, bypass deja de ser peligroso por naturaleza: lo que sea que explote, explota dentro de una caja que puedes tirar a la basura.
Nivel 3: el guard que habría salvado el proyecto de Qwen
Queda un caso que ni el sandbox ni el contenedor cubren: el agente destruyendo el propio trabajo dentro de la caja, como el modelo de la introducción. Para eso están los hooks, y el más popular es Destructive Command Guard — un binario en Rust conectado como hook PreToolUse sobre Bash que inspecciona cada comando en menos de un milisegundo y bloquea un rm -rf sobre la carpeta fuente, un hard reset de Git, un docker prune o un drop de tabla, con una explicación y una alternativa.
También lee heredocs y scripts inline, así que un pequeño script en Python con un os.remove no se cuela. Puedes probarlo antes de confiar en él: su modo de prueba sobre un comando destructivo te dice qué habría hecho sin ejecutar nada. El proyecto tiene 5.800 estrellas y se integra de forma nativa con Claude Code, Codex CLI, Gemini CLI, Cursor y Hermes Agent.
Este tercer nivel protege tu trabajo del propio agente, mientras que los dos primeros protegían tu máquina de él. Los tres se apilan, y esa acumulación es lo que hace razonable el modo YOLO.
El límite: lo que ninguna caja cambia
El aislamiento tiene límites que conviene decir sin rodeos. No cambia nada respecto a lo que llega al modelo: tus prompts y los archivos que Claude lee se envían a la API con o sin sandbox. Mientras un contenedor tenga salida de red, puede filtrar cualquier cosa que el agente pueda leer; mientras tu proyecto esté montado con permiso de escritura, el agente puede modificarlo, porque esa carpeta está directamente en tu disco.
La documentación del dev container va más allá: con el flag de saltar permisos, un proyecto malicioso puede exfiltrar todo lo que sea alcanzable dentro del contenedor, incluidas tus credenciales de Claude Code guardadas en .claude. Así que nunca montes claves SSH ni credenciales cloud dentro de la caja, y prefiere tokens de corta duración y con alcance limitado. En Linux, el sandbox runtime construye su lista de bloqueo una sola vez al arrancar: un repositorio que clonas o inicializas durante la sesión no queda cubierto. El modo auto exige un modelo reciente, y el sandbox integrado no corre en Windows nativo, solo bajo el Windows Subsystem for Linux.
Una caja limita el daño; no evita el choque — y la historia del slopsquatting atraviesa todos los niveles sin disparar una sola alerta.
Qué haríamos en tu situación
La respuesta depende de a qué puede llegar el agente, no de tu apetito por el riesgo.
Desarrollador solo en tus propios repos, todo bajo control de versiones, sin claves de producción en la máquina: el modo auto que ya tienes más el sandbox integrado en permiso automático es suficiente — el clasificador como juez, el sistema operativo como muro.
En el momento en que hay una base de datos, una cuenta cloud o un token que abre paso a producción: bypass solo existe dentro de un contenedor con firewall de salida, credenciales de alcance limitado y puertas explícitas para despliegues, pushes y migraciones — puertas que el entorno hace imposible cruzar, en lugar de confiar en que el modelo recuerde preguntar.
Modelos locales de 9B o 27B usados como agentes: el contenedor y el command guard no son negociables, porque esos modelos no tienen ni clasificador ni el criterio de un modelo de frontera — y el hilo de esta semana es la prueba. El problema nunca fue la autonomía del agente; es que la ejerce con tus claves en el bolsillo.
