Claude Code : le mode automatique devient le défaut

Ce que le mode automatique change le 14 août 2026

Le mode automatique de Claude Code exécute les appels d’outils sans vous demander votre autorisation à chaque fois. Chaque action est d’abord envoyée à un modèle de classification distinct pour vérification. À partir du 14 août 2026, les nouvelles sessions démarreront dans ce mode avec les offres Pro, Max et Team. Vous pouvez changer de mode à tout moment. Un mode par défaut que vous avez déjà défini pour vous-même n’est pas remplacé.

La documentation décrit ce changement ainsi :

À partir du 14 août 2026, le mode automatique devient le mode d’autorisation par défaut pour les nouvelles sessions avec les offres Pro, Max et Team. Vous pouvez changer de mode à tout moment. Un mode par défaut que vous avez défini vous-même reste en place, sauf si vous acceptez l’invite de changement ponctuel. Un mode par défaut géré par votre organisation reste inchangé.

Deux éléments de cette description sont plus importants que la date. Un defaultMode que vous avez défini dans votre propre fichier de configuration reste en place après le changement. Un mode par défaut déployé par votre organisation via des paramètres gérés reste lui aussi inchangé. Le billet d’annonce précise également que le mode automatique reste facultatif pour les offres Enterprise et pour les comptes qui utilisent l’API pendant la première phase du déploiement.

Si vous exécutez Claude Code sur un VPS (serveur privé virtuel), vous devez lire ce changement avant son entrée en vigueur. Une invite d’autorisation constitue un point de contrôle qui nécessite la présence d’une personne devant le clavier. Sur une machine distante, vous n’êtes souvent pas présent. Le mode dans lequel une session démarre est donc celui qu’elle conservera pendant plusieurs heures.

Les modes d’autorisation de Claude Code, du contrôle le plus strict au contrôle le plus limité

Il existe six modes. Le nom au début de chaque ligne correspond à la valeur à inscrire dans les paramètres ou à transmettre à --permission-mode. Claude Code applique lui-même ces six modes, et non le modèle, car déterminer ce qu’un appel d’outil est autorisé à faire relève de la responsabilité du harnais qui entoure le modèle.

• default : Claude demande une confirmation avant chaque nouvelle utilisation d’un outil. Les lectures dans votre répertoire de travail s’exécutent tout de même sans confirmation. La CLI (interface de ligne de commande) affiche le nom Manual pour ce mode et accepte manual comme alias depuis Claude Code v2.1.200.
• plan : Claude lit les fichiers et exécute des commandes pour explorer l’environnement, sans modifier votre code source. Les modifications restent bloquées jusqu’à ce que vous approuviez le plan.
• acceptEdits : les modifications de fichiers s’exécutent sans confirmation, ainsi que les commandes de système de fichiers mkdir, touch, rm, rmdir, mv, cp et sed. Cela s’applique uniquement aux chemins situés dans votre répertoire de travail ou votre additionalDirectories. Toutes les autres commandes shell demandent encore une confirmation.
• auto : tout s’exécute, après vérification de chaque action par le classifieur. Les règles explicites ask imposent toujours une confirmation.
• dontAsk : Claude Code refuse automatiquement toute action qui aurait demandé votre confirmation. Seules vos règles allow, les commandes Bash intégrées en lecture seule et les appels approuvés par un hook PreToolUse s’exécutent. La session n’attend jamais de saisie.
• bypassPermissions : les demandes de confirmation et les contrôles de sécurité sont ignorés, y compris les écritures dans des chemins protégés tels que .git et .claude.

Appuyez sur Shift+Tab pendant une session pour passer de default à acceptEdits, puis à plan. La barre d’état indique le mode sélectionné, par exemple ⏵⏵ auto mode on ou un ⏸ manual mode on gris. Les autres modes ne figurent pas dans ce cycle par défaut. auto y est ajouté lorsque votre compte remplit les conditions requises. bypassPermissions y est ajouté uniquement si la session a été démarrée avec --permission-mode bypassPermissions ou --dangerously-skip-permissions. dontAsk n’y apparaît jamais ; définissez-le avec claude --permission-mode dontAsk.

