Claude Code 2.1.259 : MCP géré et permissions plus strictes

Une seule version depuis le dernier digest, la 2.1.259 du 2 septembre. Le changelog officiel dépasse la trentaine d'entrées, mais le fil rouge est net : c'est une version sur les permissions et le MCP géré. À peu près tout ce qui compte dedans touche à qui peut lancer quoi, et pour le compte de qui.

Un nouveau canal pour pousser du MCP à toute une organisation

managedMcpServers est un nouveau réglage géré : une organisation peut désormais fournir des serveurs MCP en HTTP ou SSE à tous ses utilisateurs, avec la même forme d'entrée qu'un fichier .mcp.json de projet. Une restriction structurelle l'accompagne : une entrée qui nomme une commande à exécuter est ignorée. Seuls des serveurs distants passent par ce canal, pas de processus local lancé par une configuration poussée depuis l'extérieur.

Ce mécanisme est distinct du fichier managed-mcp.json déjà documenté, celui qui prend le contrôle exclusif des serveurs MCP d'une machine et bloque toute autre configuration. La doc du contrôle MCP pour les organisations décrit ce fichier et les listes allowedMcpServers / deniedMcpServers qui filtrent ce qui charge. managedMcpServers en est un troisième, plus léger : pousser un ensemble de serveurs sans imposer le contrôle exclusif du fichier. Si tu administres une flotte Claude Code, c'est la première chose à vérifier avant de choisir quel mécanisme utiliser : ils ne se substituent pas les uns aux autres de la même façon.

Deux ajustements aux permissions

--permission-prompts none cible les hôtes headless sans personne pour répondre à une invite. D'après le changelog, tout ce qui aurait normalement déclenché une invite est désormais refusé automatiquement, mais le mode de permission actif, y compris l'auto mode, continue de décider pour le reste. C'est différent du mode dontAsk que documente la page sur l'exécution non interactive, qui refuse tout ce qui ne correspond pas à une règle permissions.allow ou à la liste des commandes en lecture seule. Avec --permission-prompts none, le classificateur de l'auto mode garde la main sur ce qu'il approuve, et seul ce qui aurait posé une question bascule en refus.

Second correctif, plus discret mais plus large : les règles de refus Read() en Bash ne couvraient pas les fichiers passés comme valeur d'option (--ignore-revs-file=.env, -f.env, @fichier), les opérandes de git diff ou git grep, ni les compositions du type cd DIR && cat FICHIER. grep -r ou cp -r sur un répertoire contenant un fichier refusé demandent maintenant confirmation de façon cohérente. La doc des permissions rappelle la limite de ce mécanisme : une règle Read s'applique « aux commandes de fichiers que Claude Code reconnaît en Bash, comme cat, head, tail et sed », pas à un sous-processus arbitraire qui ouvre lui-même un fichier. Le trou comblé ici, ce sont des formes de commandes reconnues qui échappaient encore à la détection, pas le principe du sandbox lui-même : pour un blocage garanti au niveau du système plutôt qu'une règle de refus, c'est toujours le bac à sable qu'il faut activer.

allowedMcpServers change de périmètre à la mise à jour

Celui-ci mérite un arrêt sur image si tu administres des postes. allowedMcpServers ne gouverne désormais que les serveurs qu'un utilisateur ajoute lui-même. Un serveur littéral déclaré dans managed-mcp.json que ton allowlist filtrait jusqu'ici se remet donc à charger après la mise à jour, sans que tu aies touché à ta configuration. Pour le garder bloqué, il faut l'ajouter explicitement à deniedMcpServers, qui fusionne toujours depuis tous les niveaux de réglages d'après la doc du contrôle MCP.

C'est le genre de changement qui ne casse rien de visible : aucune erreur, aucun avertissement, un serveur qui était filtré qui recommence simplement à répondre. Si ton allowlist s'appuyait sur ce comportement pour retirer un serveur précis d'un managed-mcp.json par ailleurs partagé, va vérifier après la mise à jour, avec claude mcp list sur un poste représentatif.

Sessions concurrentes et réglages gérés : deux filets qui se resserrent

Un bug corrigé touche quiconque fait tourner plusieurs sessions Claude Code en parallèle sur la même machine : des sessions concurrentes écrasaient silencieusement les modifications que les autres apportaient à ~/.claude.json, remettant à zéro la confiance accordée à un dossier de travail et perdant l'état MCP ou projet en cours de route. Aucune erreur visible, juste une session qui redemande une confiance déjà donnée, ou qui perd la connexion à un serveur configuré plus tôt dans la même heure.

Dans un registre voisin, la doc confirme un changement de posture sur les réglages gérés eux-mêmes : « si un fichier de réglages gérés ou un fichier complémentaire ne peut pas être lu ou analysé et qu'aucune autre source d'administration ne fournit de politique, les sessions connectées avec des identifiants claude.ai ou Claude Console s'arrêtent au démarrage avec un message invitant à contacter un administrateur », précise la doc des réglages gérés. Avant, un fichier cassé pouvait laisser une politique de sécurité simplement pas appliquée, sans que personne ne le sache. Le mécanisme choisit maintenant d'échouer fermé plutôt qu'ouvert.

Le reste, en vrac

• GitLab : Claude Code reconnaît maintenant glab mr create/merge/close/reopen/note/update, les merge requests s'affichent comme MR !N dans le résumé d'outil et rafraîchissent le badge de pied de page.
• --resume et --continue ne butent plus sur une session sauvegardée contenant une pièce jointe sans contenu : le premier échouait, le second ouvrait une conversation vide.
• Le frontmatter model: d'une commande personnalisée ou d'un skill, ignoré en session interactive, est de nouveau respecté.
• Les sessions isolées en worktree refusaient des boucles Bash courantes, des pipelines xargs et des commandes enveloppées dans un lanceur qui ne peuvent pas atteindre le checkout principal.
• Un serveur MCP qui se déconnecte pendant que ses outils se listent au démarrage remonte désormais l'erreur, au lieu de s'afficher connecté sans aucun outil.
• Stop n'arrêtait pas les agents et les workflows en arrière-plan dans les sessions en contrôle à distance : une tâche tuée reste maintenant visible et re-stoppable jusqu'à la sortie de ses processus.
• Les sessions distantes et planifiées qui restaient sans rien faire après qu'une invite de permission côté connecteur avait été approuvée pendant une pause reprennent maintenant normalement.

Ce qu'il faut en retenir

Si tu es un utilisateur individuel, deux points te concernent vraiment : la faille Bash refermée ne change rien à ce que tu dois faire, et le bug des sessions concurrentes explique peut-être une confiance de dossier qui te semblait se réinitialiser sans raison. Si tu administres une flotte, le vrai travail est ailleurs : va vérifier ce que ton allowedMcpServers laissait passer avant la mise à jour, et ce qu'il laisse passer maintenant, avant qu'un serveur que tu croyais bloqué ne réponde à nouveau.