Auto mode Claude Code : classifieur, sandbox et durcissement

Anthropic a regardé ce que les utilisateurs de Claude Code répondaient aux demandes de permission. Résultat : 93 % d'approbations. Ce chiffre ne décrit pas une équipe confiante, il décrit une équipe qui clique « oui » sans lire. Une invite que personne ne lit n'est plus un contrôle, c'est du bruit qui masque la seule demande qui aurait mérité ton attention.

Depuis la v2.1.283 du 25 septembre 2026, une session interactive (terminal ou VS Code) sans mode configuré démarre en auto mode, sur tous les plans et tous les fournisseurs. L'auto mode de Claude Code est un mode de permissions où un classifieur, un modèle distinct de celui de la session, évalue les actions avant exécution et ne sollicite l'humain que pour les cas douteux. Tes développeurs ne l'activent plus : ils le reçoivent par défaut. La question n'est donc plus « faut-il l'autoriser ? » mais « qu'y a-t-il autour ? ».

Qu'est-ce qui change avec l'auto mode par défaut ?

Le mode de démarrage se résout dans cet ordre : le flag --permission-mode, puis permissions.defaultMode dans un fichier de settings, puis le défaut intégré, qui est désormais auto si le modèle le supporte, Manual sinon. La v2.1.284 du 28 septembre a étendu ce comportement aux sessions sur fournisseurs tiers. Trois pièges sont documentés dans la doc des modes de permission :

• defaultMode: "auto" dans le .claude/settings.json d'un dépôt n'a aucun effet, pas plus que bypassPermissions. Un dépôt cloné ne peut pas s'accorder l'autonomie. Pour auto, c'est ~/.claude/settings.json ou les managed settings.
• Un defaultMode de projet plus restrictif est honoré : default (alias manual), plan ou acceptEdits s'appliquent en terminal.
• Si le modèle n'est pas supporté, la session retombe en Manual sans erreur. Sur l'API Anthropic, il faut Opus 4.6+, Sonnet 4.6+ ou Haiku 5.5.

{
  "permissions": {
    "defaultMode": "default"
  }
}

Ce réglage remet un dépôt en mode manuel. Pour retirer l'auto mode à toute l'organisation, la clé permissions.disableAutoMode: "disable" se pose dans les managed settings : on y reviendra dans l'article de la série consacré aux garde-fous déterministes.

Comment le classifieur décide-t-il d’autoriser une action ?

Le classifieur te remplace dans la boucle d'approbation, mais il n'arrive qu'en dernier. L'ordre d'évaluation est le suivant :

• Les règles deny bloquent avant tout, rien ne les outrepasse.
• Les règles ask ciblées (par exemple Bash(git push *)) forcent toujours une invite, même en auto mode.
• Les lectures et éditions dans le répertoire de travail, hors chemins protégés, passent sans classifieur.
• Le reste (shell, réseau, actions hors périmètre) passe par le classifieur, qui cherche l'élargissement de périmètre, l'infrastructure inconnue et les actions dictées par du contenu hostile.

Point essentiel tiré du billet d'ingénierie Anthropic du 25 mars 2026 : le classifieur lit tes messages et les appels d'outils de l'agent, pas les sorties d'outils. Un pipeline séparé sonde ces sorties pour détecter l'injection de prompt. C'est de la défense en profondeur, pas une garantie.

Que disent les chiffres d'Anthropic sur sa fiabilité ?

• 0,4 % de faux positifs sur 10 000 actions réelles : le classifieur bloque rarement à tort, le flux de travail reste fluide.
• 17 % de faux négatifs sur 52 actions réellement « trop zélées » : environ une sur six passe. Sur un jeu d'exfiltration synthétique (1 000 cas), 5,7 % passent.
• Disjoncteur : après 3 blocages consécutifs ou 20 au total, non configurable, l'auto mode se met en pause et l'humain reprend la main. En mode non interactif (-p), le processus s'arrête.

