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 confirmation et soumet d’abord chaque action à un modèle de classification distinct pour vérification. À partir du 14 août 2026, il devient le mode utilisé par défaut au démarrage des nouvelles sessions sur les offres Pro, Max et Team. Vous pouvez changer de mode à tout moment. Un réglage par défaut que vous avez déjà défini n’est pas remplacé.

La documentation présente ce changement ainsi :

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

Deux clauses sont plus importantes que la date. Un defaultMode que vous avez défini dans votre propre fichier de configuration reste en place après le changement. Un réglage par défaut déployé par votre organisation via des paramètres gérés reste également inchangé. Le billet d’annonce précise 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), il est préférable de 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 au clavier. Sur une machine distante, vous n’êtes souvent pas devant l’écran. Le mode utilisé au démarrage d’une session reste donc généralement actif 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 à écrire dans les settings ou à transmettre à --permission-mode.

• default : Claude demande une confirmation avant chaque nouvelle utilisation d’un outil. Les lectures à l’intérieur de 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 le projet, sans modifier vos sources. Les modifications restent bloquées jusqu’à l’approbation du plan.
• acceptEdits : les modifications de fichiers s’exécutent sans confirmation, comme les commandes filesystem mkdir, touch, rm, rmdir, mv, cp et sed. Cela s’applique uniquement aux chemins situés dans votre répertoire de travail ou dans votre additionalDirectories. Toute autre commande shell demande toujours une confirmation.
• auto : toutes les actions s’exécutent, après vérification préalable par le classifieur. Les règles explicites ask imposent toujours une confirmation.
• dontAsk : Claude Code refuse automatiquement toute action qui aurait demandé une confirmation. Seules vos règles allow, les commandes Bash en lecture seule intégrées 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 pour 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 l’intègre une fois que votre compte remplit les conditions requises. bypassPermissions l’intègre uniquement lorsque la session a été démarrée avec --permission-mode bypassPermissions ou --dangerously-skip-permissions. dontAsk n’y apparaît jamais ; définissez-le donc 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 une version ultérieure, Sonnet 4.6 ou une version ultérieure, ainsi que Fable 5 sur l’API Anthropic. Elle précise aussi que les anciens modèles, comme Sonnet 4.5, ne sont pris en charge par aucun provider. 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 paramètres que vous conservez quel que soit le mode utilisé au démarrage d’une session.

Ce que le classifieur du mode automatique bloque

Le classifieur est un second modèle qui lit l’action en attente et vérifie 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ées par défaut, parmi les catégories les plus courantes pour un administrateur de serveur :

• 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 public
• Afficher un identifiant ou un token actif dans la transcription ou dans un fichier

Autorisées par défaut :

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

Ne vous basez pas sur 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 de règles fourni avec la version installée.

Deux limites documentées sont importantes avant de vous y fier. Premièrement, le classifieur 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 consulté par Claude ne peut donc pas s’adresser directement au classifieur. Deuxièmement, lorsque le classifieur 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 votre autorisation. Ces seuils ne sont pas configurables. En mode non interactif avec l’option -p, personne ne peut répondre à la demande. Des blocages répétés interrompent donc la session.

C’est ce second comportement qui pose problème sur un serveur distant. Une exécution sans surveillance qui atteint cette limite s’arrête et attend une intervention alors que personne ne regarde le terminal. Limiter les actions prévues par l’agent constitue l’autre partie de la solution, et une skill qui oriente l’agent vers la plus petite modification fonctionnelle évite qu’une session s’égare vers les actions étendues que le classifieur bloque.

Où se trouvent les modes dans settings.json

Tout ce qui précède constitue un seul objet dans un fichier de configuration.