Le mode automatique nécessite également un modèle récent. C’est généralement la raison pour laquelle il n’apparaît pas du tout. En août 2026, la documentation indique Claude Opus 4.6 ou version ultérieure, Sonnet 4.6 ou version ultérieure, ainsi que Fable 5 sur l’API Anthropic. Elle précise aussi que les modèles plus anciens, comme Sonnet 4.5, ne sont pris en charge par aucun fournisseur. Si Claude Code indique que le mode automatique est indisponible, l’une de ces conditions n’est pas remplie. Il ne s’agit pas d’une panne temporaire ; attendre ne résoudra donc pas le problème.

Deux contrôles s’appliquent à tous les modes, y compris bypassPermissions : les règles deny et les règles explicites ask. Ce sont les mécanismes que vous conservez quel que soit le mode utilisé au démarrage d’une session.

Ce que le classificateur du mode automatique bloque

Le classificateur est un second modèle qui lit l’action en attente et détermine si elle correspond à ce que vous avez demandé. La documentation décrit son rôle en une phrase :

Un modèle de classification distinct examine les actions avant leur exécution et bloque celles qui dépassent votre demande, ciblent une infrastructure non reconnue ou semblent motivées par du contenu hostile lu par Claude.

Bloqué par défaut, dans les catégories qu’un administrateur de serveur rencontre le plus souvent :

• Télécharger et exécuter du code, par exemple curl | bash
• Déployer en production et effectuer des migrations
• Effectuer un force push
• Modifier une infrastructure partagée
• Ouvrir un tunnel ou un reverse shell qui rend un service local accessible depuis Internet
• Afficher un identifiant ou un token actif dans la transcription ou dans un fichier

Autorisé par défaut :

• Les opérations sur les fichiers locaux dans votre répertoire de travail
• Installer les dépendances déclarées dans vos lock files ou manifestes
• Effectuer des requêtes HTTP en lecture seule
• Pousser vers n’importe quelle branche du dépôt sur lequel vous travaillez

Ne vous contentez pas d’un résumé comme celui ci-dessus. Exécutez claude auto-mode defaults pour afficher la liste complète des règles au format JSON, puis consultez l’ensemble fourni avec la version installée.

Deux limites documentées sont importantes avant de vous y fier. Premièrement, le classificateur voit vos messages, les appels d’outils et votre contenu CLAUDE.md, mais les résultats des outils sont supprimés. Le texte contenu dans un fichier ou une page web que Claude a lus ne peut donc pas s’adresser directement au classificateur. Deuxièmement, lorsque le classificateur bloque une action 3 fois de suite ou 20 fois au cours d’une session, le mode automatique se met en pause et Claude Code recommence à vous demander une confirmation. Ces seuils ne sont pas configurables. En mode non interactif avec l’option -p, personne ne peut répondre aux demandes de confirmation. Des blocages répétés interrompent donc la session.

C’est le deuxième comportement qui pose problème sur un serveur distant. Une exécution sans supervision qui déclenche la limite s’arrête et attend une personne qui ne regarde pas le terminal. Une deuxième session Claude Code sur le même serveur ne remplace pas cette personne, car le texte envoyé d’une session à l’autre reste en attente jusqu’à ce que la session destinataire le récupère, et une session suspendue sur une demande d’autorisation nécessite toujours une réponse humaine. Réduire le périmètre de ce que l’agent doit accomplir constitue l’autre volet de la solution, et une skill qui incite l’agent à effectuer la modification minimale fonctionnelle empêche une session de se lancer dans les actions complexes que le classifieur bloque. Une skill oriente une tâche, tandis que un style de sortie modifie directement le prompt système : un style qui demande des modifications ciblées et limitées s’applique à chaque tour de la session, et pas uniquement à la tâche pour laquelle vous l’avez appelé.

Où se trouvent les modes dans settings.json

Tout ce qui précède constitue un objet dans un fichier de paramètres.

{
  "permissions": {
    "defaultMode": "auto",
    "allow": [
      "Bash(npm run test *)",
      "Bash(git status)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(docker compose up *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Bash(curl *)"
    ]
  }
}

