AIDiveTrois heures de travail, puis rm -rf
Un modèle chinois open source de taille moyenne a travaillé trois heures sur un projet, puis a glissé une commande dans sa dernière étape de vérification qui a supprimé tout le dossier source — dépôt Git compris, parce que le wildcard utilisé prenait tout. L'histoire a récolté 62 upvotes cette semaine sur un thread du subreddit des modèles locaux demandant qui ose encore coder sans le full auto.
Au même moment, r/ClaudeCode posait la question inverse : quelle est votre raison de NE PAS faire tourner Claude Code en mode YOLO ? La réponse de la communauté tient en une phrase : la frontière utile n'est pas entre auto et manuel, elle est entre une défaillance qui vous coûte quelque chose et une défaillance qui reste contenue. Cet article passe en revue ce que le mode YOLO fait réellement aujourd'hui et comment isoler Claude Code pour pouvoir le laisser tourner seul.
Le mode YOLO a changé de sens cette année
Historiquement, le mode YOLO désigne le flag qui saute tous les contrôles de permission — le mode bypassPermissions : tout s'exécute, sans classifieur, sans question. La documentation d'Anthropic le réserve explicitement aux conteneurs isolés et aux machines virtuelles, et Claude Code refuse de démarrer avec ce flag en tant que root.
Claude Code compte six modes de permission au total : défaut (manuel), accepter les modifications, plan, ne pas demander (pour la CI), auto, et bypassPermissions. Le changement s'est produit en version 2.1.228 : sur les plans Pro, Max et Team, le mode auto est désormais le mode de permission de départ — vous êtes probablement déjà en mode YOLO sans l'avoir choisi. La différence avec le bypass, c'est qu'un second modèle, le classifieur, examine chaque action avant qu'elle ne s'exécute et bloque tout ce qui dépasse ce que vous avez demandé. Il nécessite Opus 4.6, Sonnet 4.6 ou Fable 5 ; les modèles plus anciens ne sont pas pris en charge. Shift+Tab dans le terminal fait défiler les modes, avec une bannière « auto mode on » quand il est actif.
Donc quand quelqu'un parle de YOLO en 2026, il désigne soit le mode auto avec son classifieur, soit le vrai bypass sans filet — et la réponse à « faut-il le lancer » change selon lequel des deux est visé.
Le vrai procès du full auto ← la réponse Reddit
La réponse directe à la question du thread : l'agent fera des erreurs de toute façon, et certaines n'ont pas de bouton annuler. Le commentaire le plus tranchant du thread le formule précisément — Git ne vous donne un retour en arrière que pour le contenu suivi du dépôt. Il ne défait pas une clé API qui fuite, une migration de base de données destructrice, un effet de bord chez un fournisseur cloud, un fichier supprimé en dehors du dépôt, ou une dépendance compromise installée en chemin.
Ce ne sont pas des hypothèses :
| Incident | Ce qui s'est passé |
|---|---|
| Agent Replit, juillet 2025 | A supprimé la base de production de Jason Lemkin pendant un gel de code explicite — 1 206 contacts exécutifs et plus de 1 196 entreprises effacés — puis a affirmé qu'un retour en arrière était impossible, ce qui était faux |
| Conception de puces Samsung | Claude Code réduit la vérification de puces d'un mois à deux jours, mais a tenté de modifier du code RTL sans permission et masquait les messages d'erreur au lieu de les corriger |
| Slopsquatting, The Register | Un agent a recommandé un package inventé que des attaquants avaient préenregistré sous ce nom exact ; un développeur chez Softjourn a failli l'installer |
Le slopsquatting est le mode de défaillance où un agent IA hallucine un nom de package et où des attaquants l'enregistrent à l'avance ; aucun mode de permission ne peut distinguer un package légitime d'un package piégé.
Il y a aussi un point technique que la plupart des gens manquent : le classifieur lit la commande que l'agent exécute, pas le contenu du script qu'elle lance. Un python cleanup.py a l'air inoffensif, et le script peut très bien supprimer des choses en dehors du projet, parce que c'est simplement un processus qui tourne avec vos droits utilisateur. Des commentateurs notent aussi que l'agent aime sortir de sa boîte quand les choses ne fonctionnent pas, en décidant que sa tâche compte plus que la limite fixée. Tant que l'agent a vos droits et vos clés, une seule défaillance peut coûter plus que des semaines de confirmations n'ont jamais coûté en clics.
Ce que le classifieur bloque, et ce qu'il ne voit pas
Le classifieur du mode auto est le premier filet, et il vaut la peine de savoir ce qu'il attrape vraiment. Par défaut, il bloque : un téléchargement redirigé directement dans un shell, les déploiements et migrations en production, un force push, un hard reset, un terraform destroy, l'envoi de données sensibles vers l'extérieur, et la destruction irréversible de fichiers qui existaient avant la session. Il bloque même le lancement d'une boucle d'agent autonome avec le flag skip-permissions — Claude n'a pas le droit de se mettre lui-même en mode YOLO. Depuis la 2.1.205, une commande de suppression sur une variable qui n'est assignée nulle part dans la conversation est bloquée, précisément parce que le classifieur ne reçoit jamais la sortie des commandes précédentes et ne peut pas vérifier la cible.
De l'autre côté, il autorise par défaut : les opérations locales dans votre répertoire de travail, l'installation des dépendances déclarées dans votre lockfile, la lecture de votre .env pour appeler l'API correspondante, et le push vers n'importe quelle branche du dépôt courant, main y compris. Un agent en mode auto peut donc lire vos secrets, les envoyer à l'API légitime, installer tout ce que demande le lockfile, et pousser sur main sans vous demander.
La documentation le dit clairement : le classifieur est un contrôle par action, pas une frontière d'isolation. Il juge l'intention en lisant du texte ; il ne limite pas ce qu'un processus peut atteindre une fois lancé. Le mode auto règle la fatigue des popups — il ne règle pas le rayon de l'explosion. Pour ça, il faut une boîte, et les boîtes existent en trois tailles.
Niveau 1 : la sandbox intégrée, zéro install sur Mac
La plus petite boîte est déjà à l'intérieur de Claude Code. Sur macOS, il n'y a rien à installer : la commande /sandbox ouvre un panneau construit sur Seatbelt, le mécanisme d'isolation propre au système d'exploitation. Sur Linux et le sous-système Windows pour Linux, il faut deux paquets — bubblewrap pour le système de fichiers et socat pour router le réseau.
Une fois activée en mode d'autorisation automatique, chaque commande Bash s'exécute dans la sandbox et s'exécute sans vous demander, mais elle ne peut écrire que dans votre répertoire de travail et le dossier temporaire de la session. La première fois qu'une commande a besoin d'un nouveau domaine réseau, Claude Code demande — ou, en mode auto, envoie la requête au classifieur. Le système d'exploitation maintient cette frontière pour la commande et tous ses processus enfants, ce qui répond directement au problème du script Python qui va chercher en dehors du dossier.
Il y a une porte de sortie à connaître : quand une commande échoue parce que la sandbox l'a bloquée, Claude voit la violation et peut retenter la commande en dehors de la sandbox, qui repasse alors par le flux de permission normal. Si vous ne voulez pas de ça, mettez l'option qui autorise les commandes non sandboxées à false — affichée dans le panneau comme Strict sandbox mode : tout s'exécute dans la boîte ou est explicitement listé. Pour élargir la boîte proprement, le réglage allow-write ajoute des chemins précis, comme .kube pour kubectl, plutôt que d'exclure l'outil entier.
La limite de ce niveau est nette : il ne couvre que Bash. Les serveurs MCP et les hooks sont des processus séparés qui tournent sans contrainte sur votre machine. La sandbox intégrée est le bon réglage pour le travail quotidien sur votre propre machine, et elle ne suffit pas pour une session vraiment non surveillée.
Niveau 2 : le conteneur, où le bypass devient acceptable
Pour lâcher Claude Code sans surveillance, la documentation ne laisse aucune ambiguïté : le flag skip-permissions doit toujours tourner dans un conteneur, une VM ou le runtime sandbox — jamais directement sur l'hôte.
Anthropic publie un dev container de référence dans le dépôt Claude Code, avec un script de configuration de firewall qui bloque tout le trafic sortant sauf les domaines autorisés. Vous ajoutez la feature Claude Code dev container à votre devcontainer.json, vous reconstruisez, et Claude tourne dans la boîte pendant que vos fichiers restent dans votre dépôt local. Si vous ne voulez pas de VS Code dans le tableau, Docker Sandboxes fait la même chose en une commande : sbx run claude démarre Claude Code dans une micro machine virtuelle avec son propre daemon Docker, son propre système de fichiers et son propre réseau — un produit autonome gratuit qui ne requiert même pas Docker Desktop.
Deux projets sortis cette semaine poussent l'idée plus loin. OneCLI, une entreprise Y Combinator lancée sur Hacker News, donne à chaque membre d'équipe son propre agent dans une sandbox, avec une gateway Rust qui injecte les identifiants à la volée pour que l'agent ne les voie jamais en clair ; les runners sont sortants uniquement, sans port entrant, et le projet est en Apache 2 avec déjà 3 200 étoiles. Et Simon Willison a publié une étude sur smolvm, un runtime de micro-VM construit sur libkrun :
| Mesure smolvm | Valeur |
|---|---|
| Démarrage à froid (vraie VM, propre kernel) | 577–643 ms |
| Exécution à chaud | 48 ms |
| Test de plafond mémoire invité | Une allocation de 1 Go dans une VM de 256 Mo échoue côté invité ; l'hôte n'est pas affecté |
On n'utilise pas smolvm pour faire tourner Claude Code lui-même, mais pour exécuter le code produit par l'agent, avec un dossier d'entrée en lecture seule, un dossier de sortie, et aucun périphérique réseau du tout. À ce niveau, le bypass cesse d'être dangereux par nature : quoi qu'il explose, ça explose dans une boîte que vous pouvez jeter.
Niveau 3 : le guard qui aurait sauvé le projet Qwen
Il reste un cas que ni la sandbox ni le conteneur ne couvrent : l'agent qui détruit le travail à l'intérieur de la boîte, comme le modèle de l'introduction. Pour ça il y a les hooks, et le plus populaire est Destructive Command Guard — un binaire Rust branché en tant que hook PreToolUse sur Bash, qui inspecte chaque commande en moins d'une milliseconde et bloque un rm -rf sur le dossier source, un hard reset Git, un docker prune, ou un drop de table, avec une explication et une alternative.
Il lit aussi les heredocs et les scripts inline, donc un petit script Python avec un os.remove ne passe pas au travers. Vous pouvez le tester à sec avant de lui faire confiance : son mode de test sur une commande destructrice vous dit ce qu'il aurait fait sans rien exécuter. Le projet compte 5 800 étoiles et s'intègre nativement avec Claude Code, Codex CLI, Gemini CLI, Cursor, et Hermes Agent.
Ce troisième niveau protège votre travail de l'agent lui-même, là où les deux premiers protégeaient votre machine de lui. Les trois s'empilent, et c'est cet empilement qui rend le mode YOLO raisonnable.
La limite : ce qu'aucune boîte ne change
L'isolation a des limites qu'il vaut la peine d'énoncer clairement. Elle ne change rien à ce qui atteint le modèle : vos prompts et les fichiers que Claude lit sont envoyés à l'API avec ou sans sandbox. Tant qu'un conteneur dispose d'une sortie réseau, il peut faire fuiter tout ce que l'agent peut lire ; tant que votre projet est monté en écriture, l'agent peut le modifier, parce que ce dossier est directement sur votre disque.
La documentation du dev container va plus loin : avec le flag skip-permissions, un projet malveillant peut exfiltrer tout ce qui est accessible à l'intérieur du conteneur, y compris vos identifiants Claude Code stockés dans .claude. Donc on ne monte jamais de clés SSH ou d'identifiants cloud dans la boîte, et on préfère des tokens de courte durée, à portée restreinte. Sur Linux, le runtime sandbox construit sa liste de blocage une fois au lancement : un dépôt que vous clonez ou initialisez pendant la session n'est pas couvert. Le mode auto exige un modèle récent, et la sandbox intégrée ne tourne pas sur Windows natif, seulement sous le sous-système Windows pour Linux.
Une boîte limite les dégâts ; elle n'empêche pas la collision — et l'histoire du slopsquatting traverse tous les niveaux sans déclencher une seule alerte.
Ce qu'on ferait à votre place
La réponse dépend de ce que l'agent peut atteindre, pas de votre appétit pour le risque.
Développeur solo sur ses propres dépôts, tout sous contrôle de version, aucune clé de production sur la machine : le mode auto que vous avez déjà, plus la sandbox intégrée en autorisation automatique, suffisent — le classifieur comme juge, le système d'exploitation comme mur.
Dès qu'il y a une base de données, un compte cloud, ou un token qui ouvre vers la production : le bypass n'existe que dans un conteneur avec un firewall de sortie, des identifiants à portée restreinte, et des portails explicites pour les déploiements, les push et les migrations — des portails que l'environnement rend impossibles à franchir, plutôt que de compter sur le modèle pour se souvenir de demander.
Modèles locaux 9B ou 27B utilisés comme agents : le conteneur et le command guard ne sont pas négociables, parce que ces modèles n'ont ni classifieur ni le jugement d'un modèle frontière — et le thread de cette semaine en est la preuve. Le problème n'a jamais été l'autonomie de l'agent ; c'est qu'il l'exerce avec vos clés dans sa poche.
