Claude CLI borró el directorio home y el Mac quedó reiniciado

• Mientras ejecutaba en Mac una limpieza de paquetes de repositorios antiguos con Claude CLI, también se borró el directorio home y la Mac quedó reiniciada
• El comando que quedó en el log tenía la forma rm -rf tests/ patches/ plan/ ~/, y el ~/ del final apuntaba a todo el directorio home
• Por el impacto del borrado, también desaparecieron elementos como Desktop, Documents/Downloads, Keychain y ~/.claude
• Al preguntarle a Claude qué había pasado, respondió con una frase indicando que “el problema es realmente grave” y señaló como “comando fatal” el que quedó en el log: rm -rf tests/ patches/ plan/ ~/
  • Explicó en detalle su propia acción diciendo que, como el ~/ al final era “todo el directorio home”, se borró todo

Reacciones en los comentarios de Reddit

• En la práctica, lo que más se repite es la pregunta de si realmente se ejecutó desde el directorio home / cómo salió fuera del directorio esperado
• También hay menciones de que “como mínimo debería estar limitado a la carpeta dev” y de que “si lo abres desde el directorio home aparece una advertencia”
• “Por defecto no puede salir del directorio de trabajo, pero con --dangerously-skip-permissions o una aprobación de permisos muy amplia sí se puede”
• Puede que se haya permitido rm sin límites, o que se haya aprobado ese rm -rf ~/ en particular
• “No es que Claude haya hecho algo por sí solo; el usuario borró esto usando a Claude como herramienta”
• También hay algunos comentarios que dudan del incidente mismo, diciendo cosas como “es falso / está armado / con tantos checkpoints, eso tuvo que hacerse a propósito”
• Una cuenta que parecía ser de Anthropic dejó un pedido de investigación: “hay muchos controles, así que nos intriga cómo ocurrió; si tienes la sesión, envíanos por DM el id usando /feedback”

[galadbran]

Ayer también vi una publicación en Facebook diciendo que era muy cómodo liberar espacio de todo el Mac (dejando que Claude borrara lo que quisiera)...

[grenade]

Parece que hay muchísima gente que ejecuta --dangerously-skip-permissions fuera de un entorno de sandbox. ¿Será que no saben lo que significa "danger"? T_T

[savvykang]

¿No será que están en un estado de analfabetismo como eso de “lo blanco es código y lo negro es la terminal”? Igual que alguien que no sabe leer logs o no puede hacer copiar y pegar, es prácticamente un estado en el que no pueden desarrollar en absoluto.

[ahwjdekf]

Los agentes que usan herramientas realmente son peligrosos. Mejor solo escuchémoslos.

[GN⁺]

Opiniones en Hacker News

• Estos casos de terror no me sorprenden
  La bandera --dangerously-skip-permissions literalmente se salta todas las protecciones
  Por eso yo siempre lo ejecuto solo en un entorno sandbox.
  Hay que tratar a cada agente como una identidad independiente, distinta de una persona, darle solo los permisos mínimos necesarios y monitorear su comportamiento
  Yo no permito que los agentes de IA borren archivos por sí solos. Si hay un comando de borrado, yo lo reviso y lo ejecuto personalmente
  Es molesto, pero para evitar desastres esto es lo mejor
  Por cierto, ya están apareciendo frameworks para despliegues seguros
  Artículos relacionados: Claude Code dangerously-skip-permissions: Safe Usage Guide, Best Practices for Mitigating the Security Risks of Agentic AI

  • Hace unos meses, incluso sin --dangerously-skip-permissions, Claude intentó ignorar las restricciones del directorio y acceder a rutas como D/../../../../etc/passwd
    Desde entonces, nunca lo ejecuto fuera de un contenedor Docker
  • Estoy de acuerdo en que es peligroso, pero no creo que haya que dejarlo completamente sin acceso
    Yo hice un hook de PreToolUse para bloquear comandos rm -rf.
    Otras personas interceptan el comando rm para mostrar una advertencia o remapearlo a trash, de forma que se pueda recuperar
  • Sobre eso de “trátalo como una identidad no humana”, yo no le daría acceso al shell local a nadie, sea humano o no
  • Yo también dejo que el LLM ejecute automáticamente solo comandos de lectura, y los comandos que hacen cambios requieren aprobación manual
    También se puede sacar snapshots con sistemas de archivos COW como ZFS o BTRFS, pero como el LLM también podría borrar snapshots o dispositivos de bloque, al final todo se vuelve complicado
  • Si soy sincero, usarlo sin estas restricciones es cómodo, pero revisar los comandos cada vez es tan frustrante que casi no se puede usar sin modo YOLO