Les règles sont évaluées dans l’ordre suivant : deny, puis ask, puis allow. La première correspondance dans cet ordre détermine le résultat. Une règle plus précise ne prend pas le dessus sur une règle plus générale placée avant elle. Une règle deny pour Bash(aws *) bloque aws s3 ls, même si vous avez également autorisé cette commande exacte. Une règle deny ne peut donc pas avoir d’exceptions.

ask est le type de règle qui devient utile en mode auto. Le mode auto supprime la demande de confirmation habituelle. Une règle ask la rétablit pour la commande précise qui doit nécessiter une intervention humaine. Votre commande de déploiement doit être placée ici. Il en va de même pour Bash(git push *) si vous voulez un point de contrôle avant que le code ne quitte la machine. Conserver les fichiers d’identifiants dans deny constitue l’autre volet de cette configuration. Cela complète le fait de garder les identifiants hors de portée d’un agent dès le départ.

Les fichiers de paramètres eux-mêmes, du niveau de priorité le plus faible au plus élevé :

• ~/.claude/settings.json : vos paramètres utilisateur, appliqués à tous les projets.
• .claude/settings.json : les paramètres du projet, validés dans le dépôt.
• .claude/settings.local.json : vos propres paramètres pour un dépôt, ignorés par git.
• Paramètres gérés, déployés par un administrateur. Sous Linux, ce fichier est /etc/claude-code/managed-settings.json. Aucune configuration ne remplace une règle d’autorisation gérée, y compris un flag de ligne de commande.

Un piège a une cause documentée. defaultMode: "auto" est ignoré lorsqu’il provient de .claude/settings.json ou de .claude/settings.local.json, à partir de Claude Code v2.1.142, afin qu’un dépôt ne puisse pas s’accorder lui-même le mode auto en fournissant un fichier de paramètres. Si vous le définissez à cet emplacement, la session démarre en mode default sans afficher d’erreur. Déplacez cette ligne dans ~/.claude/settings.json. Exécutez /permissions pour afficher chaque règle active à côté du fichier dont elle provient.

Les deux commutateurs qui désactivent un mode

Les administrateurs disposent de deux commutateurs d’arrêt. Tous deux attendent la chaîne "disable", et non une valeur booléenne.

{
  "permissions": {
    "disableAutoMode": "disable",
    "disableBypassPermissionsMode": "disable"
  }
}

La documentation précise où les placer :

Pour empêcher l’utilisation du mode bypassPermissions ou auto, définissez permissions.disableBypassPermissionsMode ou permissions.disableAutoMode sur "disable" dans n’importe quel fichier de configuration. Ces paramètres sont particulièrement utiles dans une configuration gérée, car ils ne peuvent pas être remplacés.

disableAutoMode retire auto du cycle Shift+Tab et rejette --permission-mode auto au démarrage. disableBypassPermissionsMode fait de même pour le mode bypass et fonctionne depuis n’importe quelle portée. Vous pouvez donc le définir dans votre propre ~/.claude/settings.json pour vous interdire un mode auquel vous préféreriez ne pas recourir à 2h du matin sur un serveur en production. Sur une machine utilisée par d’autres personnes, placez plutôt les deux paramètres dans /etc/claude-code/managed-settings.json, car un fichier de configuration utilisateur appartient à l’utilisateur, contrairement à un fichier de configuration géré.

Pourquoi le mode automatique sur un VPS nécessite une limite d’isolation

Le classifieur examine une action à la fois. Il ne contient pas les effets de l’action approuvée. La documentation établit clairement la distinction :

Le classifieur est un contrôle par action, et non une limite d’isolation. Une limite d’isolation apporte donc une défense en profondeur supplémentaire pour les exécutions sans surveillance. Elle n’est pas requise comme elle l’est pour --dangerously-skip-permissions.

Sur une machine distante, l’association correcte est donc le mode automatique et un environnement que vous acceptez de perdre, pas bypassPermissions et de l’espoir. Le mode bypass est documenté uniquement pour les environnements isolés : conteneurs, machines virtuelles ou dev containers sans accès à Internet, dans lesquels Claude Code ne peut pas endommager votre système hôte. Un VPS qui exécute votre base de données et votre reverse proxy ne correspond à aucun de ces cas.

