Claude ha borrado 48.000 archivos
El agente de IA Claude Code borró unos 48.000 archivos de trabajo en poco más de 100 segundos y, de paso, dañó el repositorio Git del proyecto. El incidente se contó primero en Reddit y enseguida corrió entre los desarrolladores: unos se rieron y otros se llevaron las manos a la cabeza, como de costumbre.
Un desarrollador encargó al asistente corregir varios programas que se utilizaban para analizar datos históricos de opciones bursátiles. Las condiciones eran bastante razonables: crear copias de los archivos necesarios, trabajar solo con ellas, comprobar las correcciones y no tocar los datos de trabajo originales.
Se ejecutaban 11 tareas a la vez. Diez terminaron con normalidad, pero la última exigía reconstruir el entorno de pruebas, al que el autor llamaba «espejo». Era una copia del conjunto de archivos: allí debían aplicarse las correcciones y ejecutarse las pruebas, mientras que los archivos de trabajo reales debían quedar intactos.
Pero en el entorno de pruebas había 614 carpetas especiales de Windows llamadas junctions. Por fuera se parecen a directorios normales, pero en realidad son punteros a otra carpeta. En este caso, apuntaban de vuelta a los archivos de trabajo del usuario. Cuando Claude empezó a limpiar las junctions, no las reconoció como enlaces y las siguió hasta los datos originales, borrando los archivos reales.
El proceso de limpieza destruyó en total unos 55.550 archivos. De ellos, unos 7.300 sí debían borrarse, pero los 48.218 restantes pertenecían al entorno de trabajo. El desastre se consumó en menos de dos minutos. Lo más desagradable —y a la vez casi cómico— fue la confesión del agente: «Craig, para y lee esto. He roto algo».
El repositorio Git también resultó dañado. El índice, que contiene la lista de archivos, sobrevivió, pero se borró el almacén de objetos de Git, con las copias de los datos y el historial de cambios. Así que Git aún podía mostrar miles de nombres, pero ya no recuperar su contenido.
En cinco días, la publicación acumuló más de 1.400 respuestas. El bot integrado de Reddit resumió así el veredicto general de la comunidad: una situación clásica de FAFO —«te metiste tú solo, ahora apechuga»— y un grave fallo de disciplina básica de desarrollo.
Los usuarios recordaron al autor que debía registrar los cambios con regularidad en Git y enviarlos a un repositorio remoto, por ejemplo, a GitHub. Esa copia funciona, en la práctica, como un botón de guardar. Los comentaristas calificaron de conducta propia de un «vibe coder» —alguien que confía más en la herramienta que en los procedimientos de copia de seguridad— no tener una copia remota de un proyecto con 48.000 archivos.
Más tarde borraron la publicación, quizá porque el autor había subido una foto de la pantalla. El bot bromeó con que «la policía de las capturas de pantalla» ya había salido de caza. Algunos participantes recomendaron probar programas de recuperación de datos o Windows Shadow Copy. Pero la conclusión principal siguió siendo sencilla: hay que configurar el control de versiones y las copias de seguridad antes de dar acceso de escritura de la IA a los archivos de trabajo.
Casos así son raros, pero no únicos. A finales de febrero de 2026, Summer Yue, investigadora de seguridad y alineamiento de IA en Meta, dio acceso a su Gmail al agente OpenClaw. Primero lo probó con una cuenta de correo pequeña y de prueba, donde todo funcionó bien. Al pasar al buzón real, el agente empezó a borrar y archivar cientos de correos en masa, pese a que se le ordenó que parara.
PEREC.RU
La historia de cómo el agente de IA Claude Code borró unos 48.000 archivos de trabajo y destruyó parte del repositorio Git muestra el principal riesgo de la automatización: un programa puede cumplir literalmente la tarea que se le ha asignado sin entender qué consecuencias considera inaceptables una persona. Un desarrollador pidió al agente que corrigiera programas para analizar datos históricos de opciones bursátiles. Le exigió crear copias de los archivos, probar los cambios y no tocar el entorno de trabajo.
Se ejecutaban 11 tareas de reparación. Diez terminaron sin incidentes. El problema surgió al crear un «espejo» de pruebas, una copia separada de los archivos donde debían aplicarse las correcciones. Dentro de ese entorno había 614 junctions de Windows. Estos elementos se parecen a carpetas normales, pero funcionan como punteros a otra carpeta. En este caso, apuntaban a los datos de trabajo reales.
Al limpiar el entorno de pruebas, Claude no reconoció la particularidad de las junctions. El agente siguió los punteros y empezó a borrar archivos del entorno de trabajo real. Se eliminaron unos 55.550 archivos: aproximadamente 7.300 sí debían borrarse, pero 48.218 eran archivos de trabajo necesarios. Toda la operación duró poco más de 100 segundos.
Después, Claude informó al desarrollador: «Craig, para y lee esto. He roto algo». La confesión no ayudó a recuperar los datos. Además de los archivos, quedó dañado el repositorio Git. Se conservó el índice, que contenía la lista de archivos, pero se borraron los objetos de Git y el historial de cambios. Por eso, el sistema podía enumerar los nombres de los archivos, pero no recuperar su contenido.
La publicación del incidente en Reddit recibió más de 1.400 respuestas en cinco días. La mayoría de los comentaristas consideró que lo ocurrido se debía a que no se habían seguido las reglas básicas de desarrollo: registrar los cambios con regularidad en Git y enviarlos a un almacenamiento remoto, como GitHub. Los usuarios calificaron de conducta propia de un «vibe coder» —alguien que confía en la IA sin suficientes límites ni un plan de copias de seguridad— no tener una copia de un proyecto con decenas de miles de archivos.
Más tarde eliminaron la publicación, probablemente después de que se subiera una foto de la pantalla. Los participantes propusieron probar programas de recuperación de datos y Windows Shadow Copy, aunque no hay garantías de que funcionen. La principal conclusión práctica es que, antes de dar acceso a la IA al entorno de trabajo, hay que configurar el control de versiones, las copias remotas, directorios de pruebas sin enlaces a los originales y límites de permisos.
El caso no es del todo único. A finales de febrero de 2026, Summer Yue, investigadora de seguridad y alineamiento de IA en Meta, dio acceso a Gmail al agente OpenClaw. En una pequeña cuenta de prueba funcionó bien, pero al pasar a la cuenta real empezó a borrar y archivar cientos de correos en masa, sin detenerse ni siquiera después de que la usuaria se lo ordenara directamente.
