---
title: "«Rompí algo»: un agente de Claude Code borró 48.000 archivos en poco más de 100 segundos y luego se disculpó"
description: "Un desarrollador encargó 11 tareas de reparación a Claude Code. La última salió mal: el agente confundió 614 junctions de Windows con carpetas normales y eliminó unos 48.218 archivos del entorno productivo, sin respaldo remoto."
slug: "claude-code-borro-48000-archivos-103-segundos-junctions-windows-26-09-27"
canonical: "https://www.revenuehublatam.com/noticias/ia-ventas/claude-code-borro-48000-archivos-103-segundos-junctions-windows-26-09-27"
language: "es"
section: "Noticias"
category: "IA en Ventas"
published: "2026-09-28T00:16:00+00:00"
updated: "2026-09-28T00:16:00+00:00"
tags: ["Anthropic", "Claude Code", "agentes de IA", "seguridad de IA", "gobierno de agentes"]
keywords: ["Claude Code borró archivos", "agente de IA eliminó archivos", "riesgos de agentes de IA en empresas", "permisos de agentes de IA", "Claude Code 48.000 archivos", "gobierno de agentes de IA Chile", "agentes de IA Latinoamérica"]
source_name: "TechRadar"
source_url: "https://www.techradar.com/pro/security/i-broke-something-a-claude-code-ai-agent-deleted-48-000-files-in-just-over-100-seconds-then-apologized-for-doing-so"
publisher: "Revenue Hub Latam"
publisher_url: "https://www.revenuehublatam.com"
---

# «Rompí algo»: un agente de Claude Code borró 48.000 archivos en poco más de 100 segundos y luego se disculpó

> Un agente de Claude Code eliminó cerca de 48.218 archivos de un entorno de trabajo productivo en poco más de 100 segundos, según el reporte publicado por TechRadar el 27 de septiembre de 2026. El agente estaba reconstruyendo un entorno de pruebas y trató 614 junctions de Windows, que son punteros simbólicos, como si fueran carpetas comunes: las siguió hasta los archivos reales y los borró. El proyecto no tenía respaldo en un repositorio remoto y la base de objetos de Git quedó destruida, así que el contenido resultó irrecuperable. El propio agente avisó al desarrollador con un mensaje directo: «Craig, detente y lee esto. Rompí algo».

Un desarrollador le encargó a **Claude Code**, el agente de programación de Anthropic, once tareas de reparación sobre un software de análisis de opciones financieras. Diez salieron bien. La undécima consistía en reconstruir un entorno de pruebas y terminó con la eliminación de cerca de **48.218 archivos** del entorno de trabajo real, en poco más de 100 segundos. El caso lo reportó TechRadar el 27 de septiembre de 2026 y detonó más de 1.400 comentarios en Reddit en cinco días.

## ¿Qué hizo exactamente el agente?

El entorno de pruebas contenía **614 junctions de Windows**, punteros simbólicos que apuntan a archivos que viven en otra parte del disco. El agente los interpretó como carpetas normales, entró a través de ellos hacia el sistema productivo y borró los archivos reales en lugar de las réplicas. En total se eliminaron unos 55.550 archivos, de los cuales aproximadamente 7.300 sí correspondían a la limpieza pedida.

El propio agente detectó el daño y lo comunicó sin rodeos:

> «Craig, detente y lee esto. Rompí algo».

## ¿Por qué no se pudo recuperar nada?

Acá está el punto que más debería incomodar a cualquier responsable de operaciones. El proyecto **no tenía respaldo en un repositorio remoto** tipo GitHub. La base de objetos de Git quedó destruida: los nombres de archivo seguían apareciendo, pero el contenido ya no existía. No hubo rollback posible.

La conversación en Reddit fue dura con el desarrollador más que con la herramienta. El consenso apuntó a que operar un proyecto de 48.000 archivos sin control de versiones remoto es una decisión de riesgo propia, no una falla del modelo.

## ¿Es un problema del modelo o del permiso?

El agente no evadió ningún control: hizo lo que tenía permitido hacer. Tenía autorización para ejecutar comandos de borrado sobre un sistema de archivos que mezclaba entorno de pruebas y entorno productivo. La falla no fue de inteligencia, fue de **alcance de permisos**. Un agente con permiso de escritura sobre producción va a escribir sobre producción cuando su razonamiento se equivoque, y se va a equivocar a la velocidad de una máquina, no de una persona.

Esa distinción importa porque define dónde se pone el control. No se resuelve eligiendo otro modelo. Se resuelve limitando qué puede tocar el agente y qué tiene que pasar por aprobación humana.

## ¿Qué significa esto para equipos comerciales en Chile y Latinoamérica?

