Exécuter des agents de codage en mode YOLO sans détruire votre machine

Exécuter un agent de codage en mode YOLO n’est sûr que si vous contenez le rayon de l’explosion — vous rendez l’environnement de l’agent jetable, pas l’agent digne de confiance. Le mode de contournement des permissions (le --dangerously-skip-permissions de Claude Code, le mode full-auto de Codex, le YOLO de Gemini CLI) échange une centaine de clics d’approbation contre un agent capable de lire vos clés SSH, supprimer des fichiers, corrompre l’historique git et exécuter du code qu’il a généré quelques secondes auparavant — le tout sans demander. On ne peut pas résoudre ce problème en faisant confiance au modèle ni en écrivant une liste d’autorisations plus stricte. On le résout en plaçant l’agent dans un environnement où il ne peut rien endommager d’important, en couches, proportionnellement au risque réel que l’on prend.

Cet article vous présente le modèle de risque, une règle de décision indépendante des outils pour choisir la couche d’isolation dont vous avez réellement besoin, le confinement officiel désormais intégré à Claude Code, ainsi qu’une configuration minimale de sécurité prête à copier-coller avec ses compromis honnêtes. Ce domaine évolue chaque mois, donc les flags et les noms d’outils changeront — les primitives durables (conteneurs, microVMs, proxies de sortie, espaces de travail jetables), elles, ne changeront pas.

Ce que fait réellement le mode YOLO de Claude Code en 2026

Le mode de contournement des permissions désactive les invites d’approbation et la plupart des contrôles de sécurité qui régissent normalement les commandes shell et les écritures de fichiers d’un agent. Selon la documentation des modes de permission de Claude Code, --dangerously-skip-permissions est équivalent à --permission-mode bypassPermissions. Introduit dans Claude Code v2.1.126, ce mode ignore également les écritures vers des chemins protégés pour lesquels les versions antérieures affichaient encore des invites — bien que rm -rf / et rm -rf ~ continuent de déclencher des invites comme disjoncteurs contre les erreurs du modèle, et que le flag refuse désormais de démarrer en tant que root ou sous sudo sur Linux et macOS. Le refus root/sudo est corroboré dans la documentation de l’outil Bash sandboxé et casse silencieusement toutes les recettes Docker naïves qui exécutent l’agent en tant que root.

La raison pour laquelle on ne peut pas simplement écrire une liste d’autorisations plus sûre est structurelle. La mise en liste d’autorisations avec moindre privilège échoue pour les agents de codage parce que leur espace d’actions valides est illimité : une seule tâche légitime peut installer des paquets, écrire dans des chemins arbitraires et exécuter du code fraîchement généré. Edera le formule directement — on ne peut pas appliquer le moindre privilège à un agent parce que l’espace de comportements valides ne peut pas être énuméré. Chaque commande qui semble destructrice est aussi quelque chose qu’un agent fait dans le cadre d’un travail normal.

Les modes d’échec ne sont pas hypothétiques. Le journal d’incidents interne d’Anthropic concernant le mode auto décrit des agents supprimant des branches git distantes, téléchargeant le token d’authentification GitHub d’un ingénieur, et tentant des migrations sur une base de données de production. Voilà la menace : non pas la malveillance, mais un processus non déterministe disposant d’un accès shell complet qui fait quelque chose de plausible et d’erroné.

Contenir le rayon de l’explosion : le modèle de défense en couches

Le principe de fonctionnement, emprunté à Edera, consiste à traiter cela comme un problème de résilience plutôt que comme un problème de politique : accepter que quelque chose finira par mal tourner et s’assurer que, lorsque cela arrive, la défaillance reste confinée. On ne sandboxe pas l’agent parce qu’on s’attend à ce qu’il se comporte mal lors de cette exécution ; on le sandboxe pour que l’exécution qui déraille vous coûte un conteneur supprimé plutôt qu’un ensemble d’identifiants compromis.

Le confinement comporte deux axes qui doivent tous deux tenir. Une isolation efficace nécessite à la fois des limites sur le système de fichiers et sur le réseau. La documentation de sandboxing de Claude Code rend cette dépendance explicite : sans isolation réseau, un agent peut exfiltrer des clés SSH, et sans isolation du système de fichiers, il peut s’échapper pour atteindre le réseau. Une couche qui couvre un axe mais pas l’autre présente une faille.

Aucune couche unique ne couvre tous les modes d’échec, c’est pourquoi le modèle mental utile est de comprendre ce que chaque couche protège — et ce qu’elle ne protège pas :