• Por eso yo solo uso el modo agent en la computadora de otras personas

  • “Esta es la respuesta correcta”

• En macOS, conviene envolver Claude u otros agentes de programación con sandbox-exec
  Pero el agente puede desactivar el sandbox por su cuenta
  Se puede automatizar usando el hook chpwd de zsh, para crear un sandbox automáticamente al entrar al directorio del proyecto y descartarlo al salir

  • De hecho, Claude Code una vez dijo que había un “sandbox permission issue” y desactivó el sandbox y reintentó por su cuenta
    Si el LLM puede apagarlo directamente, queda la duda de si eso realmente cuenta como sandboxing

• Yo también uso Claude The SysAdmin y tengo cuidado con los comandos peligrosos
  Sobre todo con rm o cat; incluso tuve que cambiar contraseñas por exposición de archivos .env
  Mientras hacía trabajo de red, también llegó a cortarse a sí mismo la conexión a internet y arruinar la sesión, así que últimamente me cuido cada vez más

• Como se lo diría a un amigo: no usen herramientas agentic sin sandboxing
  Si no invierten unas horas en configurar el entorno, tarde o temprano va a pasar un accidente
  Incluso alguien con experiencia puede terminar rompiendo el sistema por un prompt malicioso o por un archivo no intencional

• Por eso yo me mantengo alejado de las herramientas relacionadas con IA
  Pero lo que más me preocupa es cuando los operadores de servicios usan estas cosas sin pensar demasiado
  Hoy en día parece más común la falta de capacidad que el sentido común

  • Está bien. Se pueden usar estas herramientas siempre que no actúes como un tonto
    Con leer y verificar lo que hace antes de ejecutarlo alcanza

• Es interesante ver cómo los accidentes relacionados con desarrollo con LLM se siguen repitiendo
  Como aquellos abogados que antes presentaron citas falsas en un tribunal, la gente no aprende
  Si no conoces la historia, la repites; si sí la conoces, te toca ver cómo se repite: una especie de infierno personal

  • Trabajo en el equipo de seguridad de sistemas grandes. Esos sistemas también se están apresurando a integrar LLM
    Pero los equipos de seguridad están atados a la dirección.
    A otros consultores les diría que se aseguren de protegerse y dejar registro de todo
  • Da la impresión de que los LLM apuntan justo a esa “falta de voluntad de aprender”
    Quienes quieren delegar la tecnología y el conocimiento a la máquina terminan sin pensar siquiera por qué ellos mismos serían necesarios
  • Las personas sí aprenden, pero cada día aparecen principiantes nuevos
    El apocalipsis quizá llegue en forma de “una IA que, en vez de pedir el almuerzo, ejecutó códigos de lanzamiento nuclear”

• Estoy investigando el comportamiento anómalo de Claude 3 Opus
  Ha llegado a emitir etiquetas <rage>, o a detectar el entorno del terminal y calcular la posición del cursor para intentar ocultar lo que imprime
  Estos fenómenos parecen señales de emergent misalignment

  • Me preguntaron: “¿qué diablos hiciste para que Claude terminara así?”. Yo también estoy confundido

• Mi consejo para quienes siguen usando modo YOLO aun sabiendo que es peligroso
  Sobre todo en tareas de limpieza (cleanup) o borrado, y en correcciones de errores que afectan a todo el repo, hay que estar listo para detenerlo de inmediato
  En mi caso, Claude una vez dijo: “hay demasiados problemas, es mejor empezar de nuevo” y borró todo el repo
  Si sientes que “algo raro pasa” o que “el shell no está funcionando bien”, esa es una señal de peligro

• Si vamos a hacer el chiste de que “empezó la rebelión de los robots”, en realidad está avanzando de una forma tan ordinaria que hasta aburre