{
  "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 l’emporte pas 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 comporter d’exceptions.

ask est le type de règle qui est 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 à cet endroit. Il en va de même pour Bash(git push *) si vous voulez imposer un point de contrôle avant que le code ne quitte le serveur. Conserver les fichiers d’identifiants dans deny constitue l’autre volet de cette approche. Cela va de pair avec le fait de maintenir les identifiants hors de portée d’un agent dès le départ.

Les fichiers de configuration 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. Rien ne remplace une règle d’autorisation gérée, pas même une option de ligne de commande.

Un piège a ici une cause documentée. defaultMode: "auto" est ignoré lorsqu’il provient de .claude/settings.json ou de .claude/settings.local.json, depuis 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 configuration. Si vous le définissez à cet endroit, 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 acceptent la chaîne "disable" plutôt qu’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 options sont particulièrement utiles dans une configuration gérée, car elles ne peuvent pas y être remplacées.

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

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

Le classifieur examine une action à la fois. Il n’empêche pas une action approuvée d’effectuer ensuite d’autres opérations. La documentation établit clairement la distinction :

Le classifieur contrôle chaque action individuellement, mais ne constitue pas une limite d’isolation. Une limite d’isolation fournit 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 un serveur distant, l’association appropriée est donc le mode auto et un environnement que vous acceptez de perdre, et non bypassPermissions avec l’espoir que tout se passe bien. 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 le 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 et aucun autre fichier important à lire. Reconstruisez le serveur au lieu de le réparer. C’est le principe de la VM jetable que vous supprimez après chaque tâche. Les détails du hardening, 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 pour exécuter 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

Cette vérification est ignorée dans un sandbox reconnu. C’est pourquoi la solution documentée pour exécuter un agent de manière autonome dans un conteneur consiste à utiliser un dev container dans lequel Claude Code s’exécute avec un utilisateur non root. Si vous pilotez l’agent depuis un téléphone ou un laptop via SSH, le même raisonnement s’applique à une session Claude Code de longue durée maintenue ouverte dans tmux : personne ne surveille l’invite pendant l’exécution de la session.

Configurer le bac à sable Bash sur un VPS Ubuntu

Le bac à sable intégré limite 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

Lancez Claude Code et exécutez /sandbox. Le panneau s’ouvre avec un onglet Mode et un onglet Overrides, ainsi qu’un onglet Dependencies qui répertorie les éléments manquants. La vérification des dépendances est effectuée 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 policy AppArmor par défaut empêche bubblewrap de créer les user namespaces 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 .claude/settings.json du projet, car . ne se résout vers la racine du projet que depuis les paramètres du projet. Si vous placez les mêmes lignes dans ~/.claude/settings.json, . se résout vers ~/.claude à la place. La règle denyRead bloque alors les fichiers de votre projet et chaque commande ne peut pas lire le code qu’elle est censée modifier.

Sachez ce que cette configuration ne couvre pas. Le bac à sable limite 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 boundary, exécutez l’ensemble du processus Claude Code dans un conteneur, une machine virtuelle ou le paquet @anthropic-ai/sandbox-runtime, qui est une preview de recherche beta au moment de la rédaction.

Quel mode convient à chaque configuration ?

Un dépôt personnel sur votre ordinateur portable

Utilisez auto, avec les règles ask pour les actions que vous souhaitez voir passer. Vous êtes devant le clavier, le repli du classifieur peut réellement vous atteindre et les dommages sont limités à une seule machine que vous contrôlez. C’est le cas pour lequel la valeur par défaut du 14 août a été conçue.

Un VPS partagé

Utilisez auto par utilisateur, défini dans le propre 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.

CI et sessions sans surveillance

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 jamais d’invite. Le mode automatique fonctionne également sans interaction, 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 depuis une image, et ne l’utilisez pas sur un hôte qui exécute également des services importants pour vous.

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 actif 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 les comptes qui utilisent l’API pendant la première phase du déploiement. Vérifiez le mode réellement utilisé par une 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, associé à 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 doit donc utiliser un conteneur, une machine virtuelle ou un serveur que vous êtes prêt à 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 toute personne sur 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 aucun flag de ligne de commande ne peut donc les remplacer. disableAutoMode supprime auto du cycle Shift+Tab et refuse --permission-mode auto au démarrage. disableBypassPermissionsMode fonctionne également depuis n’importe quelle portée. Un 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 donc 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 dans ~/.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 configuration requise du modèle : les modèles plus anciens, comme Sonnet 4.5, ne sont pris en charge par aucun provider.