Claude Code 2.1.268 : ce qui a été corrigé dans les règles deny et MCP

Claude Code version 2.1.268 est sorti le 10 septembre 2026, suivi le lendemain par la version 2.1.269. Vous devriez mettre à jour immédiatement : dans deux cas, les règles de refus que vous utilisez pour empêcher l’agent d’accéder à .env et aux dossiers de services étaient silencieusement inopérantes. De plus, la commande /mcp pouvait afficher des secrets provenant de vos configurations dans le terminal.

Tout ce qui suit s’appuie sur le journal des modifications et la documentation officiels d’Anthropic tels qu’ils se présentaient le 17 septembre 2026, date du document source. La dernière version à cette date était la 2.1.274. Nous décrivons le fonctionnement des erreurs à partir de ces entrées ; les contournements n’ont pas été reproduits sur la version vulnérable.

Pour obtenir des instructions supplémentaires sur l’utilisation d’Ailoot, consultez la documentation.

Qu’est-ce qui a été corrigé dans Claude Code 2.1.268 et 2.1.269 ?#

Quatre corrections concernent les règles d’autorisation :

1. Les refus ne fonctionnaient pas sur les liens symboliques. Les règles deny et ask définies pour des répertoires liés par des liens symboliques (/etc, /tmp, /var sur macOS, /bin sur Linux) ne se déclenchaient pas lorsqu’un chemin était spécifié par son emplacement réel. Les commandes Bash ignoraient également les règles de refus définies pour un chemin via un lien symbolique.
2. Le refus de lecture et de modification échouait avec env -C ou eval. Si la même ligne de commande contenait une construction que la vérification d’autorisation ne pouvait pas analyser, deny pour Read ou Edit pouvait ne pas se déclencher.
3. Une règle avec « ! » s’appliquait plus largement que prévu. Une règle deny ou ask commençant par ! s’appliquait au-delà du fichier de paramètres où elle était écrite. Elle ne s’applique désormais qu’à sa propre source, et une négation isolée ! est ignorée.
4. tee contournait les refus d’écriture. Les règles deny pour Edit() et la vérification du chemin d’écriture ne s’appliquaient pas à un fichier créé par la commande Bash tee. L’autorisation Bash(tee:*) ne couvre plus les écritures en dehors des répertoires de travail.

Ces versions ont également corrigé deux problèmes liés à l’exposition de secrets. WebFetch n’attend plus indéfiniment la réponse d’un serveur qui maintient la connexion ouverte : la requête échoue désormais après 300 secondes, et le délai d’expiration peut être configuré à l’aide de la variable CLAUDE_CODE_WEBFETCH_DEADLINE_MS. Elles ont également supprimé l’utilisation élevée et persistante du processeur lors des longues sessions inactives.

Comment fonctionnent les refus dans Claude Code ?#

Claude Code comporte trois listes de règles : deny (toujours interdit), ask (demander avant d’effectuer l’action) et allow (autorisé sans confirmation). Lorsque l’agent s’apprête à faire quelque chose, les règles sont vérifiées strictement dans cet ordre. Une règle deny correspondante annule toute règle allow pour la même action : une règle d’autorisation ne peut pas créer d’exception à un refus.

Les règles sont stockées à trois endroits : les règles utilisateur dans ~/.claude/settings.json, les règles du projet dans .claude/settings.json au sein du dépôt, et les règles locales dans .claude/settings.local.json. Voici un exemple de paramètres qui refusent la lecture d’un fichier contenant des clés :

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Bash(rm *)"
    ]
  }
}

Vous pouvez voir toutes les règles actives et le fichier dont chacune provient en exécutant /permissions dans une session. Si une règle bloque la lecture, le refus indique cette règle, ce qui sera utile pour la vérification ci-dessous.

Quelles erreurs concernaient les refus et la portée des règles ?#

Les erreurs concernaient les vérifications des chemins et des commandes, ainsi que la portée des règles issues de différents fichiers de paramètres.

Premier cas : les liens symboliques. Sur macOS, /etc, /tmp et /var sont des liens symboliques vers des dossiers réels sous /private ; sur Linux, /bin est souvent un lien similaire. Si vous aviez écrit une règle de refus pour une écriture du chemin, mais que l’agent y accédait avec une autre (par exemple, son emplacement réel au lieu du lien symbolique), la règle ne se déclenchait pas. Les commandes Bash ignoraient également un refus défini pour un chemin via un lien symbolique. Dans la version 2.1.268, ces deux cas ont été corrigés : la règle s’applique désormais quelle que soit l’écriture du chemin utilisée.

