Claude Code 2.1.290-291 : Chrome, pyright et les permissions resserrées

La 2.1.290 de Claude Code, sortie le 5 octobre 2026, est une version fourre-tout : plus de cent cinquante entrées, pour l'essentiel des correctifs ponctuels sur des surfaces précises : mods et plugins, vue des agents, /ultrareview, passerelle Claude apps, VS Code, Slack. Au milieu, une poignée de changements touchent vraiment l'usage quotidien : Chrome et pyright changent de réflexe par défaut, WebFetch arrête de tronquer les pages en silence, les tâches planifiées survivent mieux à une compaction, et plusieurs angles morts de permissions se referment, dans la continuité des versions précédentes de ce digest. La 2.1.291, sortie le lendemain, n'existe que pour corriger deux régressions, l'une introduite par la 2.1.290 elle-même, l'autre par la 2.1.288. La première touchait justement la fiabilité des réponses aux demandes de permission en session cloud.

Chrome et pyright : deux réflexes qui changent par défaut

Deux changements de la 2.1.290 ne corrigent pas un bug, ils déplacent un défaut. Claude in Chrome partage l'état de connexion de ton navigateur avec Claude, ce qui veut dire un accès à tout site où tu es déjà connecté. Jusqu'ici, un fichier de paramètres de projet pouvait activer cette intégration tout seul. Le changelog est direct : « Changed Claude in Chrome so that a project's settings files can no longer turn it on; use --chrome, /chrome or your user settings ». Un dépôt partagé ou cloné ne peut donc plus décider, à ta place, que Claude a le droit d'ouvrir ton navigateur et d'agir dans tes sessions ouvertes : il faut désormais le flag --chrome, la commande /chrome, ou un réglage posé dans tes propres paramètres utilisateur.

Le second concerne pyright, l'analyseur de types Python. La doc sur les permissions décrit un ensemble intégré de commandes reconnues comme read-only et exécutées sans confirmation dans tous les modes, dont ls, cat, grep et les formes read-only de git, et précise que cet ensemble n'est pas configurable. Jusqu'ici, Claude Code y rangeait aussi pyright et le lançait sans prompt. La 2.1.290 le sort de cette liste : « Changed the Bash tool to ask for permission before running pyright, which is no longer treated as a read-only command ». Si Claude lance pyright pour vérifier son code pendant une session en mode Manuel, attends-toi désormais à une demande de confirmation, à moins d'ajouter une règle allow pour cette commande.

WebFetch arrête de se taire, les tâches planifiées aussi

Deux correctifs de la 2.1.290 partagent le même principe : un échec silencieux devient visible, ou disparaît carrément. Le premier, je l'ai vécu en préparant cet article. La doc sur les outils dit encore aujourd'hui que « Large pages are truncated to a fixed character limit before processing », sans préciser ce qui arrive au texte coupé. En allant chercher le changelog officiel pour ce digest, WebFetch m'a renvoyé une page de près d'un million de caractères : seuls les cent mille premiers étaient lus, avec un avertissement explicite sur ce qui manquait et un paramètre offset pour reprendre la lecture exactement là où elle s'était arrêtée. C'est précisément ce que corrige la 2.1.290 : avant, le texte au-delà de la limite disparaissait sans un mot.

Le second touche /loop à intervalle fixe et les rappels programmés. La doc sur les tâches planifiées explique que ces tâches sont restaurées automatiquement à la reprise d'une session avec --resume ou --continue, tant qu'elles n'ont pas expiré. Le changelog de la 2.1.290 répare un cas où cette promesse ne tenait pas : une tâche planifiée ne revenait pas, en silence, à la reprise d'une conversation déjà compactée (le correctif couvre les compactions faites à partir de cette version), et une tâche récurrente pouvait se déclencher une fois de trop à chaque reprise, respawn ou fork de session. Si tu fais tourner un /loop de longue durée, ce correctif compte directement : une boucle qui s'arrête sans message est le pire genre de panne, celle qu'on ne découvre qu'en constatant le retard accumulé.

Le chantier des permissions continue

Le fil que ce digest suit depuis plusieurs semaines se poursuit dans la 2.1.290 : des garde-fous déjà posés, qu'une forme précise de commande ou de chemin parvenait encore à contourner.