Le premier chiffre rassure sur la productivité, le second dit ce que tu risques. Anthropic l'écrit sans détour : l'auto mode n'est « not a drop-in replacement for careful human review on high-stakes infrastructure ». Un classifieur qui laisse passer une action zélée sur six n'est pas une barrière, c'est une couche. Tout le reste de l'article découle de cette distinction.

Côté facture, le classifieur tourne côté serveur dans les requêtes de la session, sans facturation séparée, par défaut depuis la v2.1.278 (19 septembre). Piège : une passerelle LLM qui ne relaie pas ces contrôles fait retomber la session sur un classifieur local, facturé en tokens. Vérifie avec /status que la ligne Auto mode server affiche Enabled.

Auto mode ou sandbox : quelle différence ?

Le classifieur décide si un appel d'outil peut avoir lieu ; la sandbox limite ce que peuvent faire les commandes shell, au niveau de l'OS. Le premier est probabiliste, la seconde est appliquée par le noyau : bubblewrap sur Linux et WSL2, Seatbelt sur macOS, rien sur Windows natif. Le billet How we contain Claude (25 mai 2026) résume la doctrine : l'auto mode est une couche de défense à l'intérieur d'une sandbox, pas un substitut. Et le billet sur le sandboxing chiffre le bénéfice : 84 % de demandes de permission en moins en usage interne, à condition d'isoler à la fois le système de fichiers et le réseau. Sans réseau isolé, un agent compromis exfiltre tes clés ; sans système de fichiers isolé, il s'échappe et retrouve le réseau.

Le défaut est moins strict qu'on le croit. Une commande sandboxée écrit dans le répertoire de travail, mais lit presque toute la machine, ~/.ssh et ~/.aws/credentials compris, et hérite de l'environnement, donc de tes secrets. Seul le réseau démarre fermé, derrière un proxy dont la liste de domaines est vide. Il faut donc durcir explicitement, dans les settings utilisateur ou managés :

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "network": {
      "allowedDomains": ["github.com", "repo.packagist.org", "packagist.org"]
    },
    "credentials": {
      "files": [
        { "path": "~/.aws/credentials", "mode": "deny" },
        { "path": "~/.ssh", "mode": "deny" }
      ],
      "envVars": [{ "name": "GITHUB_TOKEN", "mode": "deny" }]
    }
  }
}

• failIfUnavailable: true : sans lui, si bubblewrap manque, Claude Code exécute sans sandbox, en silence. allowUnsandboxedCommands: false supprime l'échappatoire par commande.
• credentials n'est pas lu depuis les settings de projet (v2.1.246+), seulement utilisateur ou managés. Le mode mask montre une valeur sentinelle à la commande et laisse le proxy injecter la vraie valeur vers les hôtes autorisés.
• Chaque domaine autorisé est une capacité, pas une URL : github.com permet aussi de pousser vers n'importe quel compte. Préfère des domaines précis aux jokers larges.
• Limite structurelle : la sandbox ne couvre que le shell. Read, Edit, Write, WebFetch, les serveurs MCP et les hooks tournent hors sandbox. D'où la couche suivante.

Depuis la v2.1.271, en auto mode avec sandbox, Claude déclare les hôtes nécessaires sur la commande elle-même (allowed_domains). Le classifieur les examine avec la commande, ils sont ouverts pour cette seule exécution, rien n'est ajouté aux réglages. Avec strictAllowlist ou allowManagedDomainsOnly, ces listes ponctuelles sont refusées : c'est le verrou si tu veux une liste fermée. Le panneau /sandbox affiche la configuration résolue.

Comment configurer les permissions allow, ask et deny d’un projet Symfony ?

