Claude Code 2.1.271-272 : le mode auto resserre ses contrôles de sécurité

La 2.1.271 de Claude Code, sortie le 14 septembre 2026, resserre le mode auto sur trois fronts à la fois : les commandes shell lancées par un skill ou une commande slash, le retour d'un sous-agent vers son appelant, et l'accès réseau accordé commande par commande. À côté de ça, quatre failles distinctes dans les vérifications de permissions Bash sont refermées d'un coup, et l'outil Monitor perd son option d'attente sans limite de temps. La 2.1.272, sortie le lendemain, ne contient que des correctifs de fiabilité sans détail publié dans le changelog officiel. Voici ce qui change réellement si tu tournes en mode auto.

Les commandes shell d'un skill suivent désormais les règles par défaut, pas le classifieur

En mode auto, c'est un second modèle, le classifieur, qui approuve ou bloque la plupart des actions à ta place, comme le rappelle la doc sur les modes de permission : « In Manual mode, Claude Code stops and asks you before most actions... In auto mode, a second model, the classifier, reviews actions instead of you ». Jusqu'ici, les commandes shell inline lancées avec ! à l'intérieur d'un skill ou d'une commande slash suivaient ce chemin comme n'importe quelle autre commande.

La 2.1.271 change ça : ces commandes passent maintenant par les règles de permission du mode par défaut, celles que tu poses toi-même avec allow, ask et deny. Une commande qu'aucune règle ne couvre explicitement redevient un appel d'outil revu normalement, plutôt que soumis au jugement du classifieur. Concrètement, si tu maintiens des skills avec des commandes shell intégrées, leur comportement en mode auto devient prévisible et pilotable par règle, au lieu de dépendre d'une évaluation au cas par cas.

Le retour d'un sous-agent passe par un appel dédié, revu par le classifieur

La doc sur les modes de permission détaille trois points de contrôle quand un sous-agent travaille en mode auto : avant son lancement, pendant chacune de ses actions, et à la fin, quand « the classifier reviews its full action history ». C'est ce troisième point que la 2.1.271 change : au lieu de relire après coup le dernier message du sous-agent pour repérer un problème, le retour passe désormais par un appel dédié que le classifieur examine directement.

La différence est réelle : une revue a posteriori du dernier message peut manquer une action problématique si le résumé final ne la mentionne pas clairement. Un appel dédié au retour donne au classifieur un point de contrôle explicite, pensé pour ça, au moment précis où le travail du sous-agent revient dans ta conversation.

allowed_domains par commande : un contrôle réseau plus fin sous sandbox

En mode auto avec le sandbox Bash, l'accès réseau suit déjà une règle stricte : « The first time a command needs a new domain, Claude Code prompts for approval, or in auto mode sends the request to the classifier ». Le problème que corrige la 2.1.271, c'est que cette approbation valait ensuite pour toute la session : un domaine ouvert pour une commande restait ouvert pour les suivantes.

La nouveauté, un paramètre allowed_domains par commande pour Bash, PowerShell et Monitor, change la granularité : les domaines dont une commande a besoin sont revus avec elle et ouverts pour elle seule, les autres restent refusés. Si une tâche ponctuelle a besoin d'atteindre un service externe, l'accès ne traîne plus après coup pour le reste de la session.

Quatre failles de vérification des permissions Bash refermées d'un coup

La même version corrige quatre angles morts distincts dans la façon dont Claude Code lit une commande Bash avant de décider si elle a besoin d'une permission :

• un fichier lu par fmt, column et des commandes similaires pouvait échapper à la vérification quand il suivait une option que le vérificateur ne reconnaissait pas ;
• un fichier atteint par une expansion de wildcard dans le motif ou la valeur d'une option, comme grep -v dir/* file, pouvait sauter le même contrôle ;
• des options de déclaration de variable shell pouvaient déguiser la commande réellement exécutée aux yeux du vérificateur ;
• une commande Bash combinant deux changements de répertoire, un sous-shell, ou un enchaînement cd+git, pouvait contourner l'invite de confirmation attendue sous permissions.blockReadsOutsideWorkingDirectories, en bypass comme en mode auto.