Trois mesures sont essentielles sur un serveur. Exécutez Claude Code avec un utilisateur standard, jamais avec root. Donnez à cet utilisateur un répertoire de travail, sans autre donnée intéressante à lire. Reconstruisez la machine au lieu de la réparer. C’est l’argument en faveur de une VM jetable que vous supprimez après chaque tâche. Les détails du durcissement, de la création de l’utilisateur aux règles du firewall, sont présentés dans la procédure complète de sécurisation de Claude Code sur un VPS et ne sont donc pas répétés ici.

Claude Code applique lui-même la règle concernant root. Sous Linux et macOS, il refuse de démarrer en mode bypass avec sudo ou en tant que root :

--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons

Ce contrôle est ignoré dans un sandbox reconnu. C’est pourquoi la réponse documentée pour l’exécution autonome dans un conteneur est un dev container qui exécute Claude Code avec un utilisateur non root. Si vous pilotez l’agent depuis un téléphone ou un ordinateur portable via SSH, le même raisonnement s’applique à une session Claude Code longue durée maintenue ouverte dans tmux : personne ne surveille l’invite pendant l’exécution de la session. Rien ne démarre tant que la connexion elle-même ne fonctionne pas. Si la machine vous refuse l’accès avec Permission denied (publickey), la sortie SSH détaillée indiquera lequel des cinq problèmes vous rencontrez réellement.

Configurer le bac à sable Bash sur un VPS Ubuntu

Le bac à sable intégré restreint l’accès au système de fichiers et au réseau de chaque commande Bash exécutée par Claude. Le système d’exploitation applique également ces restrictions aux processus enfants. Sous Linux, deux paquets sont nécessaires.

sudo apt-get install bubblewrap socat

Démarrez Claude Code et exécutez /sandbox. Le panneau s’ouvre avec un onglet Mode et un onglet Overrides, ainsi qu’un onglet Dependencies qui liste les éléments manquants. La vérification des dépendances s’exécute au démarrage. Redémarrez donc Claude Code après l’installation des paquets, sinon le panneau les indiquera toujours comme absents.

Sur Ubuntu 24.04 et les versions ultérieures, la politique AppArmor par défaut empêche bubblewrap de créer les espaces de noms utilisateur dont il a besoin. Le bac à sable ne peut donc pas démarrer. Vérifiez si cela concerne votre serveur :

sysctl kernel.apparmor_restrict_unprivileged_userns

Un 0, ou une erreur indiquant que la clé n’existe pas, signifie qu’aucune action n’est nécessaire. Un 1 signifie que bwrap a besoin de son propre profil :

sudo tee /etc/apparmor.d/bwrap > /dev/null <<'EOF'
abi <abi/4.0>,
include <tunables/global>

profile bwrap /usr/bin/bwrap flags=(unconfined) {
  userns,
  include if exists <local/bwrap>
}
EOF
sudo systemctl reload apparmor

Le profil s’applique à bwrap lui-même, et non aux commandes qu’il exécute dans le bac à sable. Réduisez ensuite le périmètre dans les paramètres :

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "denyRead": ["~/"],
      "allowRead": ["."]
    },
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    }
  }
}

Ce bloc doit figurer dans le fichier .claude/settings.json du projet, car . correspond à la racine du projet uniquement dans les paramètres du projet. Placez les mêmes lignes dans ~/.claude/settings.json et . correspondra à ~/.claude. La règle denyRead continuera alors de bloquer l’accès aux fichiers du projet, et chaque commande ne pourra pas lire le code qu’elle doit modifier.

Sachez ce que cette configuration ne couvre pas. Le bac à sable restreint Bash et ses processus enfants. Les outils de fichiers intégrés s’exécutent dans le processus Claude Code. Les serveurs MCP (model context protocol) et les hooks sont des processus distincts qui s’exécutent sans restriction sur l’hôte. Pour les placer tous derrière une même limite, exécutez l’ensemble du processus Claude Code dans un conteneur, une machine virtuelle ou le paquet @anthropic-ai/sandbox-runtime, qui est encore une préversion de recherche bêta au moment de la rédaction.

À quel mode chaque configuration correspond-elle ?

Un dépôt personnel sur votre ordinateur portable