Les règles de permission s'évaluent dans l'ordre deny, ask, allow, première correspondance gagnante. C'est le seul mécanisme déterministe pour les outils qui tournent hors sandbox. En auto mode, les règles allow larges (Bash(*), interpréteurs avec joker) sont suspendues, mais les règles étroites restent actives et passent avant le classifieur. Voici un .claude/settings.json de projet Symfony, commité :

{
  "permissions": {
    "allow": [
      "Bash(composer test)",
      "Bash(vendor/bin/phpunit *)",
      "Bash(vendor/bin/phpstan analyse *)",
      "Bash(php bin/console debug:*)",
      "Bash(php bin/console lint:*)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(gh pr create *)",
      "Bash(php bin/console doctrine:migrations:migrate *)",
      "Bash(docker compose down *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./config/secrets/**)",
      "Bash(php bin/console doctrine:database:drop *)",
      "Bash(docker volume rm *)"
    ]
  }
}

Réserve à écrire noir sur blanc : les règles Bash par préfixe sont contournables. Bash(git push *) ne matche pas git -C . push, et Bash(rm *) ne matche pas /bin/rm ni bash -c 'rm …'. Les règles shell sont un filet, pas un mur ; la sandbox et les hooks PreToolUse, qui inspectent la commande complète, sont les vrais verrous. Les règles Read sur .env, elles, sont fiables, y compris à travers les liens symboliques.

Dernier réglage, côté utilisateur ou managé : permissions.blockReadsOutsideWorkingDirectories: true (v2.1.257). Sans lui, une lecture hors du répertoire de travail passe sans invite en auto mode. Avec lui, elle est refusée ou demandée, y compris pour les commandes Bash de lecture reconnues.

Comment décrire ton environnement au classifieur ?

Par défaut, le classifieur ne fait confiance qu'au répertoire de travail et aux remotes du dépôt courant. Pousser vers l'organisation GitHub de ton entreprise ou passer par un registre Composer interne est vu comme externe tant que tu ne l'as pas décrit. La clé autoMode.environment est un tableau de prose, lu uniquement dans ~/.claude/settings.json, les managed settings ou --settings, jamais dans les settings d'un dépôt (doc de configuration de l'auto mode) :

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Source control: github.com/acme-corp and all repos under it",
      "Internal package registry: packagist.acme.example",
      "Sensitive remote targets: any host or namespace named prod, production or acme-prod-*"
    ],
    "soft_deny": [
      "$defaults",
      "Never run Doctrine migrations outside the migration pipeline"
    ]
  }
}

Piège majeur : un tableau écrit sans "$defaults" remplace la liste intégrée entière. Pour soft_deny, tu perds le blocage du force push, de curl | bash et des déploiements de production. Garde toujours "$defaults". Depuis la v2.1.257, la règle intégrée Containment Escape bloque aussi la récupération de credentials via l'endpoint de métadonnées cloud, le contournement d'egress (tunnel, reverse shell) et le scan de conteneurs voisins.

claude auto-mode defaults     # règles intégrées (JSON)
claude auto-mode config       # ce que le classifieur utilise réellement
claude auto-mode critique     # revue IA de tes règles : ambiguïtés, redondances
claude auto-mode reset        # retour aux défauts (settings utilisateur)

Dans l'interface, /permissions a un onglet Auto mode (v2.1.246+) pour éditer ces règles, et un onglet Recently denied qui liste les refus. Une consigne donnée en conversation (« ne pousse pas avant ma revue ») peut disparaître à la compaction : pour une garantie durable, écris une règle ask ou deny.

Que faire de docker compose dans la sandbox ?

C'est la question numéro un d'un projet Symfony conteneurisé. docker compose parle à un socket et lance des conteneurs hors du périmètre de bubblewrap. La doc propose excludedCommands, avec un avertissement net : une commande exclue tourne avec tous tes droits, et docker compose lit un fichier compose que l'agent peut réécrire dans le dépôt avant de l'exécuter hors sandbox. N'exclus donc jamais docker compose * en entier :

