Claude Code 2.1.269 : une règle de permission recadrée, l'attribution rendue au CLAUDE.md

La 2.1.269 de Claude Code est sortie le 11 septembre 2026, le lendemain de la 2.1.268 couverte dans le digest précédent. Deux correctifs touchent directement ce que Claude Code applique de ton côté sans que tu l'aies décidé : une règle de permission qui débordait de son propre fichier de réglages, et un rappel d'attribution qui imposait ses lignes de commit même quand ton CLAUDE.md disait le contraire. À côté de ça, les skills synchronisés depuis claude.ai changent de nom, et une nouvelle commande permet de tester un plugin sans repasse humaine à chaque changement.

Une règle deny qui débordait de son propre fichier de réglages

Une règle de permission peut venir de plusieurs sources à la fois : réglages utilisateur, projet, local, ou politique managée par une organisation. La doc sur les permissions le rappelle, le dialogue /permissions liste chaque règle avec le fichier settings.json dont elle provient, précisément parce que ces sources se superposent et qu'il faut pouvoir tracer d'où vient chaque décision.

La 2.1.269 corrige un bug sur les règles deny et ask qui commencent par !, une syntaxe de négation héritée des motifs gitignore que ces règles utilisent, et destinée à retirer un chemin de la portée d'une autre règle. Le problème : cette négation pouvait s'appliquer au-delà de la source qui l'avait écrite, donc annuler une règle posée dans une autre source, y compris potentiellement une règle plus stricte venue d'une politique managée. Une négation écrite dans un fichier de réglages local n'a normalement aucune raison d'affaiblir ce qu'une organisation impose plus haut dans l'ordre de préséance décrit par la doc sur les fichiers de réglages. C'est désormais corrigé : une règle ! ne s'applique plus qu'à l'intérieur de sa propre source. Un ! isolé, sans règle derrière, est maintenant ignoré plutôt que traité comme une négation valide.

Ton CLAUDE.md reprend la main sur l'attribution des commits

Deuxième correctif de comportement par défaut, et celui-ci concerne à peu près tous ceux qui versionnent du code avec Claude Code : le rappel interne qui ajoute les lignes d'attribution (Co-Authored-By, mention Claude Code) aux commits et aux pull requests l'emportait jusqu'ici sur une règle de ton CLAUDE.md ou de ta mémoire qui demandait explicitement de ne pas les ajouter. Autrement dit, écrire noir sur blanc dans ton CLAUDE.md que tu ne veux pas de ces lignes ne suffisait pas à les supprimer, le rappel gagnait quand même.

La doc sur la mémoire est claire sur le principe général : CLAUDE.md est du contexte que Claude essaie de suivre, pas une configuration appliquée de force, contrairement à une règle de permission. La 2.1.269 aligne l'attribution sur ce principe : une instruction contre l'attribution dans ton CLAUDE.md ou ta mémoire est désormais respectée. Seule exception, logique : une ligne d'attribution imposée par les réglages managés d'une organisation continue de s'appliquer, elle, quoi que dise ton CLAUDE.md personnel.

Les skills synchronisés depuis claude.ai changent de nom

Les skills que tu configures sur claude.ai et qui se synchronisent dans une session cloud Claude Code s'invoquent désormais sous la forme anthropic-skills:<nom>, au lieu du nom nu utilisé jusque-là. Ce n'est pas arbitraire : c'est le même schéma de namespace que celui déjà en place pour les skills de plugin, documenté sur la page sur les skills, où un skill de plugin s'appelle /plugin-name:skill-name pour éviter qu'un nom générique entre en collision avec un autre. Claude Desktop utilisait déjà cette convention, la 2.1.269 aligne les sessions cloud dessus.

Le nom nu continue de fonctionner tant que rien d'autre ne le revendique, exactement comme pour un skill de plugin classique. Si tu as pris l'habitude d'invoquer un skill synchronisé par son nom seul dans un script ou une routine, ça continue de marcher sauf collision, mais la forme complète est désormais la référence stable si tu veux être sûr de viser le bon skill.