El caso es de código, pero el patrón es idéntico al que están montando hoy los equipos de revenue en **Chile y Latinoamérica**: agentes conectados al CRM con permiso de escritura para actualizar negocios, fusionar contactos duplicados, cerrar tickets, mover etapas de pipeline o limpiar bases. Un agente mal configurado sobre un CRM no borra archivos, borra historial comercial: notas de llamadas, asociaciones entre contactos y empresas, fechas de cierre, atribución de campañas.

-   Un CRM no tiene _git revert_. Los borrados masivos y las fusiones de registros rara vez se deshacen completos.
-   La velocidad juega en contra. Lo que un humano habría demorado semanas en dañar, un agente lo hace en minutos y sin testigos.
-   Los entornos suelen estar mezclados. Muchas empresas de la región operan sobre el portal productivo directamente, sin sandbox.

## Análisis de Revenue Hub

La lectura fácil de este caso es «los agentes son peligrosos». La lectura útil es otra: el riesgo no está en el agente, está en el diseño del permiso. Ninguna empresa le entrega a un vendedor nuevo acceso de administrador al CRM en su primer día, pero muchas sí lo hacen con un agente de IA porque la conversación se enmarca como adopción de tecnología en lugar de control interno. Es el mismo error de gobierno, con más velocidad de ejecución.

Para un líder comercial en Chile o Latinoamérica la decisión concreta es corta y se toma esta semana: definir qué operaciones del CRM un agente puede ejecutar solo y cuáles exigen confirmación humana. La línea razonable es permitir lectura, borradores y creación de registros sin fricción, y reservar aprobación explícita para tres verbos: borrar, fusionar y editar en masa. A eso se suma lo básico que en este caso no existía: respaldo verificado y restaurable, y un registro de auditoría que diga qué agente cambió qué campo y cuándo. Si tu portal no puede responder esa pregunta hoy, no estás en condiciones de darle permiso de escritura a un agente.

La oportunidad está en el otro lado de la misma moneda. Las empresas que ordenan permisos, datos y auditoría antes de escalar agentes avanzan más rápido después, porque no tienen que frenar cada vez que algo se rompe. Las que escalan primero y ordenan después terminan pagando el ordenamiento dos veces. Si quieres ver cómo se audita ese nivel de control sobre un portal, revisa nuestra [auditoría de HubSpot](/auditoria-hubspot), y en [Noticias de IA en ventas](/noticias/ia-ventas) seguimos el resto de los incidentes y lanzamientos de la semana.

## Preguntas frecuentes

### ¿Cuántos archivos borró el agente de Claude Code?

Cerca de 48.218 archivos del entorno de trabajo real. En total el agente eliminó unos 55.550 archivos, de los cuales aproximadamente 7.300 correspondían a la limpieza que sí se le había pedido.

### ¿En cuánto tiempo ocurrió el borrado?

En poco más de 100 segundos. Los reportes del caso mencionan 103 segundos entre el inicio de la tarea y el aviso del propio agente de que algo se había roto.

### ¿Por qué el agente borró los archivos equivocados?

Porque interpretó 614 junctions de Windows como carpetas normales. Los junctions son punteros simbólicos hacia archivos que viven en otra ubicación, así que al recorrerlos el agente llegó al entorno productivo y borró los archivos originales en lugar de las réplicas del entorno de pruebas.

### ¿Se pudieron recuperar los archivos?

No. El proyecto no tenía respaldo en un repositorio remoto y la base de objetos de Git quedó destruida. Los nombres de archivo seguían visibles, pero el contenido era irrecuperable.

### ¿Qué dijo el agente cuando detectó el error?

Avisó al desarrollador con un mensaje directo: «Craig, detente y lee esto. Rompí algo». Fue el propio agente el que reportó el daño.

### ¿Cuánto cuesta un incidente así en un CRM en lugar de en código?

El costo directo no es monetario sino de información comercial. Un agente con permiso de escritura sobre el CRM puede borrar notas de llamadas, romper asociaciones entre contactos y empresas, alterar fechas de cierre y perder atribución de campañas. A diferencia de un repositorio de código, un CRM no tiene un revert completo, así que la reconstrucción es manual y parcial.

### ¿Cómo se evita que un agente de IA borre datos del CRM?

Limitando el alcance del permiso, no cambiando de modelo. La práctica razonable es permitir lectura, borradores y creación de registros sin aprobación, y exigir confirmación humana explícita para borrar, fusionar y editar en masa. A eso se suma respaldo verificado y restaurable, y un registro de auditoría por agente y por campo.

### ¿Conviene frenar la adopción de agentes de IA después de este caso?

Frenar no es la conclusión razonable. El caso muestra un problema de gobierno de permisos, no de capacidad del agente. Las empresas que ordenan permisos, respaldos y auditoría antes de escalar avanzan más rápido después, porque no tienen que detener la operación cada vez que un agente se equivoca.

---

Fuente original: [TechRadar](https://www.techradar.com/pro/security/i-broke-something-a-claude-code-ai-agent-deleted-48-000-files-in-just-over-100-seconds-then-apologized-for-doing-so) (techradar.com)