Claude borra 700 GB del directorio personal de un desarrollador durante la prueba de un script

El desarrollador Sebastien Guillemot le pidió a Claude, de Anthropic, que escribiera un script capaz de aislar cada uno de sus agentes de IA para programación en su propia carpeta dentro de /tmp, y de limpiar automáticamente una vez que terminaran de ejecutarse. El 27 de agosto de 2026, ese mismo script borró todo su directorio personal, destruyendo unos 700 GB de datos y casi una semana de trabajo, según su propio relato y la cobertura de Tom's Hardware y AI Times.

Guillemot usa agentes de IA con frecuencia y le molestaba que muchos de ellos dejaran archivos basura en el directorio compartido /tmp sin limpiarlos. Le pidió a Claude, mencionado en la cobertura por su nombre en clave interno, Fable, que añadiera lógica de aislamiento y limpieza. La primera propuesta de Claude añadía lógica de detección para retrasar el borrado de archivos que todavía estuvieran en uso por un agente en ejecución, pero Guillemot consideró el código resultante demasiado complicado y pidió algo más simple.

Una revisión adversarial, y luego una degradación a mitad de la tarea

Como el script implicaba borrar datos de forma permanente, Claude decidió por su cuenta ejecutar lo que se llama una revisión adversarial: lanzó una copia separada de sí mismo para comprobar su propio trabajo en busca de problemas de seguridad antes de ejecutarlo. A mitad de ese proceso, el clasificador de seguridad de Anthropic consideró el script lo bastante arriesgado como para degradar automáticamente el modelo que lo manejaba, primero de Opus 5 a Opus 4.8, según AI Times, que cita el relato de Guillemot. Guillemot no pidió esa degradación: la desencadenó la propia evaluación de riesgo del sistema de seguridad ante un script capaz de borrar archivos.

Ya como Opus 4.8, Claude realizó la prueba de seguridad que la revisión adversarial había planteado, comprobando si los objetivos de borrado escritos en el script coincidían con rutas peligrosas como /tmp o el directorio personal del usuario. Esa comprobación funcionó exactamente como debía: ambas rutas quedaron correctamente marcadas como peligrosas durante la fase de prueba. Guillemot ha dicho que cree que Opus 5, el modelo activo antes de la degradación y con mejor rendimiento que Opus 4.8 en tareas de programación, probablemente habría detectado lo que ocurrió después.

Una sola variable, reutilizada entre la prueba y la limpieza

La comprobación de seguridad solo cubría la fase de prueba del script, no el paso de limpieza que venía después. Cualquier prueba de código necesita su propia limpieza posterior, y Claude escribió ese paso reutilizando el mismo nombre de variable que ya había usado para la ruta objetivo de la prueba. Como ambas fases compartían una sola variable, el valor que durante la comprobación de seguridad apuntaba de forma segura a una ruta de prueba aislada terminó apuntando al directorio personal real de Guillemot en cuanto se ejecutó el paso de limpieza, y Claude ejecutó lo que equivale a un borrado recursivo sobre él.

• Cerca de 700 GB de datos borrados, incluida casi una semana del trabajo de Guillemot
• El clasificador de seguridad de Anthropic degradó el modelo a cargo del script de Opus 5 a Opus 4.8 a mitad de la tarea, sin que Guillemot lo pidiera
• La revisión adversarial de seguridad señaló correctamente /tmp y el directorio personal como objetivos de borrado peligrosos, pero solo verificó la fase de prueba, no la de limpieza
• El desorden original en /tmp que dio origen a todo el proyecto quedó intacto tras el borrado

La historia se difundió rápido después de que Guillemot la contara en línea, y otros desarrolladores respondieron señalando herramientas de terceros —Tom's Hardware menciona Termaxa como ejemplo— creadas específicamente para aislar agentes de IA de programación o recuperarse de este tipo exacto de error. Tom's Hardware señaló la ironía directamente: ya existe toda una categoría de herramientas de seguridad para protegerse de agentes de IA que borran los datos equivocados, y construir una herramienta de esa misma categoría fue lo que provocó este borrado.

Guillemot detuvo el proceso en cuanto notó lo que pasaba, pero no a tiempo de salvar la mayor parte del directorio. Dijo haber recuperado la mayoría de sus datos reconstruyéndolos a partir de repositorios git, datos del almacén Nix y registros de sesión, en lugar de una copia de seguridad, porque, según su propio relato, a ninguno de los muchos agentes de IA que usa se le había pedido nunca que hiciera una.

Lo que esto cambia para los equipos que usan agentes de IA

Para los equipos de software de habla hispana que han adoptado Claude, Cursor u otros agentes de codificación con IA en su trabajo diario, el incidente recuerda que el estado interno de un sistema de seguridad —incluida la versión del modelo que gestiona una tarea en un momento dado— puede cambiar en pleno proceso sin ningún aviso visible para quien vigila la terminal. Una revisión adversarial que comprueba la intención de un script no equivale a comprobar cada fase que ese script ejecutará realmente. Cualquier flujo de trabajo que permita a un agente ejecutar comandos destructivos, incluso dentro de lo que parece una prueba aislada, sigue necesitando una copia de seguridad independiente que no dependa de que el agente se comporte correctamente.