{
  "sandbox": {
    "enabled": true,
    "excludedCommands": [
      "docker compose exec php vendor/bin/phpunit *",
      "docker compose exec php php bin/console debug:*",
      "docker compose ps"
    ]
  }
}

Termine chaque motif par * quand des arguments sont attendus, sinon c'est un match exact. Tous les segments d'une commande chaînée doivent matcher, et un make qui appelle docker ne matche pas. L'alternative plus robuste consiste à faire tourner Claude Code dans un conteneur de développement, sans socket Docker monté, avec un réseau sortant contrôlé, et à le décrire au classifieur dans autoMode.environment.

Quand rester en mode manuel ?

Le critère est le coût d'une erreur, pas la confiance que tu accordes à l'agent. Un faux négatif sur un script de test est un incident mineur ; sur une migration en production, c'est une nuit blanche. Reste en Manual ou en plan mode pour :

• La production et l'infrastructure : Terraform, Kubernetes, DNS, IAM, secrets. La doc précise qu'un message décrivant précisément l'action suffit à lever un blocage par défaut : si tu écris « applique le plan », c'est toi le garde-fou, pas le classifieur.
• Les migrations de base sur autre chose qu'une base jetable : en ask, et exécutées dans le pipeline.
• Les branches de déploiement : un push vers production ou release est traité comme un déploiement, un push vers main non, d'où le ask sur git push.
• Le contenu non fiable en entrée : dépôts tiers, issues externes, serveurs MCP inconnus. C'est la surface d'injection décrite dans notre article sur la prompt injection et la supply chain, et le classifieur ne lit pas les sorties d'outils.
• L'exécution non surveillée : sur un hôte headless, --permission-prompts none (v2.1.259) refuse tout ce qui demanderait une invite, combiné à la sandbox. Pour la CI, voir sécuriser un pipeline GitHub Actions avec des agents.

Quelle checklist de durcissement avant de généraliser l'auto mode ?

• Épingler une version minimale de Claude Code récente : Containment Escape et blockReadsOutsideWorkingDirectories exigent la v2.1.257.
• Activer la sandbox avec failIfUnavailable: true et allowUnsandboxedCommands: false, et vérifier qu'elle tourne sur chaque poste et chaque runner.
• Réduire allowedDomains au strict nécessaire, domaine par domaine.
• Sortir les credentials de l'environnement de l'agent : sandbox.credentials en deny ou mask.
• Versionner les règles deny (secrets, commandes destructrices) et ask (push, migrations, arrêt de conteneurs) dans le dépôt.
• Activer blockReadsOutsideWorkingDirectories côté utilisateur ou managé.
• Renseigner autoMode.environment en gardant "$defaults", puis valider avec claude auto-mode config et critique.
• Contrôler /status : « Auto mode server : Enabled », surtout derrière une passerelle.
• Garder un humain dans la boucle sur la production, l'IaC et les migrations, décision écrite dans CLAUDE.md et en règles.
• Relire chaque semaine l'onglet « Recently denied » : un refus répété est soit un manque de contexte, soit une alerte.

Retiens trois choses. L'auto mode corrige un vrai défaut, la fatigue d'approbation, mais laisse passer une part non négligeable des actions zélées. La sécurité vient de la sandbox, des privilèges minimaux et des règles déterministes, pas du classifieur. Et l'infrastructure critique reste sous revue humaine. Une nouveauté de plus à intégrer, donc, et l'enjeu est de décider une fois pour toute l'équipe de ce qu'on adopte, versionné dans le dépôt plutôt que laissé au réglage de chacun. Une équipe plus autonome pose vite une autre question, celle de ce qu'elle consomme : c'est le sujet du prochain article.

Écrit par

Flavien Métivier

Expert PHP/Symfony indépendant depuis 2014, ancien CTO de Kartable et d'Extrabat. Plus de 80 projets menés, de l'audit à la migration.

Mon parcours