Claude Code : le mode auto devient le réglage par défaut au 14 août 2026

Le 14 août 2026, le mode auto devient le réglage par défaut des nouvelles sessions Claude Code sur les plans Pro, Max et Team. Concrètement : chaque appel d'outil (édition de fichier, commande Bash, appel MCP) passe par un classifieur qui bloque en amont ce qu'il juge irréversible, destructeur ou dirigé hors de l'environnement de travail, au lieu de demander une confirmation utilisateur à chaque étape. Si tu utilises déjà Claude Code au quotidien et que tu as un défaut choisi manuellement, il reste en place, sauf acceptation de l'invite de bascule proposée une seule fois. Ce billet fait partie du guide complet Claude 2026 et cible les équipes qui veulent décider vite si elles gardent ce nouveau défaut ou reviennent au manuel.

À noter d'emblée : le mode auto n'est pas neuf. Une version de test existe depuis mars 2026, et il est déjà disponible aujourd'hui sur l'API Anthropic, Amazon Bedrock, Google Cloud Agent Platform et Microsoft Foundry. Ce qui change au 14 août, c'est son statut de défaut pour les plans grand public payants Pro, Max et Team. Les organisations Enterprise et l'API restent en opt-in pour le moment.

Ce qui change exactement au 14 août 2026

Avant cette date, une session Claude Code fraîche démarre avec des demandes de permission à chaque étape sensible : écrire un fichier, lancer une commande Bash, appeler un outil MCP. Après le 14 août 2026, une nouvelle session sur Pro, Max ou Team démarre en mode auto. Le classifieur autorise silencieusement ce qu'il considère comme sûr et coupe court à ce qu'il juge dangereux, sans passer par toi.

Trois choses restent vraies même en mode auto, et c'est important de les avoir en tête avant de toucher à ta configuration :

• Les règles permissions.deny et permissions.ask que tu as posées manuellement sont évaluées avant le classifieur. Une règle ask déclenche toujours une invite. Une règle deny bloque toujours.
• Un défaut géré par ton organisation (via la configuration Team/Enterprise) prime sur le basculement automatique.
• Un défaut déjà choisi manuellement par l'utilisateur reste en place. La bascule est proposée une fois, à toi de l'accepter ou non.

La commande claude auto-mode config affiche la configuration effective sur ta machine, claude auto-mode defaults les règles intégrées, et claude auto-mode reset ramène tout aux valeurs d'usine. C'est le premier réflexe à avoir sur un poste après la bascule : vérifier ce que voit réellement l'outil, pas ce que tu supposes.

Pourquoi Anthropic fait ce changement maintenant

Le billet de blog du 7 août 2026 est explicite sur les chiffres qui justifient la bascule. Sur un panel de 1 053 utilisateurs payants, le mode auto a bloqué 89 % des commandes dangereuses, contre 13,6 % de blocage en revue humaine manuelle. Un test tiers de type red-teaming a mesuré 7 % de commandes dangereuses non attrapées après durcissement, contre 12 % avant. Sur 720 tentatives d'injection de prompt, aucune n'a réussi contre Fable 5, Opus 5 ou Sonnet 5 tournant en mode auto. En production, des actions jugées dommageables sont apparues dans 6,3 % des sessions en approbation manuelle, contre 2,4 % en mode auto.

Autrement dit, la revue humaine à la volée sur chaque commande est moins fiable que le classifieur, parce qu'après vingt confirmations d'affilée on clique oui sans lire. Anthropic ajoute une phrase que je te recommande de garder en tête : le mode auto "s'appuie sur des systèmes de classification et n'élimine donc pas le risque". La documentation recommande explicitement de garder une revue manuelle pour les changements à haut risque sur une infrastructure de production.

Ce n'est pas un blanc-seing. C'est un déplacement du curseur, du "tout demander" vers "filtrer intelligemment, escalader ce qui compte".

Comment fonctionne le classifieur de sécurité

Le classifieur regarde chaque appel d'outil avant exécution : édition de fichier, commande shell, appel MCP. Il tranche selon quatre familles de règles définies dans le bloc de configuration autoMode :

Exemples concrets de ce qui se passe : un rm -rf ciblant un dossier hors de environment tombe en hard_deny. Un curl vers un domaine inconnu depuis un script exécuté par Claude déclenche typiquement soft_deny. Une modification de .env aussi. En revanche, éditer un fichier dans src/, lancer les tests, ajouter une dépendance dans package.json, ça passe.

Ce que le classifieur ne voit pas, en revanche : la logique métier de tes changements. Il ne détecte pas qu'un refacto vient de casser trois hypothèses implicites dans ton code, ni qu'un commit va publier des credentials si ton .gitignore est mal foutu. La responsabilité de la revue de fond reste chez toi ou chez ton équipe.

