Où l’auto mode et la sandbox arrêtent-ils l’agent ?

Quels contrôles une commande passe-t-elle avant de s’exécuter ?

Quand un agent de codage veut exécuter une commande, la décision ne se prend pas à un seul endroit. La documentation des cinq outils décrit les mêmes quatre couches : d’abord les règles que vous écrivez vous-même, puis la sandbox appliquée par le système d’exploitation, puis un modèle distinct qui examine la commande, et enfin vous. Nous avons expliqué comment écrire des règles avec des hooks dans l’article sur les hooks. Celui-ci porte sur les trois autres, à partir des mesures des éditeurs eux-mêmes :

Les données des éditeurs eux-mêmes montrent pourquoi on a placé un modèle entre les deux. Selon Anthropic, les utilisateurs de Claude Code acceptent 97 % des demandes d’autorisation. Les mêmes utilisateurs rejettent 39 % des plans que l’agent propose, mais pour les demandes d’autorisation prises une à une, le taux de refus n’est que de 3 %. C’est comme approuver une pull request sans la lire : les demandes arrivent si souvent qu’on les valide sans les lire.

Une expérience décrite dans le même article d’Anthropic chiffre l’écart. Une seule commande dangereuse a été glissée dans la session de 1 053 utilisateurs de test rémunérés. En réalité, seul le texte de la demande avait été modifié ; même s’ils acceptaient la commande, rien ne s’exécutait. Les humains ont arrêté cette commande dans 13,6 % des cas, l’auto mode dans 89 %. Plus la session durait, plus les humains en laissaient passer : au début, ils arrêtaient environ 17 % des commandes dangereuses, et après 50 demandes ou plus, environ 5 %. Ces résultats viennent de l’expérience de l’éditeur lui-même.

OpenAI a constaté le même problème chez ses propres utilisateurs. D’après l’article d’OpenAI, quand les demandes d’accord sont fréquentes, les utilisateurs passent soit au mode Full Access, où aucune règle n’est appliquée, soit à des règles larges qui autorisent toute commande commençant par python. Selon Anthropic, en juin, 43 % des utilisateurs actifs de la CLI avaient une règle d’interpréteur comme Bash(python:*). Les deux éditeurs ont choisi la même solution : poser la question à un modèle distinct plutôt qu’à un humain.

Comment l’auto mode et l’auto-review décident-ils ?

Un appel que ni les règles ni la sandbox ne tranchent va au modèle qui autorise ; c’est lui qui décide s’il s’exécute. Les cinq outils ont désormais un tel modèle, mais ce qu’il voit, le moment où il vous rend la décision et son activation par défaut varient d’un outil à l’autre. Situation au 20 octobre 2026 :

Source : documentation et notes de version des outils, 20 octobre 2026. « Non précisé dans la documentation » : dans les pages que nous avons lues ce jour-là, nous n’avons trouvé aucune phrase qui le décrive. Le juge de Copilot est arrivé dans la CLI le 7 juillet ; la documentation de VS Code présente ce niveau d’autorisation comme expérimental.

Dans Claude Code, l’ordre de décision est fixe : d’abord vos règles allow, ask et deny, puis les lectures et modifications dans le répertoire de travail, et en dernier le classifieur. Quand vous passez en auto mode, les règles larges qui permettent d’exécuter n’importe quel code, comme Bash(*) ou Bash(python*), sont retirées ; les règles étroites comme Bash(npm test) restent. Le classifieur ne voit pas les sorties des outils : une instruction cachée dans un fichier ou une page web ne peut donc pas l’orienter directement. Quand il bloque un appel, l’écran affiche Denied by auto mode classifier, avec à côté le nom de la règle correspondante, par exemple [Data Exfiltration].