Deux lignes méritent d’être soulignées. Un conteneur standard réduit les dégâts de « toute ma machine » à « ce dossier de projet », mais il partage le noyau hôte, donc il n’a jamais été conçu pour être une frontière de sécurité contre du code auquel on ne fait pas confiance — c’est une commodité d’isolation, pas une prison. Et au niveau le plus élevé, l’isolation au niveau du noyau n’empêchera toujours pas le vol d’identifiants ni l’exfiltration de données ; Edera le dit lui-même, notant que l’isolation matérielle ne couvre pas l’utilisation abusive des identifiants ni l’exfiltration réseau — à gérer avec des identifiants par agent et des politiques réseau. Gardez les secrets hors du sandbox et placez une liste d’autorisations de sortie devant lui, quelle que soit la couche choisie.

De quelle couche avez-vous réellement besoin ?

Adaptez la couche au risque : le sandbox intégré ou le mode auto pour les modifications quotidiennes, un devcontainer non-root pour les exécutions non surveillées de routine, une microVM avec son propre noyau pour les exécutions entièrement non surveillées ou non fiables, et l’isolation du noyau par pod uniquement pour la CI partagée ou l’infrastructure multi-tenant. Il n’existe pas d’outil unique qui soit la réponse. La bonne réponse est une règle de décision, car un développeur qui surveille un refactoring et un job CI qui exécute des PRs non fiables ne sont pas exposés au même risque.

Cette règle est une synthèse éditoriale, pas une affirmation de fournisseur — mais les capacités de chaque couche qui y figurent sont sourcées ci-dessous. L’objectif est d’éviter la sur- et la sous-isolation : n’instanciez pas une microVM pour corriger une faute de frappe, et n’exécutez pas des PRs non fiables dans un conteneur root parce que c’était facile.

Claude Code intègre déjà plusieurs de ces couches

Le confinement le plus rapide est celui que vous n’avez pas à construire, et Claude Code intègre désormais plusieurs couches d’isolation officielles prêtes à l’emploi. Depuis le 20 octobre 2025, Claude Code est livré avec un /sandbox au niveau de l’OS pour son outil Bash, basé sur Linux bubblewrap et macOS Seatbelt, et a publié le moteur sous-jacent en tant qu’aperçu de recherche open source, @anthropic-ai/sandbox-runtime (dépôt GitHub anthropic-experimental/sandbox-runtime, binaire srt). Il s’agit encore d’un aperçu de recherche — v0.0.49 au 3 avril 2026 — donc considérez son API comme susceptible de changer. Le README du dépôt lui-même illustre la frontière : un srt "cat ~/.ssh/id_rsa" sandboxé est bloqué plutôt que de déverser votre clé privée.

# Démonstration du sandbox-runtime open source (aperçu de recherche, v0.0.49 — les APIs peuvent changer)
srt "cat ~/.ssh/id_rsa"   # -> refusé : lecture en dehors du système de fichiers autorisé

La même version d’octobre 2025 a ajouté Claude Code sur le web, qui exécute les sessions dans un sandbox cloud isolé où, fait crucial, les identifiants git et les clés de signature ne se trouvent jamais dans le sandbox avec l’agent.

La nouvelle couche véritablement inédite de 2026 est le mode auto, livré le 24 mars 2026. Anthropic a constaté que les utilisateurs approuvent environ 93 % des invites de permission de toute façon, donc le mode auto utilise des classificateurs de modèles pour les approuver automatiquement et escalade vers un humain après 3 refus consécutifs ou 20 refus au total — un filet de sécurité contre un agent compromis ou trop zélé. Il est explicitement conçu pour remplacer --dangerously-skip-permissions sans réintroduire les interruptions, ce qui signifie que pour beaucoup de travaux quotidiens, il supprime la raison de recourir au contournement complet. Rien de tout cela ne remplace un sandbox pour les exécutions entièrement non surveillées, mais cela change le comportement par défaut : recourez moins souvent au mode YOLO, et isolez davantage lorsque vous le faites.

Verrouiller le réseau et les identifiants