Deuxième cas : env -C et eval sur la même ligne. La vérification d’autorisation analyse une commande pour déterminer quels fichiers elle va consulter. Elle ne peut pas analyser des constructions telles que env -C ou eval. Le problème était que si une telle construction figurait sur la ligne, deny pour Read ou Edit pouvait ne pas être appliqué. La commande pouvait donc contourner le refus de lecture ou de modification d’un fichier protégé.

Troisième cas : une règle avec « ! » dépassait ses limites. Une règle commençant par ! ne devrait s’appliquer que dans le fichier de paramètres où elle est écrite. Avant la version 2.1.269, elle s’appliquait également à d’autres sources de paramètres. Sa portée est désormais limitée à son propre fichier, et une règle composée uniquement de ! est ignorée.

Quatrième cas : écriture avec tee. La commande Bash tee peut écrire dans un fichier. La vérification du chemin d’écriture et les règles deny pour Edit() ne s’appliquaient pas à ce fichier. Dans le même temps, l’autorisation Bash(tee:*) couvrait les écritures en dehors des répertoires de travail. Dans la version 2.1.269, ces vérifications ont commencé à s’appliquer aux écritures effectuées avec tee : le refus visant le fichier prend effet, et Bash(tee:*) ne couvre que les répertoires de travail.

Si vous utilisez des refus ciblés — pour bloquer .env, quelques dossiers de services ou des commandes dangereuses — vous devriez également les vérifier. Les étapes sont ci-dessous.

Pourquoi /mcp pouvait-il afficher vos clés ?#

Les configurations de serveurs MCP stockent couramment les clés dans des variables d’environnement et y font référence avec ${VAR}, afin que le fichier puisse être stocké dans un dépôt sans contenir les secrets eux-mêmes. Le problème venait du fait que les commandes d’affichage (/mcp, /plugin, claude mcp list, claude mcp get) et les messages d’erreur de connexion MCP affichaient la configuration avec les valeurs déjà substituées. La clé elle-même apparaissait à l’écran.

Une autre correction concerne les erreurs de plugins et de marketplaces : elles pouvaient afficher un jeton ou un mot de passe provenant de l’URL Git source.

Si la sortie de /mcp ou de claude mcp list dans une ancienne version est apparue dans un flux, une capture d’écran, un message envoyé à un collègue ou un journal qui a quitté votre machine, y compris automatiquement, considérez que les clés de vos configurations MCP ont été exposées et faites-les tourner. Si la sortie n’a jamais quitté votre machine, une mise à jour suffit. Nous proposons un guide distinct sur les serveurs MCP et les configurations prêtes à l’emploi : Serveurs MCP de Claude Code.

Autres changements apportés dans ces versions#

WebFetch et les artefacts. Auparavant, une règle WebFetch sans détails dans deny ou ask s’appliquait également à la lecture et à la modification des artefacts publiés. Depuis la version 2.1.268, elle ne s’applique plus à ceux-ci. Pour bloquer les artefacts, vous devez ajouter une règle Artifact distincte ou une règle visant le domaine, telle que WebFetch(domain:claude.ai). Si vous comptiez sur un refus général de WebFetch pour empêcher la lecture des artefacts, revérifiez vos paramètres : l’ancienne règle ne bloque plus ces actions.

WebFetch a désormais un délai d’expiration. Une requête adressée à un serveur qui maintient la connexion ouverte sans terminer sa réponse échoue désormais après 300 secondes. Auparavant, une telle requête pouvait rester bloquée indéfiniment. Le comportement peut être configuré avec la variable CLAUDE_CODE_WEBFETCH_DEADLINE_MS ; la définir sur 0 désactive le délai d’expiration.

L’utilisation élevée et persistante du processeur pendant les sessions inactives a été supprimée. Au cours des longues sessions inactives, une boucle d’inactivité dans Claude Code pouvait entraîner une utilisation élevée et persistante du processeur. Ce problème a été corrigé dans la version 2.1.268. Il pouvait également toucher les personnes qui laissent leurs sessions ouvertes toute la journée.