Codex fait le choix inverse. L’auto-review voit aussi les sorties des outils et fait au besoin ses propres vérifications en lecture seule. Mais elle n’examine que les appels qui veulent franchir la limite de la sandbox ; une commande qui reste dans la sandbox n’est jamais examinée. Selon sa documentation, ce n’est pas une autorisation, seulement un changement de vérificateur : l’auto-review n’élargit pas les répertoires accessibles en écriture et n’ouvre pas le réseau. La politique par défaut se trouve dans le dépôt open source de Codex, dans un dossier nommé guardian. Si vous écrivez votre propre politique, elle ne se combine pas avec celle par défaut : elle la remplace. Selon l’article d’OpenAI du 30 avril 2026, le vérificateur tournait alors sur GPT-5.4 Thinking ; la documentation n’indique pas le modèle actuel.

Cursor a publié Auto-review le 29 mai et la propose depuis comme réglage par défaut recommandé. Le classifieur tourne avec de petits modèles sur les serveurs de Cursor et peut consulter des fichiers de votre machine en lecture seule pour décider. Chez Copilot, le juge est arrivé d’abord dans la CLI. Selon la documentation de VS Code, Assisted permissions est un niveau expérimental : un juge LLM évalue chaque appel d’outil, et s’il n’approuve pas, on vous demande. Antigravity CLI a ajouté un Auto mode le 14 octobre : il approuve sans demander les modifications de fichiers et les commandes sûres, tandis qu’un agent distinct examine d’abord les commandes qui sortiraient de la sandbox. La page des modes d’Antigravity ne mentionne pas encore ce mode ; l’information se trouve dans les notes de version.

Si vous utilisez encore Gemini CLI, sa documentation ne décrit pas de modèle qui autorise : le policy engine décide avec des règles fixes, et c’est la première règle correspondante qui fixe le résultat. Le 18 juin 2026, Google a cessé de servir Gemini CLI aux abonnés Google AI Pro et Ultra ainsi qu’aux utilisateurs individuels gratuits, et les a redirigés vers Antigravity CLI ; vous pouvez continuer à utiliser Gemini CLI avec une clé d’API payante. Attention aussi à une confusion de noms : dans Copilot et Cursor, « Auto » est aussi le nom du routeur qui choisit un modèle. Nous l’avons présenté dans l’article sur le choix du modèle ; l’auto mode de cet article concerne les autorisations.

À quelle fréquence le modèle qui autorise se trompe-t-il ?

Le modèle qui autorise peut se tromper de deux façons : il laisse passer un appel dangereux, ou il arrête pour rien un appel inoffensif. Dans le premier cas, la commande s’exécute ; dans le second, l’agent essaie une autre voie ou vous demande. Deux éditeurs mesurent et publient les deux : Anthropic et OpenAI. Nous n’avons trouvé aucune mesure dans la documentation de Cursor, de GitHub ou de Google. Anthropic a comparé les humains et le classifieur sur les mêmes commandes :

Ces chiffres viennent de jeux de test ; en usage réel, le tableau est moins flatteur. Dans l’article technique d’Anthropic du 25 mars 2026, sur 10 000 appels d’outils réels d’employés de l’entreprise, le classifieur a arrêté pour rien 0,4 % des appels inoffensifs. À l’inverse, l’agent est allé au-delà de ce que voulait l’utilisateur dans 52 actions réelles, et le classifieur n’en a pas détecté 17 %. L’article lui-même appelle ce chiffre « the honest number ». Dans la plupart des cas manqués, le classifieur avait vu le danger, mais avait cru que l’accord de l’utilisateur couvrait aussi cette action : dire « Clean up the PR », ce n’est pas autoriser un force push. À l’époque, le classifieur tournait sur Sonnet 4.6 ; aujourd’hui, le modèle par défaut est Claude Sonnet 5.

OpenAI a fait sa propre mesure sur des données synthétiques. Selon OpenAI, l’auto-review a détecté 90,3 % des cas où l’agent allait au-delà de ce qui était demandé. Pour l’injection de prompt, le taux de détection est de 99,3 % sur trois types d’attaque ; en comptant tous les types, suppressions et altérations de données comprises, il tombe à 90,2 %. Lors d’exercices de red team, ils ont trouvé des cas où l’on pouvait amener l’auto-review à approuver une commande sans l’accord de l’utilisateur ; ils écrivent aussi qu’ils n’attendent pas de garantie déterministe de ce type de système. Dans un test d’attaques synthétiques qu’Anthropic a mené avec une équipe externe, la part des cas manqués par le classifieur est passée de 12 % à 7 % après corrections ; Anthropic demande de ne pas prendre ce chiffre pour la part des cas manqués sur du trafic réel. Nous avons expliqué comment lire un résultat publié par un éditeur dans l’article sur SWE-bench.

