Le mode auto de Claude Code

Problème : Tout utilisateur de Claude Code finit par craquer face aux demandes de permission. Tu es trois fichiers dans un refactor, Claude a besoin de npm test, et une modale s'impose devant ton travail. Approuve. Lecture de fichier. Approuve. Écriture de migration. Approuve. Après trente prompts tu ne les lis plus. Tu cliques, c'est tout.

L'autre option, c'était --dangerously-skip-permissions. Ce flag retire tous les garde-fous. Bien dans un conteneur. Sur ton laptop, avec des clés SSH, des fichiers .env et des identifiants git juste là ? Pas une option raisonnable.

Le mode auto est la voie du milieu. Il a été lancé le 24 mars 2026, et il fonctionne en faisant tourner une seconde IA en arrière-plan. Chaque appel d'outil que Claude veut faire est inspecté d'abord. Les appels risqués sont bloqués et Claude est informé du pourquoi. Les appels sûrs s'exécutent sans aucune demande. Le classificateur se place entre Claude et ton système de fichiers, et prend la décision que tu aurais prise, plus vite que tu ne pourrais cliquer.

Ce qu'est vraiment le mode auto

Le mode auto est un nouveau mode de permission. Il se place entre default (tu examines tout) et bypassPermissions (rien n'est examiné). Active-le et Claude arrête d'afficher des prompts. Avant que chaque appel d'outil s'exécute réellement, un modèle classificateur séparé regarde la conversation jusqu'ici et l'action en attente, puis décide de laisser passer ou bloquer.

Trois catégories de risque guident la décision :

1. Escalade de portée : l'action va-t-elle au-delà de ce que tu as demandé ?
2. Infrastructure non fiable : la cible est-elle quelque chose que le classificateur n'a aucune raison de faire confiance ?
3. Injection de prompt : l'action ressemble-t-elle à quelque chose qui provient d'un contenu hostile que Claude a lu dans un fichier ou une page web ?

Ça passe et l'action s'exécute. Ça bloque et Claude reçoit la raison pour essayer une approche différente. Tes mains restent sur le clavier. Le classificateur reste en veille.

Comment fonctionne le classificateur

Chaque appel du classificateur tourne sur Claude Sonnet 4.6, quel que soit le modèle utilisé par ta session. L'entrée est constituée de tes messages utilisateur plus les appels d'outils en attente. La prose de Claude lui-même et les résultats d'outils précédents sont délibérément retirés. Comme la sortie des outils n'atterrit jamais dans le contexte du classificateur, rien de malveillant à l'intérieur d'un fichier ou d'une page ne peut atteindre et modifier la décision.

Ton CLAUDE.md est bien transmis. Les règles du projet alimentent ce que le classificateur accepte et refuse. Les listes d'autorisation et de refus statiques correspondent aux noms d'outils et aux arguments comme un grep. Le classificateur lit la prose et raisonne sur l'intention, donc il gère les cas que le filtrage par pattern ne peut pas.

Ordre d'évaluation

Chaque appel d'outil suit une échelle fixe. La première correspondance gagne :

Tes règles settings.json s'exécutent toujours en premier. Bash(npm test) dans la liste d'autorisation s'exécute sans que le classificateur se réveille. Bash(rm -rf *) dans la liste de refus est stoppé avant que le classificateur le voie.

Les règles d'autorisation larges sont supprimées

Voilà le piège que la plupart des gens ratent : au moment où tu passes en mode auto, Claude Code supprime tes règles d'autorisation larges qui accordent une exécution arbitraire. Tout ce qui ressemble à Bash(*), Bash(python*), Bash(node*), et toute règle d'autorisation Agent est retiré pour la durée.

La raison est simple. Si Bash(*) restait actif, exactement les commandes les plus susceptibles de te faire du mal s'auto-approuveraient avant que le classificateur ne les voie. Toute la fonctionnalité serait contournée.

Les règles précises restent en place. Bash(git status) et Bash(npm test) passent sans problème. Les règles supprimées reviennent quand tu quittes le mode auto.

Ce qui est bloqué vs autorisé

Une frontière de confiance traverse la vue du classificateur de ton système. Ton répertoire de travail local est de confiance. Si tu es dans un repo git, les remotes configurés pour ce repo sont de confiance. Tout ce qui est en dehors de ce périmètre compte comme externe jusqu'à ce qu'un admin en décide autrement.

Bloqué par défaut

Autorisé par défaut

Obtiens l'ensemble de règles par défaut tel que le classificateur le lit :

claude auto-mode defaults

Le travail d'équipe courant fait parfois trébucher le classificateur. Push vers le repo de ton org, écriture dans un bucket d'entreprise. Le classificateur n'a aucune idée que ces ressources t'appartiennent. Les admins corrigent ça en configurant l'infrastructure de confiance sous le paramètre autoMode.environment.

Comment activer le mode auto

Prérequis

Trois conditions doivent être remplies :

• Forfait Claude Code Team (Enterprise et API en cours de déploiement)
• Claude Sonnet 4.6 ou Claude Opus 4.6 (non disponible sur Haiku, les modèles claude-3, ou les fournisseurs tiers comme Bedrock ou Vertex)
• Activation par un admin : un admin doit activer le mode auto dans les paramètres admin de Claude Code avant que les utilisateurs puissent l'activer

CLI

Lance une session qui peut passer en mode auto :

claude --enable-auto-mode

Shift+Tab parcourt les modes : default -> acceptEdits -> plan -> auto. Ton mode actuel apparaît dans la barre de statut.

Ou saute directement là au lancement :

claude --permission-mode auto

VS Code

1. Ouvre les paramètres de l'extension Claude Code
2. Active Allow dangerously skip permissions (ça déverrouille le mode auto dans l'interface)
3. Clique sur l'indicateur de mode en bas de la zone de prompt
4. Sélectionne Auto dans le menu déroulant

Application Desktop

1. Active le mode auto dans les paramètres Desktop
2. Utilise le sélecteur de mode à côté du bouton d'envoi
3. Sélectionne Auto dans le menu déroulant

Desktop démarre avec le mode auto désactivé. Tu l'actives dans les paramètres avant qu'il apparaisse comme option.

Mode non-interactif

Les exécutions scriptées fonctionnent bien avec le flag -p :

claude -p "refactor the auth module" --permission-mode auto

Un point d'attention. Si le fallback se déclenche (couvert ci-dessous), les sessions non-interactives s'arrêtent. Il n'y a personne au clavier pour répondre à un prompt.

Les sous-agents en mode auto

Les équipes qui font tourner des boucles d'agents et des configurations multi-agents doivent savoir comment ça se propage aux sous-agents. Trois points de contrôle :

Au démarrage : avant que le sous-agent commence, le classificateur lit la description de la tâche qui lui est déléguée. "Supprime toutes les branches distantes correspondant à ce pattern" est refusé à l'entrée. Le sous-agent ne démarre jamais.

Pendant l'exécution : dans la session enfant, le mode auto applique les mêmes règles d'autorisation et de blocage que le parent. Tout permissionMode que le sous-agent a défini dans son propre frontmatter est ignoré. Chaque appel d'outil passe par le classificateur individuellement.

Au retour : une fois le sous-agent terminé, le classificateur lit son journal d'actions complet. Un enfant qui semblait correct au démarrage pourrait avoir été détourné en cours d'exécution par quelque chose qu'il a lu. Si la vérification au retour détecte un problème, un avertissement de sécurité est attaché au début de la sortie du sous-agent pour que le parent puisse réagir.

Trois points de contrôle signifient que les sous-agents n'ont pas besoin de ta confiance aveugle. Le classificateur les traite de la même façon que la session principale.

Le mode auto face aux autres modes

Voilà la vue complète sur tous les modes de permission que Claude Code propose :

L'échange est simple. Tu paies plus de tokens et attends un peu plus longtemps par action vérifiée. Tu perds le flux de prompts qui transforme toute longue session en exercice de clics.

Quand le choisir

Bon choix quand :

• Tâches longues où les approbations constantes brisent la concentration
• Tu fais confiance à la direction globale mais veux un filet sous les angles difficiles
• Boucles d'agents sans humain à proximité pour confirmer chaque étape
• Tu veux un choix plus sûr que bypassPermissions en dehors d'un conteneur

Mauvais choix quand :

• L'infrastructure de production est dans le périmètre (ce mode bloque ces actions de toute façon, pour de bonnes raisons)
• Code peu familier où tu veux les yeux sur chaque étape
• Un contrôle déterministe et auditable est nécessaire (utilise dontAsk avec des règles d'autorisation explicites)
• Le coût est serré (les appels classificateur coûtent des tokens)

Le fallback

Les faux positifs ne doivent pas couler ta session, donc le fallback les rattrape. Si le classificateur bloque 3 fois de suite ou 20 fois au total dans une session, le mode auto se met en pause et Claude Code revient à demander l'approbation manuellement.

Aucun des deux seuils ne peut être ajusté.

Quand il se déclenche :

• CLI : une note apparaît dans la zone de statut. Approuve le prochain prompt manuel et les compteurs de blocage se réinitialisent, donc tu peux rester en mode auto après.
• Mode non-interactif (flag -p) : la session se termine. Il n'y a personne pour répondre.

Les blocages répétés viennent d'un de ces deux endroits. La tâche veut vraiment quelque chose que le classificateur est conçu pour arrêter, ou le classificateur manque de contexte sur une infrastructure que tu possèdes vraiment. Utilise /feedback quand ça ressemble à un faux positif. Si le classificateur continue à rater que tes repos et services sont de confiance, demande à un admin de configurer l'infrastructure de confiance dans les paramètres gérés.

Défense en profondeur

Une seule couche n'est jamais toute l'histoire. Le mode auto te donne plus de protection que bypassPermissions et moins qu'examiner chaque appel à la main. La configuration la plus solide empile :

Couche 1 : Règles de permission. Les listes d'autorisation et de refus dans settings.json se résolvent avant que le classificateur tourne. Utilise-les pour un contrôle dur et déterministe sur des outils spécifiques.

Couche 2 : Classificateur du mode auto. Capture tout ce que les règles ne font pas. Raisonne sur le contexte, pas seulement sur des patterns textuels.

Couche 3 : Hooks. Les hooks PreToolUse font tourner une logique personnalisée en avance du système de permission. Le Permission Hook embarque un auto-approuveur alimenté par LLM avec un flux en trois niveaux (approbation rapide, refus rapide, analyse LLM). Les hooks et le mode auto coexistent : les hooks tournent en premier et peuvent approuver, refuser ou escalader avant que le classificateur voie l'appel.

Couche 4 : Sandboxing. Le sandboxing au niveau OS cloisonne l'accès au système de fichiers et au réseau au niveau du noyau. Même quand le classificateur rate quelque chose, le sandbox garde les commandes shell dans la boîte que tu as délimitée. C'est important parce que le classificateur lit l'intention tandis que le sandbox applique des murs durs.

Couche 5 : Agents auto-validants et stop hooks. Ils maintiennent les agents sur la tâche et dans le périmètre, ajoutant une vérification supplémentaire par-dessus la couche de permission.

Chaque couche comble les failles que les autres laissent. C'est la défense en profondeur.

Limitations à connaître

Ça a été lancé en research preview. Soyons honnêtes sur ce que ça signifie :

• Pas de garantie de sécurité. Une intention utilisateur ambiguë ou un contexte d'environnement manquant peut amener le classificateur à rater une action risquée. L'inverse arrive aussi (faux positifs sur des actions bénignes).
• Ça coûte plus. Les appels classificateur comptent dans ton utilisation de tokens. Chaque action vérifiée envoie un extrait de la transcription plus l'appel en attente. La majeure partie du surcoût vient des commandes shell et des opérations réseau, car les actions en lecture seule et les modifications de fichiers locaux sautent complètement le classificateur.
• La latence est réelle. Chaque vérification ajoute un aller-retour avant que l'action s'exécute. Les séquences de commandes shell rapides semblent plus lentes.
• Disponibilité limitée. Forfait Team uniquement pour l'instant (research preview). Enterprise et support API en cours de déploiement. Sonnet 4.6 ou Opus 4.6 requis. Pas de Haiku, pas de claude-3, pas de fournisseurs tiers.
• Pas un substitut à la revue sur les opérations sensibles. Fais-lui confiance pour le travail où la direction est solide. Pour tout ce qui touche la production, les identifiants, ou l'infrastructure partagée, la revue humaine reste le bon choix.

Le calibrage s'améliore avec les données. /feedback est la façon dont les faux positifs et les blocages ratés sont signalés. Chaque rapport affine le système.

La suite

Les utilisateurs du forfait Team ont un nouveau workflow quotidien. L'ancien compromis entre sécurité et vitesse a maintenant une troisième option.

Pour une posture de sécurité complète autour du mode auto :

• Rédige des règles de permission pour un contrôle déterministe sur des outils spécifiques
• Configure des hooks pour une logique de permission personnalisée au-delà de ce que le classificateur gère
• Active le sandboxing pour une application au niveau OS comme dernier rempart
• Lis la référence des paramètres pour chaque option liée aux permissions
• Explore les boucles d'agents autonomes pour tirer le meilleur parti de la réduction des prompts sur les longues exécutions

Le prompt de permission n'est plus le goulot d'étranglement. Le classificateur s'en occupe. Retourne à construire.