Le premier concerne le mode plan. La doc sur les modes de permission range parmi les actions qu'aucun mode n'approuve automatiquement les outils de connecteur qu'une organisation a mis sur ask : « Connector tools your organization set to ask, in sessions where that setting reaches Claude Code ». Le changelog de la 2.1.290 corrige un cas où le classifieur du mode auto approuvait quand même un outil de connecteur non read-only soumis à cette règle ask poussée par le serveur, pendant qu'il tournait en mode plan. La règle existait côté organisation, elle ne tenait pas dans ce mode précis.

Le deuxième touche les fichiers de règles eux-mêmes. La doc sur les permissions pose le principe pour les liens symboliques : « Deny rules: apply when either the requested path or the file it resolves to matches. A symlink that points to a denied file is itself denied ». La 2.1.290 étend cette couverture à un cas qui échappait encore : un CLAUDE.md de projet, un fichier de règles ou un AGENTS.md qui était en réalité un lien symbolique vers un fichier hors des répertoires de travail se chargeait quand même, sans tenir compte de permissions.blockReadsOutsideWorkingDirectories ni d'une règle deny sur Read.

Une autre série touche la reconnaissance des commandes shell : une règle deny ou ask ratait une commande préfixée par declare, typeset, export ou readonly, ou une commande dont zsh lit les noms de variables autrement que bash, ou des commandes read-only (rg, git grep) dont le shell développait encore les arguments en caractères génériques. La forme courte d'une option de git clone gardait aussi l'exemption de sandbox d'un motif comme git *, et un motif d'URL avec un caractère générique dans un domaine encodé en punycode (xn--) ne correspondait pas de la même façon d'un processus à l'autre. Plus large encore, certaines règles de permission ne s'appliquaient plus à un appel d'outil dont un hook PreToolUse avait réécrit l'entrée. Dans tous les cas, la règle visait la bonne cible, elle ne la reconnaissait pas sous ce déguisement précis.

Le reste, en vrac

• Budget WebSearch : passe d'une limite totale de 200 appels par session à un budget qui se recharge dans le temps, 100 par heure par défaut, réglable avec CLAUDE_CODE_WEB_SEARCH_REFILLS_PER_HOUR.
• claude attach et claude logs : une partie du nom d'une session suffit désormais, plus besoin de l'identifiant complet.
• /teleport : refuse désormais de stasher quand ce stash effacerait les fichiers d'un dossier ayant remplacé un fichier suivi par git du même nom, et dit pourquoi.
• Sessions avec des centaines d'images : ne restent plus bloquées sur une erreur de requête rejetée.
• Filtre de contenu de l'API : une réponse coupée en cours de réflexion par ce filtre est retentée une fois avant d'afficher une erreur.
• Sous-agents et coéquipiers repris : ne perdent plus leur réflexion ni leur cache de prompt après un message reçu en cours d'exécution.
• /rewind : liste désormais un prompt envoyé pendant que Claude travaillait encore.
• 2.1.291 : corrige le lendemain deux régressions de versions récentes, l'une où les sessions cloud pouvaient perdre la réponse donnée à une demande de permission, l'autre où les derniers messages d'une session pouvaient se perdre en quittant.
• VS Code, Claude Tag dans Slack, les sessions cloud et Code Review ont aussi leur lot dans la 2.1.290 : surtout des correctifs d'affichage et de fiabilité propres à ces surfaces.

Ce qu'il faut retenir

Si tu actives Claude in Chrome depuis un fichier de paramètres de projet, ça ne fonctionne plus : passe par --chrome, /chrome, ou tes paramètres utilisateur. Si Claude lance pyright dans tes sessions, prévois la demande de confirmation qui arrive désormais avec, ou une règle allow. Si tu dépends d'un /loop ou d'un rappel programmé sur une session longue, cette version corrige justement le genre de panne silencieuse qui ne se voit qu'au retard accumulé. Pour le reste, la 2.1.290 prolonge un chantier déjà engagé plutôt qu'elle n'en ouvre un nouveau : fermer, un par un, les endroits précis où une règle de permission existait sur le papier sans tenir en pratique. Aucun de ces correctifs n'est spectaculaire pris seul, c'est la série qui compte.