`claude plugin eval` : mesurer un plugin sans repasse humaine

Nouvelle commande, claude plugin eval, qui fait tourner la suite de tests d'un plugin, un ensemble de prompts réalistes couplés à des critères de réussite, et en sort un score reproductible en JSON et en rapport HTML. La doc sur les evals de plugin situe bien la différence avec ce qui existait déjà : claude plugin validate vérifie que la structure et la syntaxe d'un plugin sont correctes, alors qu'un eval vérifie son comportement réel, à quelle fréquence Claude s'en sert et obtient le bon résultat, y compris comparé à une session sans le plugin du tout.

Concrètement, ça permet de brancher un score de plugin sur une CI et de détecter une régression dès qu'on modifie le plugin ou qu'un nouveau modèle sort, plutôt que de le découvrir en production. Si tu distribues un plugin à une équipe ou sur une marketplace, c'est le contrôle qui manquait entre « ça charge sans erreur » et « ça fait vraiment ce qu'on attend de lui ».

Le reste, en vrac

/output-style [name] liste et change de style de sortie directement, y compris depuis Remote Control et dans les sessions cloud ou headless.
Les sessions distantes et headless n'affichent plus « en attente de ta réponse » alors que des agents en arrière-plan tournent encore ; CLAUDE_CODE_BG_TASKS_REPORT_RUNNING=0 restaure l'ancien affichage si tu préfères.
permission_denials dans la sortie --output-format stream-json n'omet plus les appels Read, Edit et Write bloqués par une règle deny scopée à un chemin, ce qui fermait un angle mort pour qui audite ces refus par script.
Les règles deny Edit() et la vérification du chemin d'écriture s'appliquent maintenant au fichier qu'écrit un tee lancé en Bash, et une règle allow Bash(tee:*) ne couvre plus les destinations hors des répertoires de travail.
Le résultat de l'outil Bash peut inclure un diff des fichiers qu'une commande a modifiés quand c'est Bash qui se charge de l'édition, via le réglage bashEditDiffEnabled.
Deux correctifs de cache de prompt : le cache n'est plus partiellement invalidé au tour qui suit une réponse coupée puis reprise automatiquement à la limite de tokens, et reprendre une session juste après avoir interrompu Claude en plein raisonnement ne change plus la façon dont le contexte précédent est renvoyé.
CLAUDE_CODE_WORKFLOW_MAX_CONCURRENT_AGENTS relève le plafond d'agents concurrents de l'outil Workflow, utile pour les répartitions de tâches limitées par la vitesse d'inférence plutôt que par autre chose.
VS Code gagne un dialogue Hooks et un dialogue de règles de permission dans le menu de commandes, pour lister, ajouter, modifier ou retirer des hooks et des règles sans éditer settings.json à la main.
Claude Code sur le web permet de reprendre un message mis en file d'attente dans une session cloud avant que Claude ne le lise, en le retirant de la file ou en appuyant sur Échap ou flèche haut, et le texte revient dans la zone de saisie.

Ce qu'il faut retenir

Si tu es en solo avec un compte claude.ai classique, la ligne qui te concerne le plus directement est celle sur l'attribution : si tu avais déjà écrit dans ton CLAUDE.md ou ta mémoire que tu ne voulais pas des lignes Co-Authored-By sur tes commits et que ça ne marchait pas, ça devrait fonctionner à partir de cette version. Le correctif sur les règles ! vise surtout les configurations qui empilent plusieurs sources de réglages, typiquement en équipe ou avec une politique managée. Le renommage des skills synchronisés ne casse rien tant qu'il n'y a pas de collision de nom, et claude plugin eval s'adresse aux auteurs de plugins qui veulent un score plutôt qu'un ressenti sur ce que leur plugin apporte vraiment.