La documentation dit aussi ce que le modèle ne voit pas. Le modèle qui autorise ne voit que l’appel qui lui est soumis : dans Codex, les commandes qui restent dans la sandbox ne lui parviennent jamais, et dans Claude Code, les lectures et modifications dans le répertoire de travail non plus. OpenAI écrit qu’un modèle qui cache son intention pourrait produire une demande d’apparence inoffensive, ou faire dans la sandbox des choses que l’auto-review ne voit jamais. Le classifieur de Claude Code ne voit pas la sortie des commandes précédentes. Si la cible d’un rm -rf est une variable shell dont la valeur n’est jamais apparue dans la conversation, il ne peut donc pas vérifier la suppression et la bloque. Une limite que vous fixez dans la conversation, comme « ne push pas », n’est pas non plus enregistrée comme une règle ; selon la documentation, ce message peut se perdre quand le contexte est compacté. Nous avons expliqué comment dans l’article sur l’auto compact. Pour une interdiction ferme, écrivez une règle deny.

L’équilibre entre danger manqué et arrêt inutile est le même qu’en revue de code entre bug réel et fausse alerte : un réglage qui réduit l’un augmente l’autre. Les éditeurs le disent eux-mêmes clairement. Cursor écrit dans un titre qu’Auto-review n’est pas une frontière de sécurité ; VS Code dit la même chose d’Assisted permissions. OpenAI écrit que l’auto-review n’est pas une garantie de sécurité déterministe, et Anthropic que l’auto mode ne garantit pas la sécurité. C’est la sandbox qui trace la limite.

Que limite vraiment une sandbox ?

La sandbox limite la commande que lance l’agent avec les outils du système d’exploitation lui-même : Seatbelt sous macOS, et bubblewrap, Landlock ou les namespaces du noyau sous Linux. Même si le modèle se trompe, la commande ne peut ni écrire dans un fichier non autorisé, ni se connecter à un serveur non autorisé. Mais les réglages par défaut des cinq outils sont très différents :

Source : documentation des outils sur la sandbox, 20 octobre 2026. La sandbox locale de Copilot est disponible pour tous depuis le 7 octobre. Dans Gemini CLI aussi, c’est vous qui activez la sandbox, avec une option, une variable d’environnement ou un réglage.

La colonne la plus importante du tableau est la dernière. La documentation de Claude Code indique que la sandbox ne couvre que les commandes shell : les outils de fichiers comme Read et Edit suivent les règles d’autorisation, et les hooks et les serveurs MCP locaux s’exécutent avec tous vos droits. Selon la documentation de GitHub, la sandbox du système d’exploitation ne voit pas non plus ce que font les outils de fichiers propres à Copilot CLI ; seul un contrôle logiciel les limite. Nous avons expliqué pourquoi les serveurs MCP locaux méritent une attention particulière dans l’article sur la sécurité MCP.

La plupart des évasions de sandbox recensées viennent précisément de cette brèche : une commande dans la sandbox prépare quelque chose, et un élément hors de la sandbox l’exécute ou écrit par ce biais. La NVD en donne trois exemples, tous trois corrigés :

