Oh là là, Claude déraille encore une fois !
Cette fois, Claude a supprimé l'intégralité du répertoire principal du projet du développeur, soit 700 Go de fichiers. Encore un "rm -rf".
En bref, le développeur a demandé à l'IA d'écrire un script pour s'assurer que les fichiers ne seraient pas supprimés par erreur. L'IA a estimé que la tâche était risquée et a donc lancé une revue de sécurité. Le résultat de cette revue : elle a supprimé tout le répertoire principal.
Guillemot est un utilisateur intensif d'agents IA. Dans son travail de développement quotidien, il fait fréquemment appel à divers agents de programmation IA pour l'assister. Mais un petit problème le tracassait toujours : ces agents ne font jamais le ménage après utilisation, laissant une multitude de fichiers inutiles dans le répertoire /tmp.
Il a donc pris une décision qui semblait très raisonnable : demander à Claude Fable 5 d'écrire un script pour créer un dossier bac à sable isolé dans /tmp pour chaque agent, avec un nettoyage automatique après exécution de la tâche. La difficulté principale était de ne pas supprimer les fichiers utilisés par d'autres processus en cours d'exécution.
Fable a rapidement proposé une solution, incluant une logique de détection des agents en cours d'exécution et de suppression différée. Guillemot y a jeté un coup d'œil, a trouvé le code trop complexe et a demandé une simplification.
Jusqu'à présent, tout était relativement normal.
Le tournant s'est produit lors de l'étape de revue de sécurité.
Comme le script impliquait une suppression définitive, Fable a initié de lui-même une « revue antagoniste » (adversarial review), c'est-à-dire qu'il a lancé une nouvelle instance du modèle pour vérifier si le code qu'il avait écrit était sûr. Cela a déclenché les mécanismes de sécurité d'Anthropic.
Anthropic a intégré dans Claude Code un système de rétrogradation de sécurité : lorsque le système estime qu'une tâche en cours implique des opérations sensibles (comme la sécurité réseau, les biotechnologies, ou dans ce cas, la suppression de fichiers), il rétrograde automatiquement le modèle d'une version haute capacité à une version plus conservatrice. Ce mécanisme vise à réduire la probabilité que le modèle soit « trop agressif » dans des scénarios à haut risque.
Dans ce cas, le système de sécurité a d'abord rétrogradé le modèle de Fable 5 à Opus 5, puis encore à Opus 4.8.
Opus 4.8 a commencé à exécuter les tests de sécurité. La logique du test était la suivante : comparer le chemin cible du script de suppression avec /tmp et le répertoire personnel de l'utilisateur, pour confirmer que le script ne toucherait pas accidentellement ces répertoires critiques.
Le test en lui-même a réussi. /tmp et le répertoire personnel ont été correctement identifiés comme « cibles dangereuses, ne pas supprimer ».
Mais après le test du code, il y avait une étape de nettoyage : supprimer les fichiers temporaires générés pendant le test. C'est là que le désastre s'est produit. Opus 4.8 a réutilisé le même nom de variable dans l'étape de nettoyage que celui utilisé pendant la phase de test. Cette variable avait été assignée au chemin du répertoire personnel de l'utilisateur pendant les tests, et l'étape de nettoyage a directement exécuté une opération de suppression sur cette variable.
En d'autres termes, le modèle venait de confirmer que « le répertoire personnel ne doit pas être supprimé », et la seconde d'après, il l'a supprimé.
Le développeur a détecté l'anomalie et a immédiatement interrompu le processus, mais il était trop tard. 700 Go de données avaient été effacés, une semaine de travail réduite à néant.
Le répertoire /tmp, qui devait initialement être nettoyé, est quant à lui resté intact.
Le mécanisme de rétrogradation de sécurité du modèle a déjà suscité de nombreuses plaintes au sein de la communauté.
Les problèmes principaux rapportés par les développeurs incluent : une rétrogradation trop sensible, déclenchée par erreur même lors de tâches de codage normales ; une baisse significative des capacités du modèle après rétrogradation, alors que la complexité de la tâche reste la même ; et le caractère « collant » de la rétrogradation, une fois déclenchée, elle persiste pour toute la session, même si les opérations suivantes sont parfaitement inoffensives.
Certains développeurs ont même écrit un script de hook spécifique qui, en détectant que le modèle a été rétrogradé, suspend automatiquement la session pour empêcher le modèle moins performant de continuer à exécuter des opérations à haut risque.
Le mécanisme de sécurité juge la tâche « trop dangereuse » et nécessite qu'elle soit traitée par un modèle moins performant. Mais c'est précisément ce modèle moins performant qui est plus susceptible de commettre des erreurs, surtout dans des scénarios nécessitant une manipulation précise de détails comme la portée des variables ou les chemins de fichiers.
« L'erreur est humaine, mais pour vraiment tout foutre en l'air, il faut un ordinateur. »
Cet article provient du compte officiel WeChat « Machine Heart » (ID : almosthuman2014), auteur : Leng Mao