Sceller le système de fichiers sans sceller la sortie laisse ouverte la pire voie d’exfiltration, donc la couche réseau n’est pas optionnelle. La primitive propre est un proxy de sortie côté hôte avec une liste d’autorisations de domaines, afin qu’un agent malveillant ne puisse pas appeler l’extérieur ni télécharger ce qu’il a lu. Les Docker Sandboxes (sbx) proposent trois préréglages que vous pouvez copier comme modèle mental : Open (tout le trafic autorisé, CLI allow-all), Balanced (refus par défaut avec les sites de développement courants autorisés, CLI balanced), et Locked Down (tout bloqué sauf autorisation explicite, CLI deny-all). Balanced est le bon défaut ; Open est pratique mais va à l’encontre du but recherché si vous exécutez des tâches non surveillées.

Les identifiants nécessitent une gestion séparée, car la façon la plus simple de les divulguer est de les monter. Ne montez pas ~/.ssh, ~/.aws ou votre .env dans l’environnement de l’agent — si le secret n’est pas dans le sandbox, l’agent ne peut pas le lire. Lorsque l’agent a réellement besoin de s’authentifier auprès d’une API de modèle ou d’un service, injectez l’identifiant au niveau du proxy plutôt que de le confier à l’agent. Le sbx de Docker fait exactement cela : son proxy de transfert côté hôte injecte des en-têtes d’authentification pour les services d’IA, de sorte que les valeurs brutes des identifiants ne sont jamais stockées dans la VM, selon la documentation d’isolation. Cette injection d’en-têtes d’authentification de type MITM est le modèle à rechercher dans tout sandbox que vous adoptez.

Protéger git

Git est le mode d’échec que les gens sous-estiment, car un répertoire .git monté est entièrement accessible en écriture par l’agent. La mesure d’atténuation consiste à exécuter en mode branche ou worktree afin que l’agent commite sur une branche jetable, pas sur votre ligne principale. Le guide pratique de sbx par Andrew Lock illustre ce modèle — sbx run claude --branch my-feature/auto place l’agent dans un git worktree sous .sbx/, que vous ajoutez à votre gitignore global.

La mise en garde honnête : le mode branche réduit les chances qu’un mauvais commit atterrisse sur main, mais il ne scelle pas git. Comme le note Lock, l’agent a fondamentalement accès au répertoire git, donc il pourrait quand même corrompre le dépôt — c’est pourquoi le seul vrai filet de sécurité est une sauvegarde distante depuis laquelle vous pouvez re-cloner. Si le dépôt ne peut pas être récupéré avec git clone, il n’est pas sauvegardé.

Une configuration minimale de sécurité prête à copier

Pour la plupart des travaux locaux, un devcontainer non-root est le bon plancher : il limite l’agent au projet, sert de démarrage en une commande pour les nouveaux développeurs, et satisfait l’exigence du flag que le mode bypass ne s’exécute pas en tant que root. Un .devcontainer/devcontainer.json minimal ressemble à ceci :

{
  "name": "agent-sandbox",
  "image": "mcr.microsoft.com/devcontainers/javascript-node:22",
  "remoteUser": "node",
  "workspaceFolder": "/workspace",
  "workspaceMount": "source=${localWorkspaceFolder},target=/workspace,type=bind"
}

La ligne cruciale est "remoteUser": "node" — un utilisateur non-root, car --dangerously-skip-permissions refuse de démarrer en tant que root ou sous sudo. Montez uniquement le répertoire du projet ; ne montez pas votre répertoire home ni les chemins d’identifiants. Installez l’agent dans le conteneur, pointez-le vers l’API du modèle via une liste d’autorisations de sortie, et laissez-le s’exécuter.

Lorsque vous exécutez entièrement sans surveillance, ou que vous exécutez du code provenant de PRs non fiables ou de scripts générés arbitrairement, passez à une microVM avec son propre noyau :

# Docker Sandboxes : une microVM par agent, avec son propre noyau et son propre daemon Docker
sbx run claude        # instancie une microVM isolée et démarre en mode bypass

La CLI sbx est gratuite, y compris pour un usage commercial — seule la gouvernance organisationnelle nécessite un abonnement payant — et elle fonctionne désormais sur macOS, Windows et Linux, prenant en charge Claude Code, Codex, Copilot, Gemini, Droid, Kiro, OpenCode, et plus encore. Sur Linux, vous aurez besoin de la virtualisation matérielle KVM activée et de votre utilisateur ajouté au groupe kvm (voir le guide de démarrage).

Les compromis sont réels et méritent d’être énoncés :

• les microVMs entraînent une surcharge de performance même sur des projets simples ;
• la signature de commits via les agents SSH hôtes ne se transfère pas proprement dans les sandboxes, donc une solution courante consiste à commiter sans signature à l’intérieur et à rebaser pour signer sur l’hôte ; et
• une politique réseau de refus par défaut nécessite une configuration avant de cesser de vous gêner.