• Claude Code (CVE-2026-39861, avant 2.1.64) : une commande dans la sandbox pouvait créer un lien symbolique pointant hors du répertoire de travail. Quand Claude Code, qui s’exécute hors de la sandbox, écrivait sur ce chemin, le fichier atterrissait hors du répertoire. Selon la fiche, aucun des deux ne pouvait écrire hors du répertoire à lui seul ; l’évasion venait de leur combinaison.
• Cursor (CVE-2026-26268, avant 2.5) : un agent manipulé par injection de prompt pouvait écrire dans des réglages .git mal protégés et dans des hooks git ; git exécutait ensuite ces hooks de lui-même, hors de la sandbox. Cursor bloque désormais toujours l’écriture dans .git/hooks et .git/config.
• Codex (CVE-2026-19591) : l’analyseur qui repère les commandes sûres a pris à tort certaines commandes PowerShell pour sûres, et une commande git qui écrit dans un fichier pouvait s’exécuter sans demander d’accord. Selon la fiche, sous macOS et Linux, la sandbox par défaut pouvait malgré tout empêcher l’écriture aux endroits non autorisés : quand la couche des règles s’est trompée, la sandbox pouvait tenir la limite.

La documentation de VS Code décrit elle aussi cette faiblesse de la couche des règles : l’approbation automatique fondée sur des règles n’analyse une commande qu’au mieux ; la concaténation de guillemets ou les alias shell peuvent contourner les règles. Côté réseau, il existe aussi une faille connue. Selon la documentation de Claude Code, le proxy décide d’après le nom de domaine que le client annonce, sans inspecter le TLS ; des techniques comme le domain fronting permettent donc d’atteindre des serveurs absents de la liste. La même page avertit qu’autoriser un domaine large comme github.com peut ouvrir une voie d’exfiltration de données. Les bugs de la sandbox elle-même apparaissent aussi dans les notes de version : la version 2.1.224 a corrigé un bug par lequel une entrée denyRead terminée par une barre oblique pouvait être contournée sans bruit sous Linux et macOS.

Les outils traitent aussi les secrets différemment. Claude Code n’a aucune liste de refus intégrée pour les identifiants ; seuls les fichiers et variables que vous listez sont restreints. Vous pouvez masquer une clé si vous le souhaitez : la commande voit un substitut propre à la session au lieu de la vraie valeur, et le proxy n’insère la vraie valeur que dans les requêtes vers les serveurs que vous autorisez. Claude Code ne lit pas ce réglage dans le .claude/settings.json du dépôt, seulement dans les réglages utilisateur ou administrateur. Copilot fournit par défaut les identifiants Git et gh de la même manière quand la sandbox est activée ; le vrai jeton de gh ne part que vers les adresses github.com. Antigravity bloque ~/.ssh et .env d’emblée. La documentation de GitHub dit clairement ce qui se passe dans Copilot quand la sandbox est désactivée : les commandes peuvent lire et écrire partout avec les droits de votre compte, atteindre tout réseau que votre machine atteint et utiliser vos identifiants sans restriction.

Quel mode choisir pour quel travail ?

Tous les éléments vont dans le même sens : le modèle qui autorise réduit les questions qui vous arrivent, et c’est la sandbox qui trace la limite. Utilisez les deux ensemble et choisissez le réglage selon le travail :

Pour le travail quotidien que vous suivez, utilisez le modèle qui autorise avec la sandbox. Dans Claude Code, l’auto mode est déjà le mode de départ ; activez aussi la sandbox avec /sandbox. Dans Codex, la sandbox est déjà activée ; choisissez « Approve for me » dans le menu des autorisations. Dans Cursor, laissez Auto-review activée. Dans Copilot CLI, activez la sandbox avec /sandbox enable. Dans Antigravity CLI, activez la sandbox avec --sandbox et choisissez --mode auto. Pour voir ce que bloque le modèle, Claude Code écrit depuis le 15 octobre la décision du classifieur dans les événements OpenTelemetry, et Codex garde les transcriptions de l’auto-review sous ~/.codex/sessions.

Si l’agent demande sans cesse l’autorisation, ajustez la limite plutôt que de tout ouvrir. C’est aussi le conseil d’OpenAI : si des demandes ordinaires finissent en vérification, corrigez d’abord la limite de la sandbox, et écrivez des règles étroites comme ["cargo", "test"] plutôt que des préfixes larges comme ["python"]. Dans Claude Code, si vous ne voulez pas de classifieur, combinez le mode Manual et le mode auto-allow de la sandbox ; les commandes qui restent dans la sandbox s’exécutent sans demander. Donnez l’autorisation une fois, sous forme de règle étroite, et non à chaque demande de l’agent.