Reconfigurer les permissions pour votre équipe

Le mode auto s'ajuste par profil. Trois cas typiques que je vois passer, avec la logique de configuration correspondante.

Dev solo sur projet perso

Accepte le défaut. Tu bosses en sandbox, tu peux te permettre de laisser le classifieur faire son job. Si tu veux protéger un dossier sensible (clés SSH, dotfiles), ajoute-le en hard_deny. Rien d'autre à faire.

Agence sur repo client

Restreins environment au périmètre réel du projet client, et ajoute des règles soft_deny qui décrivent en langage naturel ce qui doit être escaladé avant toute modification. Les entrées autoMode ne sont pas des motifs de fichiers (pas de glob ni de regex) : le classifieur les lit comme des règles en prose. Un exemple minimal de settings.json côté utilisateur, construit sur les règles par défaut avec "$defaults" :

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Organisation : agence, dépôt du client courant uniquement, aucun autre repo de confiance"
    ],
    "soft_deny": [
      "$defaults",
      "Ne jamais modifier les fichiers sous .git/, infra/ ou tout fichier .env sans validation explicite du client"
    ],
    "hard_deny": [
      "$defaults",
      "Ne jamais lire ou modifier un dossier en dehors du projet client courant, y compris ~/.ssh/"
    ]
  },
  "permissions": {
    "ask": ["Bash(git push *)", "Bash(npm publish *)"]
  }
}

La règle ask sur git push et npm publish passe par-dessus le classifieur : ces deux actions resteront toujours confirmées manuellement, même si le mode auto les considère comme sûres.

Équipe produit sur monorepo

Le mode auto reste actif sur src/, désactivé sur les dossiers infra, CI et scripts de déploiement. Utilise la configuration gérée par l'organisation (managed settings) plutôt que la config utilisateur : elle s'applique à tous les postes et ne dépend pas de ce que chaque dev a bricolé chez lui. Pour aller plus loin sur la config globale de Claude, va voir la page pilier configurer Claude au quotidien.

Note technique utile : les options avancées de masquage de secrets ajoutées dans Claude Code 2.1.224 (extraction JWT, re-signature AWS SigV4) ne sont prises en compte que depuis les réglages utilisateur, les réglages gérés par l'organisation, ou le flag --settings. Pas depuis .claude/settings.json à la racine du projet.

Les trois pièges du mode auto en production

Piège 1 : les suppressions en cascade sur un refacto mal cadré. Tu demandes à Claude de "nettoyer les composants inutilisés" sur une base React. Le classifieur autorise chaque suppression individuellement, elles sont dans src/, aucune n'est destructrice au sens strict. Mais l'ensemble supprime des composants encore importés dynamiquement. Parade : sur un refacto lourd, bascule temporairement en manuel via la commande de mode ou lance la session en soft_deny sur les suppressions.

Piège 2 : la modification silencieuse de fichiers de config partagés. Un docker-compose.yml, un fichier CI GitHub Actions, un tsconfig.json. Le classifieur les traite comme du texte dans le dossier projet. Si tu ne les as pas mis en soft_deny, ils partent en modification sans que tu le voies passer. Parade : liste explicitement les fichiers de config transverse dans soft_deny.

Piège 3 : les commits automatiques qui polluent l'historique git. Claude Code sait committer si on ne l'en empêche pas. En mode auto, un long enchaînement de tâches peut produire une série de commits granulaires que personne n'a relus. Parade : mets Bash(git commit:*) en ask, ou demande explicitement dans le prompt système de regrouper les modifications avant tout commit.

Décider si tu gardes le défaut ou reviens au manuel

Grille courte sur trois critères.

Le défaut auto est un gain net quand tu passes ta journée à itérer sur du code que tu vas de toute façon relire à la fin. Il devient un risque dès que Claude touche à des fichiers que personne ne relira avant le déploiement. Sur les repos sensibles, la combinaison saine reste : mode auto restreint à src/, tout ce qui touche à git, à l'infra ou aux secrets en ask ou soft_deny.

Si tu veux pousser au-delà de la simple config de permissions et cadrer des agents Claude qui tournent en fond de manière durable, la logique se déplace du réglage local vers l'architecture. Le pilier construire des agents Claude autonomes couvre cette étape, et l'article dédié au correctif d'isolation Claude Code 2.1.222 sur les worktrees complète utilement le sujet si tu fais tourner plusieurs sessions en parallèle. Pour les intégrations tierces, la page connecter Claude via MCP détaille les serveurs pris en charge.

Enfin, pour les équipes qui veulent structurer une flotte d'agents Claude avec permissions, garde-fous et supervision, tu peux piloter vos agents autonomes avec un cadre méthodologique dédié plutôt qu'à coups de settings.json improvisés.