Pris un par un, ce sont des cas limites. Ensemble, ce sont quatre façons dont une commande pouvait faire plus que ce que sa lecture superficielle laissait penser, sans déclencher le contrôle censé s'appliquer. Si tu utilises blockReadsOutsideWorkingDirectories ou des commandes riches en wildcards, cette version referme un vrai trou.

Monitor plafonné à 30 minutes, l'option persistante disparaît

L'outil Monitor servait jusqu'ici les tâches d'attente longue avec une option persistent sans limite de temps. La 2.1.271 la retire : « Every watch Claude starts has a deadline: 5 minutes by default, at most 30 minutes, and at most 10 minutes in a non-interactive run given a single prompt with -p ». À l'échéance, le watch s'arrête et Claude reçoit un avis unique, à charge pour lui de relancer une surveillance si elle est encore utile.

Si tu avais un watch de longue durée configuré en persistent, par exemple pour suivre un déploiement lent ou une CI qui traîne, il faudra désormais compter sur cet avis, et sur une relance décidée par Claude, plutôt que sur une attente continue.

Le reste, en vrac

• Le mode rapide (/fast) est disponible dans les sessions Claude Code Remote, cloud comme auto-hébergées, selon le réglage de l'hôte ou ce que tu tapes dans la session.
• /config en plein écran gagne la souris : la molette fait défiler, un clic change la valeur d'un réglage.
• omitClaudeMd dans le frontmatter d'un agent personnalisé ou plugin permet de le faire tourner sans charger les fichiers CLAUDE.md, tout en gardant les politiques managées.
• --accept-command <sha256> s'ajoute à claude plugin install et claude plugin update : tu acceptes exactement la commande affichée par un précédent passage en --json, au lieu d'un -y aveugle.
• /resume et /teleport ne gardent plus le suivi des fichiers lus de la conversation précédente, qui laissait Claude éditer des fichiers que la session reprise n'avait jamais ouverts.
• Les artefacts Markdown publiés se rendent maintenant comme des pages de document stylées, avec titre et coloration syntaxique du code.
• Le nombre d'artefacts surveillables pour republication passe de 5 à 10 par session.
• VS Code corrige plusieurs bugs des dialogues Hooks et règles de permission, dont des sauvegardes qui semblaient échouer alors qu'elles réussissaient.
• Claude Tag ne perd plus le contexte d'un canal actif toutes les heures quand la conversation se passe surtout en fils, et reprend le suivi d'une pull request après un redémarrage dans le même fil.
• Code Review ne republie plus deux ou trois fois la même trouvaille, et ne repousse plus un signalement de sécurité déjà résolu quand un push déplace les lignes concernées.
• Windows : les commandes PowerShell qui échouaient avec « Exit code 1 » et aucune sortie, quand le chemin de sortie temporaire de la session atteignait 260 caractères, fonctionnent à nouveau.
• La taille par défaut d'un workflow dynamique baisse sur les plans Pro, et le seuil indicatif de la taille moyenne passe de 15 à 10 agents.

Ce qu'il faut retenir

Si tu tournes au quotidien en mode auto, les trois premiers changements de cette version pointent tous dans la même direction : moins de zones grises laissées au jugement du classifieur, plus de points de contrôle explicites, que ce soit pour une commande shell de skill, le retour d'un sous-agent, ou un domaine réseau ouvert pour une seule commande plutôt que pour toute la session. Les quatre correctifs de permissions Bash comptent surtout si tu utilises blockReadsOutsideWorkingDirectories ou des commandes construites avec des wildcards et des sous-shells. Et si un de tes workflows s'appuyait sur un Monitor persistent, il faut désormais composer avec un plafond de 30 minutes.