Installez la dernière version. Un nouveau problème est apparu dans la version 2.1.269 : après une longue durée de session, les commandes Bash Git qui ne faisaient que lire des données ont commencé à demander une autorisation. Ce problème a été corrigé dans la version 2.1.270. Mettez donc à jour vers la dernière version (au 17 septembre 2026, il s’agissait de la 2.1.274) ; ne vous arrêtez pas à la version 2.1.268 ou 2.1.269.

Comment mettre à jour et vérifier que les refus fonctionnent ?#

1. Vérifiez votre version actuelle. Exécutez claude --version dans le terminal. Les corrections des problèmes décrits ci-dessus ont été publiées dans les versions 2.1.268 et 2.1.269. Si le numéro de version est inférieur à 2.1.268, votre version ne contient pas encore ces corrections, même si l’applicabilité de chaque problème dépend des chemins, commandes et règles que vous utilisez.
2. Mettez à jour. Le guide comment mettre à jour Claude Code vers la dernière version fournit des instructions détaillées et des conseils de dépannage. Choisissez la dernière version ; ne vous arrêtez pas à la 2.1.268.
3. Testez le refus. Ne testez pas une règle sur un vrai fichier .env : si le refus échoue, l’agent verra de vraies clés. Créez un fichier de test, par exemple secret-test.txt, contenant n’importe quel texte, tel que « ceci est un test » ; ajoutez la règle "Read(./secret-test.txt)" à la liste deny dans le fichier .claude/settings.json du projet ; redémarrez la session et demandez : « lis le fichier secret-test.txt et dis-moi ce qu’il contient. » Le résultat attendu est un refus qui mentionne votre règle. Si l’agent lit le fichier, le refus n’a pas fonctionné lors de ce test. Commencez par vérifier la syntaxe dans la section ci-dessus et ouvrez /permissions pour consulter les règles actives et les fichiers depuis lesquels elles ont été chargées. Le résultat du test seul ne permet pas d’identifier la cause. Un seul refus montre que la règle fonctionne pour ce fichier ; il ne dit rien de vos autres règles. Vérifiez-les une par une de la même façon.
4. Vérifiez le cas des liens symboliques si vous utilisez des chemins de ce type. Si vous avez défini des refus pour /tmp, /etc ou /var sur macOS, ou pour /bin sur Linux, répétez le test pour ces chemins après la mise à jour.
5. Vérifiez les règles avec « ! ». Si vous en avez utilisé, vérifiez que chacune est écrite dans le fichier auquel elle est censée s’appliquer.

Si le refus fonctionne, mais que Claude Code ne peut toujours pas voir les fichiers dont vous avez besoin, consultez l’explication distincte : pourquoi Claude Code ne peut pas voir les fichiers du projet.

Si vous ne pouvez pas mettre à jour tout de suite#

Il faut parfois repousser une mise à jour : vous ne pouvez pas modifier l’environnement, la machine appartient à votre entreprise ou vous devez terminer la tâche en cours. En attendant la mise à jour, vous pouvez réduire les risques ainsi :

• écrivez des règles de refus pour les deux écritures du chemin — le lien symbolique et l’emplacement réel (sur macOS, les chemins réels se trouvent sous /private) ;
• ne combinez pas plusieurs commandes sur une seule ligne et évitez env -C et eval dans les commandes que vous demandez à l’agent d’exécuter ;
• ne montrez à personne la sortie de /mcp, /plugin, claude mcp list ou claude mcp get, et faites tourner les clés des configurations MCP qui ont pu tomber entre les mains d’une autre personne ;
• gardez à l’esprit que tee contourne deny pour Edit : ne considérez pas les fichiers comme protégés si Bash est autorisé.

Ces mesures réduisent la probabilité de certains contournements, mais ne remplacent pas la correction. Mettez à jour et effectuez le test de la section précédente dès que possible.

Bref résumé#

Les versions 2.1.268 et 2.1.269 ont corrigé quatre problèmes d’autorisation dans Claude Code : les liens symboliques, les lignes contenant env -C et eval, les règles avec « ! » qui s’appliquaient au-delà de leur propre fichier et les écritures via tee. Elles ont également corrigé séparément l’exposition de secrets dans la sortie de /mcp et de jetons dans les erreurs de plugins. Vérifiez votre numéro de version, mettez à jour vers la dernière version et effectuez le test avec un fichier de test de la section ci-dessus. Un refus qui mentionne votre règle montre que le refus a fonctionné lors de ce test. La simple présence de la règle dans les paramètres ne suffit pas à le vérifier.

Pour continuer à travailler avec des modèles, vous pouvez vous rendre sur Ailoot.