Claude Code 2.1.267 : deux verrous de sécurité refermés, le cache stabilisé
Un chemin de marketplace et des réglages hooks/plugins géraient mal leurs cas d'erreur, corrigés dans la 2.1.267, aux côtés d'une dizaine de correctifs sur le cache de prompt en reprise de session.
La 2.1.267 de Claude Code est sortie le 9 septembre 2026, le lendemain de la double sortie 2.1.265-266 couverte dans le digest précédent. Le fil rouge n'est pas neuf : encore de la sécurité colmatée, avec deux contrôles qui laissaient passer ce qu'ils étaient censés bloquer, et un chantier plus discret sur la fiabilité du cache de prompt quand une session reprend après une pause, un changement de modèle ou une reconnexion MCP.
Un chemin de marketplace avec antislash rejouait le même bug
La 2.1.265 avait déjà fermé un contournement du contrôle de confinement des liens symboliques dans le chargement des plugins, sur macOS et Linux, quand le chemin contenait un antislash. La 2.1.267 corrige la même famille de bug, mais un cran plus haut dans le processus : cette fois, c'est le chemin déclaré par une entrée de marketplace elle-même, avant même l'installation d'un plugin, qui pouvait contourner le contrôle de confinement sur ces deux systèmes grâce à un antislash.
La doc sur les marketplaces de plugins est claire sur ce que ce contrôle protège : un chemin qui se résout hors du dossier du plugin, du type ./../shared.md, est rejeté, et Claude Code copie les plugins installés dans un emplacement de cache pour qu'ils ne puissent justement pas référencer des fichiers extérieurs à leur dossier. L'antislash n'est pas un séparateur de chemin sur macOS ni sur Linux, mais la vérification 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. Deux versions, deux points d'entrée différents, la même faille de raisonnement sur les caractères de chemin : si tu distribues des marketplaces ou des plugins, aucune action à mener, le correctif est transparent, mais la récurrence vaut la peine d'être connue.
Des réglages qui autorisaient tout quand ils devenaient illisibles
Trois réglages gérés encadrent ce que les hooks et les canaux d'une organisation ont le droit de faire : allowedHttpHookUrls limite les URL que peuvent contacter les hooks HTTP, httpHookAllowedEnvVars limite les variables d'environnement interpolables dans leurs en-têtes, et allowedChannelPlugins limite les plugins autorisés à s'enregistrer comme canal, donc à pousser des messages dans une session ouverte. La doc sur les hooks précise que les deux premiers fonctionnent en liste blanche : une fois définis, seul ce qu'ils listent explicitement passe. Le troisième remplace la liste d'Anthropic par celle de l'organisation, sur le même principe.
Le bug corrigé par la 2.1.267 touchait le cas où le fichier de réglages gérés portant ces valeurs devenait illisible, JSON malformé ou erreur de lecture. Claude Code retombait alors sur un comportement permissif, comme si le réglage n'avait jamais été défini, au lieu de bloquer par défaut. Pour une organisation qui compte sur ces listes blanches pour empêcher un hook d'exfiltrer une variable sensible vers une URL non approuvée, une erreur de configuration qui ouvre grand la porte plutôt que de la refermer est le pire des deux scénarios. La correction fait désormais échouer fermé dans les trois cas : un réglage illisible n'autorise plus rien.
Le cache de prompt, l'autre chantier de cette version
Une dizaine de correctifs de la 2.1.267 visent tous la même mécanique : garder le cache de prompt intact, en reprise de session comme en cours de route, plutôt que de tout recalculer sans raison. La doc sur le cache de prompt rappelle le principe : un changement n'importe où dans le préfixe d'une requête, système, outils ou historique, invalide tout ce qui suit, et rebâtir ce préfixe coûte un tour plus lent et plus cher.
Parmi les cas corrigés : reprendre une session après /compact ou une commande slash via -p --resume n'insère plus un tour fantôme « Continue from where you left off » ; reprendre une session dont la conversation enregistrée dépasse 5 Mo ne perd plus les appels d'outils parallèles ni la sortie des hooks associés ; un outil qui disparaît en cours de session, serveur MCP déconnecté ou mise à jour, ne réécrit plus toute la liste d'outils en perdant le raisonnement déjà produit ; et changer de modèle avec /model ne renvoie plus la définition de chaque outil, le texte d'attribution des commits et PR arrivant désormais comme une note de conversation mise à jour à chaque changement de modèle. Rien de tout ça ne change une commande ou un réflexe : c'est de la reprise de session qui redevient aussi rapide et aussi peu coûteuse qu'elle devrait l'être, surtout utile si tu enchaînes de longues sessions reprises d'un jour sur l'autre.
Un plafond d'effort pour les organisations
Nouveau réglage maxEffortLevel, définissable au niveau global ou par modèle sous modelSettings, qui plafonne le niveau d'effort disponible sur un modèle, sur tous les fournisseurs, Bedrock, Vertex et Foundry compris. Les utilisateurs restent libres de choisir un niveau plus bas ; c'est un plafond, pas une valeur imposée. Le cas d'usage est le même que pour les autres contrôles de coûts déjà disponibles : une organisation qui veut éviter qu'un niveau d'effort maximal fasse grimper la facture d'une équipe entière sans y avoir consenti. En parallèle, --system-prompt-snapshot off force le rendu du prompt système à chaque requête plutôt que de réutiliser celui enregistré au démarrage, utile si tu itères sur un prompt système personnalisé et veux voir chaque changement pris en compte immédiatement.
Le reste, en vrac
- Cowork : les tâches planifiées dans le cloud ne plantent plus au démarrage pour les organisations dont les réglages gérés imposent le sandboxing.
- Mobile :
/contextet les autres sorties de commandes locales ne s'affichent plus vides sur les clients mobiles. - Terminal : shift+entrée et option+retour arrière fonctionnent de nouveau après une reconnexion à une session tmux ou ssh dans une vue d'agent.
- Remote Control :
claude remote-controlne s'arrête plus en lâchant toutes les sessions attachées quand son identifiant de serveur expire, environ trente jours après le démarrage ; l'hôte se ré-enregistre et continue. - Identifiants AWS ou Google Cloud expirés sous une appli hôte type Claude Desktop : l'erreur de ré-authentification s'affiche directement, au lieu de dix tentatives génériques.
- Claude Code sur le web : les sessions GitHub Enterprise Server n'affichent plus le compte GitHub comme déconnecté quand son jeton expire, et les appels
ghfonctionnent dans les organisations sans la GitHub App Claude, via le compte GitHub connecté. - VS Code : huit correctifs, dont un blocage CPU à 100 % lié à un lien parent cyclique dans une conversation, le collage d'une capture d'écran cassé sous WSL2, et les diffs qui suivaient toujours un thème sombre au lieu du thème actif de l'éditeur.
- Claude Tag : un lien pour basculer vers un connecteur personnalisé sans repartir de zéro, et un message d'erreur plus clair quand l'organisation a épuisé ses crédits d'usage.
Ce qu'il faut retenir
Si tu es en solo avec un compte claude.ai classique, rien ici à changer dans tes habitudes : le correctif de marketplace concerne les auteurs et distributeurs de plugins, celui sur les listes blanches les organisations qui déploient des réglages gérés, maxEffortLevel vise les mêmes organisations côté coûts d'équipe, et le lot de correctifs sur le cache de prompt joue simplement en ta faveur, sans rien à configurer. Le point commun avec la version précédente reste net : deux versions de suite, c'est le même contrôle de confinement des chemins de plugins qu'il a fallu recolmater.
Pierre Rondeau
Développeur et indie builder. Je construis des produits et automatisations avec l'IA. Créateur de Claude Hub.
LinkedIn