Claude Code 2.1.265-266 : la faille des plugins colmatée, Windows débloqué

Deux versions coup sur coup le 8 septembre 2026 : la 2.1.265, puis la 2.1.266 dans la foulée pour corriger une régression que la première venait d'introduire. Le fil rouge de cette double sortie n'est pas une nouvelle fonctionnalité, c'est du durcissement : une faille de sécurité colmatée dans le chargement des plugins, un sandbox Windows qui bloquait tout usage de Claude Code, et un correctif publié le jour même sur l'authentification via passerelle LLM.

Un antislash dans un chemin de plugin contournait le contrôle de sécurité

Claude Code vérifie, au chargement d'un plugin, que ses liens symboliques restent contenus dans le dossier du plugin : un plugin ne doit pas pouvoir pointer, via un lien symbolique, vers un fichier situé ailleurs sur ta machine. La 2.1.265 ferme une voie de contournement de ce contrôle sur macOS et Linux, quand le chemin du plugin contenait un antislash. L'antislash n'est pas un séparateur de chemin sur ces systèmes, mais le contrôle le traitait apparemment comme tel, ce qui laissait passer un chemin que la résolution réelle du système de fichiers interprétait autrement.

La doc sur l'installation de plugins est directe sur ce que représente un plugin : « les plugins et les marketplaces sont des composants de très haute confiance, capables d'exécuter du code arbitraire sur ta machine avec tes propres droits utilisateur ». Le contrôle de confinement des liens symboliques est justement ce qui borne cette confiance une fois un plugin chargé. Le contourner ne donnait pas un accès qu'un plugin malveillant n'avait pas déjà en théorie, mais retirait une des barrières censées limiter les dégâts d'un plugin mal intentionné ou compromis. Si tu développes ou distribues des plugins, aucune action à mener : le correctif est transparent, mais il vaut la peine de savoir qu'il existait.

Windows : le sandbox ne bloquait plus un fichier, il les bloquait tous

Sur Windows, quand Claude Code tournait à l'intérieur d'un AppContainer ou d'un jeton restreint (les mécanismes que des politiques d'entreprise ou des outils de sandboxing tiers imposent au processus), Read, Write et Edit refusaient purement et simplement chaque fichier, avec le message « symlink resolution changed after permission was checked ». Concrètement, les outils ne pouvaient plus rien lire ni écrire dans ce contexte, ce qui rendait Claude Code inutilisable pour quiconque travaillait dans un environnement Windows verrouillé de cette façon. La 2.1.265 corrige le bug.

Ce n'est pas le sandbox intégré de Claude Code lui-même, celui que tu actives avec /sandbox : cette fonctionnalité n'est toujours pas prise en charge nativement sous Windows, où la recommandation reste de passer par WSL2. Le bug touchait des sandbox imposés en dehors de Claude Code, par le système d'exploitation ou par une politique de poste de travail. Si tu déploies Claude Code sur des postes Windows gérés avec ce type de restriction, la mise à jour vaut la peine d'être poussée en priorité.

Un correctif publié le jour même sur les passerelles LLM

La 2.1.265 avait aussi introduit, sans le vouloir, une régression sur les configurations passant par une passerelle LLM (proxy d'entreprise vers Anthropic ou un autre fournisseur). La variable d'environnement CLAUDE_CODE_USE_GATEWAY, non documentée et jusque-là ignorée sauf si ANTHROPIC_BASE_URL et ANTHROPIC_AUTH_TOKEN étaient tous les deux définis, s'est mise à forcer d'elle-même la connexion à la passerelle Cloud. Toute configuration qui la définissait à côté d'une clé API, d'un apiKeyHelper ou d'en-têtes d'authentification personnalisés voyait alors chaque requête échouer avec « Not signed in to the Cloud gateway ».

La doc sur la connexion à une passerelle LLM détaille comment une organisation distribue une URL de passerelle et un identifiant, via les réglages gérés, la gestion de parc ou un apiKeyHelper, et précise que cet identifiant prend le pas sur un login claude.ai enregistré, qui reste alors en place mais inutilisé. C'est ce mécanisme que la régression court-circuitait : la variable imposait une connexion à la passerelle Cloud avant même que l'identifiant configuré puisse servir, au lieu de rester sans effet par défaut. La 2.1.266, sortie le jour même, restaure le comportement d'origine, sans rien à reconfigurer de ton côté. Si tu gères une flotte avec cette variable dans l'environnement, vérifie simplement que tu tournes bien sur la 2.1.266 ou plus récent.

Le reste, en vrac

--plugin-dir accepte maintenant un dossier contenant plusieurs plugins : chaque sous-dossier avec un manifeste se charge, et un ajout ou un retrait pendant que Claude Code tourne est détecté.
Les résultats d'outils enregistrés sur disque sont désormais plafonnés à 1 Go, avec un avertissement dans l'aperçu quand un fichier a été tronqué pour cette raison.
La réutilisation du cache de prompt repartait de zéro dans deux cas : la reprise d'un sous-agent lancé au premier plan, qui changeait sa liste d'outils et son préfixe de prompt système, et les coéquipiers d'agent comme les sous-agents repris, dont le contexte du hook SubagentStart et les skills préchargés sortaient du préfixe aux tours suivants. Les deux sont corrigés.
Les serveurs MCP configurés en transport http qui ne parlent en réalité que l'ancien transport SSE restaient bloqués sans jamais se connecter : Claude Code retombe maintenant sur SSE, comme le prévoit la spécification MCP, sans reconfiguration nécessaire de ton côté.
Un cd dans une session non interactive (-p avec entrée stream-json, Agent SDK, sessions cloud) persiste maintenant d'un tour à l'autre, au lieu d'être réinitialisé à chaque nouveau message.
VS Code archive désormais automatiquement les sessions inactives depuis un certain délai, réglé à quatorze jours par défaut, avec un nouveau réglage pour changer ce délai.
Reprendre une session interrompue pendant qu'un outil tournait ne réécrit plus le dernier message : l'appel d'outil interrompu est conservé et marqué comme tel, au lieu d'être perdu.
La lecture d'un artifact publié par quelqu'un d'autre traite maintenant son contenu comme non fiable et signale les instructions qui y seraient dissimulées, au lieu de les relayer telles quelles.
Un serveur MCP distant demandant une connexion ne se voit plus enregistrer de client OAuth tant que tu ne t'es pas réellement authentifié auprès de lui.
Les machines dont les réglages gérés définissent forceLoginGatewayUrl démarrent maintenant directement en session passerelle Claude apps, comme avec forceLoginMethod: "gateway" : un login claude.ai ou une clé API restés en place ne sont plus utilisés.
La télémétrie que Claude Desktop et Cowork envoient à travers une passerelle Claude apps inclut maintenant user.email et user.groups, comme le faisaient déjà les sessions terminal.

Ce qu'il faut retenir

Rien ici ne change tes réflexes du quotidien si tu utilises Claude Code en solo avec un compte claude.ai classique. Les deux versions ciblent des publics précis : les auteurs et utilisateurs de plugins pour le contournement du contrôle de sécurité, les équipes qui déploient Claude Code sur des postes Windows verrouillés pour le sandbox, et les administrateurs de passerelle LLM pour le correctif du jour même. Dans les trois cas, la seule action utile est de vérifier que tu tournes sur la 2.1.266, la régression ayant été introduite et corrigée en l'espace d'une journée.