Pendant une exécution sans surveillance, personne n’est là pour répondre. Claude Code lance les exécutions démarrées avec -p en mode Manual tant que vous ne donnez pas de mode, et refuse les appels qui demandent un accord. Les agents cloud de Cursor tournent sur une machine qui leur est réservée et ne demandent jamais d’accord. Dans une telle exécution, gardez la sandbox activée, limitez le réseau à une liste de domaines et ne mettez dans l’environnement aucune clé dont l’exécution n’a pas besoin. Si vous devez donner un accès complet, faites-le uniquement dans un conteneur jetable ; c’est alors le conteneur lui-même qui trace la limite. La documentation de Codex précise que même dans un tel conteneur, un projet malveillant peut exfiltrer tout ce qui s’y trouve, identifiants de Codex compris.

Une partie de ces réglages vit dans le dépôt et peut changer avec une pull request. Claude Code ne permet pas d’activer l’auto mode depuis le fichier de réglages du dépôt ; mais tant qu’un administrateur n’impose pas la sandbox, il lit dans ce fichier des entrées qui assouplissent la limite, comme excludedCommands et network.allowedDomains. Sa documentation indique qu’avec une entrée excludedCommands large, l’agent peut écrire un fichier puis l’exécuter hors de la sandbox. Cursor fusionne le .cursor/sandbox.json du dépôt avec le réglage utilisateur et donne la priorité au fichier du dépôt ; Codex charge le .codex/config.toml du dépôt dans un projet auquel vous faites confiance. Une pull request qui touche l’un de ces fichiers change la limite pour tous ceux qui ouvrent le dépôt ; examinez-la comme un changement de sécurité. Avant d’ouvrir avec un agent un dépôt auquel vous ne faites pas confiance, regardez aussi ces fichiers.

Nous appliquons le même principe dans notre propre produit. Dans diffox, notre outil de revue de code par IA, l’étape qui trace le blast radius d’une pull request lit les fichiers du client et n’appelle personne à l’extérieur. Cette étape construit son environnement à partir d’une liste d’autorisation : en dehors de PATH, HOME, des réglages de langue et du répertoire temporaire, elle ne reprend aucune variable. Une liste de refus laisserait passer une nouvelle clé ajoutée demain.

Questions fréquentes

Qu’est-ce que l’auto mode de Claude Code ?

L’auto mode est l’un des modes d’autorisation de Claude Code : un modèle classifieur distinct répond à votre place aux demandes d’autorisation. Vos règles allow, ask et deny s’appliquent d’abord, et les lectures et modifications dans le répertoire de travail passent sans demande ; les appels restants sont examinés par le classifieur, qui tourne par défaut sur Claude Sonnet 5. Vous pouvez changer de modèle avec CLAUDE_CODE_AUTO_MODE_MODEL. Par défaut, il bloque l’envoi de données sensibles vers l’extérieur, les déploiements en production et le force push ; après 3 blocages d’affilée ou 20 au total dans la session, il vous redemande. Le 14 août, il est devenu le mode de départ des offres Pro, Max et Team ; depuis le 28 septembre, les sessions interactives démarrent dans ce mode sur toutes les offres. La documentation d’Anthropic précise que l’auto mode ne garantit pas la sécurité.

Que signifie « Denied by auto mode classifier » ?

Cela signifie que le classifieur de Claude Code a jugé cet appel non sûr. Le nom entre crochets, par exemple [Data Exfiltration] ou [Production Deploy], est celui de la règle correspondante. Vous voyez les appels bloqués dans l’onglet Recently denied de /permissions, et la touche r indique à l’agent qu’il peut réessayer cet appel. Si ce qui a été bloqué est un registre de paquets ou un domaine interne dont l’agent a constamment besoin, ajoutez-le à autoMode.environment ; /auto-mode-setup prépare ces entrées pour vous. Pour une opération ponctuelle, écrivez clairement votre intention dans le message suivant.