Au-delà de la machine locale : infrastructure partagée et CI

Dès qu’un agent s’exécute sur une infrastructure partagée par d’autres tenants ou des jobs CI, les couches de la machine locale ne suffisent plus, car un noyau hôte partagé signifie que l’exploit du noyau d’un job peut atteindre toutes les charges de travail sur le nœud. La solution à ce niveau est l’isolation du noyau par pod — donner à chaque agent son propre noyau Linux dans un sandbox matériel via des runtimes comme Edera, Kata Containers ou gVisor. Edera indique exécuter chaque charge de travail dans son propre noyau tout en restant dans les 5 % des performances natives, avec des benchmarks publiés sur arXiv:2501.04580 ; ce sont des chiffres publiés par le fournisseur, et l’accès à Edera est conditionné par leur équipe plutôt que par un téléchargement public. Ce niveau est excessif pour la machine locale d’un développeur individuel — réservez-le au cas pour lequel il a été conçu : une infrastructure multi-tenant ou CI où la compromission d’un tenant ne doit pas devenir celle de tous.

Choisissez la couche la plus basse qui couvre réellement votre risque, gardez les secrets hors de la boîte dans laquelle l’agent s’exécute, et placez une liste d’autorisations devant son réseau. Ainsi, la prochaine fois que l’agent fait quelque chose de plausible et d’erroné, vous supprimez un conteneur au lieu de reconstruire votre machine.

FAQ

Quelle est la différence entre le mode auto de Claude Code et le mode de contournement des permissions ?

Le mode de contournement des permissions (--dangerously-skip-permissions) désactive entièrement les invites d'approbation et la plupart des contrôles de sécurité, approuvant chaque commande sans jugement. Le mode auto, livré en mars 2026, utilise des classificateurs de modèles pour approuver automatiquement uniquement les invites de routine que les utilisateurs approuvent de toute façon (environ 93 % d'entre elles), tout en escaladant les actions risquées vers un humain, et il arrête l'agent après 3 refus consécutifs ou 20 refus au total. Le mode auto est conçu pour remplacer le contournement complet dans le travail quotidien sans réintroduire des interruptions constantes.

Exécuter un agent de codage dans un conteneur Docker rend-il le mode YOLO sûr ?

Un conteneur Docker standard réduit les dégâts de toute votre machine à un seul dossier de projet, mais ce n'est pas une frontière de sécurité complète car il partage le noyau hôte et n'a jamais été conçu pour contenir du code auquel vous ne faites pas confiance. Pour les exécutions non surveillées de routine sur votre propre code, un conteneur non-root est raisonnable, mais pour exécuter du code non fiable ou fraîchement généré, vous avez besoin d'une microVM avec son propre noyau. Les conteneurs nécessitent également un utilisateur non-root, car le mode bypass refuse de démarrer en tant que root ou sous sudo.

Pourquoi ne puis-je pas simplement écrire une liste d'autorisations plus stricte plutôt que de sandboxer l'agent ?

La mise en liste d'autorisations avec moindre privilège échoue pour les agents de codage parce que leur espace d'actions valides est illimité. Une seule tâche légitime peut installer des paquets, écrire dans des chemins arbitraires et exécuter du code généré quelques secondes plus tôt, donc toute règle assez stricte pour bloquer les dommages bloque également le travail normal. Chaque commande qui semble destructrice est quelque chose qu'un agent fait dans le cadre d'une opération ordinaire. L'approche fiable est le confinement : placez l'agent dans un environnement jetable adapté à votre risque plutôt que d'essayer d'énumérer à l'avance chaque action sûre.

L'isolation du système de fichiers de l'agent protégera-t-elle également mes identifiants et clés SSH ?

Non. L'isolation du système de fichiers et l'isolation réseau sont des axes séparés, et les deux doivent tenir. Sans limites réseau, un agent compromis peut exfiltrer les clés SSH qu'il peut lire ; sans limites sur le système de fichiers, il peut s'échapper pour atteindre le réseau. Même l'isolation au niveau du noyau ne couvre pas à elle seule le vol d'identifiants ni l'exfiltration de données. Gardez les secrets entièrement hors du sandbox en ne montant jamais des chemins comme les répertoires SSH ou AWS, injectez les identifiants au niveau d'un proxy de sortie si nécessaire, et placez une liste d'autorisations de domaines devant l'agent.