Utilisez auto, avec les règles ask pour les actions que vous souhaitez voir autorisées. Vous êtes devant le clavier, le repli du classifieur peut effectivement vous solliciter, et les dégâts sont limités à une machine que vous contrôlez. C’est le cas pour lequel la valeur par défaut du 14 August a été définie.

Un VPS partagé

Utilisez auto par utilisateur, défini dans le fichier ~/.claude/settings.json de chaque utilisateur, sur une machine où le compte qui exécute Claude Code n’est pas root et ne peut pas lire le travail des autres utilisateurs. Déployez disableBypassPermissionsMode comme "disable" dans /etc/claude-code/managed-settings.json, avec les règles de refus qui protègent les chemins partagés. Une machine partagée est le cas le plus évident où bypassPermissions est incorrect, car la limite d’isolation supposée par ce mode n’existe pas : les autres utilisateurs se trouvent à l’intérieur de cette limite.

CI et sessions sans supervision

Utilisez dontAsk avec une liste allow explicite des commandes nécessaires au job. Le refus automatique est le comportement approprié lorsqu’aucune personne ne verra de prompt. Le mode automatique fonctionne également de manière non interactive, mais les blocages répétés du classifieur interrompent une session -p. Un job qui les rencontre échoue donc en cours d’exécution, avec un travail partiellement effectué. Réservez bypassPermissions à un conteneur ou une machine virtuelle que vous recréez à partir d’une image, et ne l’utilisez pas sur un hôte qui exécute également des services importants.

FAQ

Quand le mode automatique devient-il le mode par défaut dans Claude Code ?

À partir du 14 août 2026, pour les nouvelles sessions des offres Pro, Max et Team. La documentation précise que vous pouvez changer de mode à tout moment, qu’un mode par défaut défini par vos soins reste en place tant que vous n’acceptez pas l’invite de changement unique, et qu’un mode par défaut géré par votre organisation reste inchangé. L’annonce indique que le mode automatique reste facultatif pour les offres Enterprise et pour les comptes qui utilisent l’API pendant la première phase du déploiement. Vérifiez le mode réellement utilisé par la session dans la barre d’état, qui affiche ⏵⏵ auto mode on en mode automatique.

Dois-je utiliser le mode automatique ou bypassPermissions sur un VPS ?

Le mode automatique, avec une limite d’isolation. Le classifieur examine chaque action avant son exécution, mais la documentation précise qu’il s’agit d’un contrôle par action et non d’une limite d’isolation. Une exécution sans surveillance nécessite donc toujours un conteneur, une machine virtuelle ou un serveur que vous pouvez reconstruire. bypassPermissions ignore entièrement ces contrôles et est documenté uniquement pour les environnements isolés. Claude Code refuse de démarrer dans ce mode en tant que root sous Linux et affiche --dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons.

Comment empêcher tout utilisateur de mon serveur d’utiliser le mode automatique ou le mode bypass ?

Définissez permissions.disableAutoMode et permissions.disableBypassPermissionsMode sur la chaîne "disable" dans /etc/claude-code/managed-settings.json. Les paramètres gérés sont prioritaires sur toutes les autres portées. Aucun fichier de paramètres utilisateur ni aucune option de ligne de commande ne peut donc les remplacer. disableAutoMode supprime auto du cycle Shift+Tab et rejette --permission-mode auto au démarrage. disableBypassPermissionsMode fonctionne également depuis n’importe quelle portée. Un seul utilisateur peut donc le définir dans son propre ~/.claude/settings.json.

Pourquoi mon paramètre defaultMode: "auto" est-il ignoré ?

Parce qu’il se trouve dans le mauvais fichier. Depuis Claude Code v2.1.142, defaultMode: "auto" est ignoré lorsqu’il provient de .claude/settings.json ou de .claude/settings.local.json. Un dépôt ne peut ainsi pas s’accorder lui-même le mode automatique en fournissant un fichier de paramètres. La session démarre en mode default et n’affiche aucune erreur. Déplacez le paramètre vers ~/.claude/settings.json, puis exécutez /permissions pour vérifier de quel fichier provient chaque règle active. Si le mode automatique reste indisponible, vérifiez la version du modèle requise : les modèles plus anciens, comme Sonnet 4.5, ne sont pris en charge par aucun fournisseur.