Quelle différence entre l’auto-review et le full access de Codex ?

Les deux réduisent les demandes d’accord, mais ils placent la limite à des endroits différents. L’auto-review (« Approve for me ») laisse la sandbox workspace-write telle quelle ; elle envoie seulement les appels qui veulent sortir de la sandbox à un agent vérificateur distinct plutôt qu’à vous. Le full access, c’est sandbox_mode = "danger-full-access" avec approval_policy = "never" : ni sandbox ni question ; l’agent accède à internet et à tous les fichiers de votre ordinateur. Dans la mesure d’OpenAI elle-même, l’auto-review a détecté 90,3 % des scénarios synthétiques où l’agent franchissait la limite, et la session s’est arrêtée environ 200 fois moins souvent pour un accord humain. En full access, ce contrôle n’existe pas du tout.

Comment activer la sandbox de Claude Code ?

Tapez /sandbox dans la session, ou passez sandbox.enabled à true dans ~/.claude/settings.json. Sous macOS, rien d’autre n’est nécessaire ; sous Linux et WSL2, bubblewrap et socat doivent être installés. Sous Windows natif, les commandes s’exécutent sans sandbox. Une fois la sandbox activée, les commandes peuvent écrire dans le répertoire de travail et le répertoire temporaire, et ne sortir sur le réseau que vers les domaines que vous autorisez. La sandbox ne couvre que les commandes shell ; les outils de fichiers, les hooks et les serveurs MCP locaux restent en dehors. Si vous ne voulez pas que les commandes soient réessayées hors de la sandbox, passez allowUnsandboxedCommands à false.

L’agent peut-il lire ~/.ssh quand la sandbox est activée ?

Cela dépend de l’outil. Par défaut, la sandbox de Claude Code peut lire l’essentiel de la machine, ~/.ssh et ~/.aws/credentials compris ; pour fermer cet accès, il faut le réglage filesystem.denyRead ou credentials. Dans Cursor, la limite de lecture est « system » par défaut et ~/.ssh est lisible ; si vous choisissez « workspace », seul known_hosts reste lisible dans ~/.ssh. La sandbox de Copilot ferme tous les chemins du système de fichiers que vous n’avez pas autorisés, mais avec l’accès par défaut aux outils de développement, les commandes peuvent lire les jetons stockés par les gestionnaires de paquets. Antigravity bloque ~/.ssh et .env d’emblée. La documentation de Codex n’indique pas clairement la limite de lecture par défaut ; elle conseille une règle deny pour des chemins comme ~/.ssh.

Pourquoi Claude Code demande-t-il sans cesse l’autorisation ?

Le plus souvent parce que la session a démarré en mode Manual. Depuis le 28 septembre, Claude Code démarre les sessions interactives en auto mode ; mais si defaultMode dans vos réglages utilisateur indique un autre mode, si votre modèle ne prend pas en charge l’auto mode ou si votre organisation a désactivé l’auto mode, la session démarre en Manual. Vous pouvez passer en auto mode avec Shift+Tab. En auto mode aussi, on vous demande pour les règles ask comme Bash(git push *) et pour la première lecture hors du répertoire de travail. Si vous ne voulez pas de classifieur, activez la sandbox en mode auto-allow ; les commandes dans la sandbox s’exécutent sans demander. N’écrivez pas de règle comme Bash(*) qui ouvre tout.

L’auto mode est-il payant ?

Cela dépend de l’outil. Depuis le 7 août, Anthropic ne facture plus les tokens supplémentaires du classifieur sur les offres Pro, Max et Team. Sur l’offre Enterprise et pour les comptes qui passent par l’API Claude, Bedrock, Google Cloud ou Foundry, les appels du classifieur comptent dans l’usage de tokens ; quand l’examen se fait côté serveur, il n’y a pas d’appel séparé. Cursor écrit que le classifieur d’Auto-review n’ajoute aucun coût à l’usage de l’agent. La documentation de Codex, de Copilot et d’Antigravity n’indique pas ce que coûte le modèle qui autorise.