Claude Code 2.1.274 : quatre angles morts de permissions refermés d'un coup

La 2.1.274 de Claude Code, sortie le 17 septembre 2026, referme quatre trous distincts côté permissions et sécurité : deux de plus dans le vérificateur de commandes Bash, un dans l'aperçu d'approbation de l'outil Edit, et un dans la gestion des secrets pour les serveurs MCP. Le reste de la centaine d'entrées tient dans des correctifs de fiabilité MCP et de sessions en tâche de fond, plus une trentaine de bugs d'interface répartis entre VS Code, Claude Code sur le web, Claude Tag et Code Review. Voici ce qui compte.

Bash : deux angles morts de plus dans le vérificateur de permissions

La 2.1.274 poursuit une série entamée dans les versions précédentes, où quatre angles morts avaient déjà été refermés le 14 septembre et deux de plus le lendemain. La doc sur les permissions explique pourquoi ces cas limites reviennent aussi souvent : le vérificateur doit lire une commande Bash telle quelle et décider si elle a besoin d'une confirmation, avant même de l'exécuter. La doc sur les modes de permission le formule directement : « A command the shell parser can't trace, such as one that changes directory more than once or runs a subshell, prompts the same way even when it names no outside path ». Chaque construction shell un peu inhabituelle est un cas de plus à couvrir explicitement.

Cette fois, deux constructions précises passaient au travers. D'un côté, les commandes qui bouclent sur certaines variables spéciales du shell, ou qui leur affectent une valeur, ne déclenchaient pas d'invite de permission ; elles la déclenchent désormais. De l'autre, une session isolée dans son propre worktree, celle que Claude Code utilise pour cantonner les modifications d'un agent à son propre espace de travail git, pouvait accepter une commande Bash contenant certaines expansions shell imbriquées ; ces commandes sont maintenant refusées.

Les deux correctifs ne visent pas le même public : le premier vaut pour toute session qui compte sur l'invite de permission Bash, le second seulement pour les sessions isolées en worktree. Dans les deux cas, c'est exactement le genre de commande qui pouvait sortir du périmètre que tu pensais avoir fermé.

Edit : l'aperçu d'approbation pouvait montrer un autre emplacement que l'édition réelle

Le tableau des permissions rappelle qu'en mode Manual, les éditions de fichiers demandent une confirmation, justement pour que tu voies ce que tu approuves avant que ça s'applique. La 2.1.274 corrige un cas où cette promesse ne tenait pas : dans les fichiers contenant des caractères multi-octets, l'aperçu affiché dans l'invite de permission de l'outil Edit pouvait pointer vers un emplacement différent de celui où l'édition atterrissait réellement une fois approuvée.

C'est le genre de bug qui ne casse rien de visible tant que tu ne compares pas l'aperçu au résultat, mais qui mine la seule protection que le mode Manual t'offre sur ce point : lire avant d'accepter. En acceptEdits, il n'y a de toute façon pas d'invite à lire pour un fichier du périmètre de travail. Et la condition de déclenchement n'a rien d'exotique en français : des accents dans le fichier suffisent à en faire un fichier multi-octets. Si tu approuves des éditions à la volée sur la confiance de l'aperçu, cette version restaure ce que tu croyais déjà vrai.

MCP : une erreur de connexion ne doit pas afficher tes secrets

La doc sur MCP documente l'expansion ${VAR} dans la configuration d'un serveur, pour l'URL, les en-têtes, les arguments ou les variables d'environnement passées au serveur. Il précise aussi une protection déjà en place pour les identifiants sensibles : « In a remote server's url and headers, Claude Code reads credential variables from your environment as empty rather than expanding them. This keeps a project's .mcp.json or a plugin from sending your Claude Code or cloud provider credentials to a server it names ».

Le bug corrigé dans la 2.1.274 touchait deux autres chemins : quand une connexion à un serveur MCP échouait, le message d'erreur affiché pouvait montrer la valeur réellement résolue d'un placeholder ${VAR}, secret compris, au lieu de la masquer. La description de l'outil de connexion MCP faisait la même chose. Cette protection à l'expansion reste valable pour les identifiants Claude et cloud reconnus, mais un secret placé dans une variable d'environnement personnalisée, une clé d'API pour un serveur tiers par exemple, pouvait se retrouver en clair dans un message d'erreur, donc potentiellement dans un journal ou une capture d'écran de session. Si tu configures des serveurs MCP distants avec des en-têtes d'authentification personnalisés, vérifie que cette version est bien celle que tu utilises.

Le reste, en vrac

Un avertissement visible apparaît quand l'utilisation de la mémoire devient critique, avec les étapes pour en libérer ou redémarrer proprement.
Les serveurs MCP en http qui ne parlent que l'ancien protocole HTTP+SSE se connectent à nouveau quand ils répondent 422 ou une autre erreur 4xx à la première requête, et les appels d'outils en Streamable HTTP ne s'arrêtent plus après environ 5 minutes malgré un timeout plus long configuré pour le serveur.
Les sessions qui restaient bloquées à relancer sans fin après une erreur 400 « unexpected tool_use_id » se terminent correctement.
Les sessions pilotées par un hook, un /goal actif par exemple, ne se terminent plus sur « Prompt is too long » : elles compactent la conversation comme prévu au lieu d'échouer.
claude agents ne perd plus --model, --effort, --permission-mode et les autres options après une mise à jour automatique.
Le premier tour d'une session cloud ne démarre plus, parfois, sans les outils d'un serveur MCP hébergé par le SDK et encore en cours de connexion.
Les sessions headless et SDK ne déclenchent plus un appel modèle séparé pour chaque tâche de fond terminée, ce qui gonflait leur coût sans raison.
Les entrées MCP "type": "sdk" dans .mcp.json, les settings, les plugins et les fichiers d'agent sont désormais ignorées avec un avertissement : seule une application hôte SDK peut enregistrer un serveur in-process.
Les installations Bedrock, Vertex, Foundry et celles dont la télémétrie est désactivée passent par défaut au client MCP v2 et à la négociation MCP 2026-07-28 avec les serveurs HTTP directs, comme le faisaient déjà les autres installations. Pour revenir en arrière : MCP_SDK_GENERATION=v1 ou MCP_PROTOCOL_NEGOTIATION=legacy.

Ce qu'il faut retenir

Si tu ne retiens qu'une chose de cette version, c'est que la sécurité et les permissions restent le chantier le plus actif de Claude Code, version après version : deux angles morts Bash de plus, un aperçu d'édition qui pouvait mentir sur ce qu'il approuvait, et un vrai risque de fuite de secret dans une erreur MCP. Trois de ces quatre bugs n'exigeaient rien d'exotique pour te toucher : des accents dans un fichier source suffisaient pour l'aperçu d'édition, un en-tête d'authentification personnalisé pour la fuite MCP. Seul le cas des expansions imbriquées suppose un mode de travail précis, la session isolée en worktree. Le reste, fiabilité MCP et coût des sessions en tâche de fond, améliore le quotidien sans rien changer à ta façon de travailler.