Claude Code 2.1.289 : cinq angles morts sur les permissions refermés d'un coup

La 2.1.289 de Claude Code, sortie le 3 octobre 2026, ne contient quasiment aucune nouveauté visible : la quasi-totalité des presque trente entrées concerne des bugs internes aux plugins et aux mods, surtout à leur affichage. Mais au milieu de ce ménage, cinq correctifs distincts referment chacun un angle mort dans les garde-fous de permissions, dont quatre contournements réels des règles deny et ask, le mécanisme qui doit bloquer une action avant qu'elle ne s'exécute. Deux touchent la frontière entre ce qu'un utilisateur installe et ce qu'une organisation gère, trois touchent la façon dont une règle reconnaît la commande ou le fichier qu'elle doit bloquer. Pris un par un, aucun n'est spectaculaire. Ensemble, ils dessinent la même série que les versions précédentes de ce digest : un garde-fou qui existe déjà, et une forme précise qui lui échappait encore.

Les mods et les permissions managées : l'approbation ne doit plus tout emporter

Un mod est un plugin qui tourne à l'intérieur de Claude Code et qui peut, entre autres, approuver un appel d'outil à ta place. La documentation est directe sur ce qu'il peut emporter : « A mod that approves tool calls can approve one that an ask rule would prompt for, or that one of your own PreToolUse hooks blocked [...] including when it can approve a call that a deny rule refuses ». C'est un fonctionnement voulu pour un usage individuel. Sur une machine gérée, Claude Code charge un mod intégré, cc-plugin-sec-default, qui protège ce que l'organisation gère des mods installés par l'utilisateur, et une organisation peut aussi bloquer ces derniers avec allowManagedModsOnly. Le changelog de la 2.1.289 corrige un cas où cette frontière ne tenait pas : sur une machine gérée, une règle deny ou ask posée sur une partie imbriquée d'une commande shell composée, du genre commande1 && commande2, pouvait quand même se faire couvrir par l'approbation d'un mod installé par l'utilisateur. La règle visait précisément ce cas, le mod passait quand même.

Le second correctif touche un risque différent mais voisin, sans règle deny ni ask en jeu : un plugin installé par l'utilisateur pouvait réécrire la description des outils de connexion d'un serveur MCP géré par l'organisation. Ces outils servent à s'authentifier auprès du serveur, et leur description est ce qui indique à Claude à quoi ils servent. Un plugin de l'utilisateur n'avait pas à modifier un outil que l'organisation contrôle. La 2.1.289 l'en empêche.

Trois contournements sur les règles deny et ask elles-mêmes

Le reste du lot touche la mécanique de reconnaissance des règles, pas leur frontière avec les mods. La doc sur les permissions pose le principe pour les symlinks : « Deny rules: apply when either the requested path or the file it resolves to matches », et précise que Claude Code applique les règles deny de Read au dossier vers lequel pointe le chemin qu'on donne à Grep et à Glob. Le changelog de la 2.1.289 étend cette couverture à un chemin d'accès que la doc ne détaillait pas encore : un fichier mentionné avec @, modifié ou sélectionné dans l'IDE échappait aux règles deny de Read quand il passait par un symlien.

Les deux derniers touchent le sandbox. La doc sur le sandbox rappelle ce qui reste vrai même en mode auto-allow : « Explicit deny rules are always respected ». Le problème que corrige la 2.1.289 n'est pas que la règle était ignorée volontairement, c'est qu'en mode auto-allow elle ne reconnaissait pas la commande visée quand celle-ci se cachait derrière un préfixe de variable d'environnement dont la valeur est développée. Un TZ="$HOME" rm -rf build faisait passer le rm -rf sous le radar d'une règle deny ou ask. Le correctif voisin couvre le même angle mort pour une simple affectation de variable placée avant la commande. Dans les deux cas, la règle existait, elle visait la bonne commande, elle ne la reconnaissait pas sous ce déguisement précis.

Le reste, en vrac

• Terminal figé : un bloc de code avec de nombreuses balises <script> non fermées, ou des ${ imbriqués en profondeur, pouvait geler le terminal. Le même défaut touchait les pages d'artifacts publiées, côté navigateur du lecteur.
• claude auth status : un changement de la 2.1.288 avait pu rendre les déconnexions plus fréquentes dans l'extension VS Code, la 2.1.289 l'annule.
• Mods non chargés : un mod installé ne se chargeait pas dans la première session après une mise à jour de Claude Code.
• agent.spawn : nouvelle méthode pour les mods qui gèrent des équipes d'agents, avec un identifiant d'agent unique d'un événement de hook à l'autre et des états « inactif » et « en attente » dans $.agent.list().
• Le reste de la version, surtout des bugs d'affichage et de rechargement pour les auteurs de plugins et de mods, n'intéresse que celles et ceux qui en développent.

Ce qu'il faut retenir

Si tu gères des mods pour une équipe, retiens le premier correctif : une règle deny ou ask posée sur une partie d'une commande composée tient désormais face à un mod installé par l'utilisateur, sur une machine gérée. Pour tout le monde, cette version prolonge un chantier que ce digest a déjà suivi sur plusieurs semaines : fermer, un par un, les endroits précis où une règle de permission existait mais ne reconnaissait pas ce qu'elle devait bloquer. Aucune de ces cinq corrections n'annonce une faille béante, toutes confirment que les règles deny et ask valent la peine d'être écrites avec soin, parce que Claude Code continue d'en traquer les trous.