Claude Code 2.1.268 : secrets qui fuitaient, permissions colmatées, endpoints réparés

La 2.1.268 de Claude Code est sortie le 10 septembre 2026, le lendemain de la 2.1.267 couverte dans le digest précédent. Le fil rouge est encore la sécurité, mais sur un registre différent : deux façons de contourner un contrôle de permission, deux fuites de secrets dans des messages d'erreur, et un hook de permission qui ne se déclenchait pas en mode automatisé. À côté de ça, une régression qui coupait Claude Code net pour quiconque passe par un endpoint tiers, et une perte de fichiers silencieuse en session cloud longue.

Deux façons de contourner un refus, et deux secrets qui fuitaient

Sur macOS, /etc, /tmp et /var sont eux-mêmes des liens symboliques vers leur emplacement réel, pareil pour /bin sur certaines distributions Linux. Une règle deny ou ask écrite sur ces chemins ne s'appliquait pas quand le chemin donné pointait directement vers l'emplacement réel plutôt que vers le lien. C'est l'inverse de ce que documente la doc sur les permissions : une règle deny s'applique dès que le chemin du lien symbolique ou sa cible correspond, l'un ou l'autre suffit. Le bug laissait passer exactement le cas que cette règle est censée couvrir.

Deuxième contournement, sur Read et Edit cette fois : une règle deny ne s'appliquait pas quand la commande contenait env -C, eval ou une construction similaire que le vérificateur de permissions ne sait pas analyser sur la même ligne que l'accès réel au fichier. Habiller un accès refusé dans une commande que Claude Code ne sait pas décomposer suffisait à passer au travers.

Deux autres correctifs, côté secrets cette fois : les erreurs de plugin et de marketplace pouvaient afficher un jeton ou un mot de passe présent dans l'URL source git, et les détails de serveur MCP (/mcp, /plugin, claude mcp list/get, erreurs de connexion) pouvaient afficher un secret résolu depuis un placeholder ${VAR} d'une configuration MCP. Dans les deux cas, un secret qui n'aurait jamais dû quitter l'environnement se retrouvait affiché à l'écran, potentiellement dans un log ou un partage d'écran.

Le garde-fou qui manquait en mode automatisé

Un hook PermissionRequest se déclenche, dit la doc sur les hooks, quand un appel d'outil a besoin d'une décision de permission : c'est le point d'intégration avec le système de permission lui-même, alors qu'un hook PreToolUse se déclenche avant chaque appel d'outil, que celui-ci demande une permission ou non. La 2.1.268 corrige un cas où ce hook ne se déclenchait pas du tout en mode --print. Concrètement, un pipeline automatisé qui pilotait Claude Code en -p et comptait sur ce hook pour approuver ou refuser des actions tournait sans ce filtre, silencieusement. Même famille de signal perdu en automatisation : les avertissements du policy helper ne s'affichaient pas non plus sur les exécutions headless (-p). Si tu as ce genre de script en production, vérifie que tu es passé sur la 2.1.268.

Trois retouches à la frontière de la confiance

Un coéquipier d'agent relancé dans le même processus pouvait hériter des outils ou du system prompt d'un fichier d'agent portant le même nom trouvé dans un dossier que tu n'as pas explicitement approuvé, contournant ainsi la confirmation de confiance normalement exigée pour ce dossier. Corrigé.

Ensuite, un changement de règle plutôt qu'un bug : les règles deny et ask écrites sur WebFetch nu, sans spécificateur de domaine, ne s'appliquent plus aux lectures et aux mises à jour de l'outil Artifact. Ce dernier ne figure pas dans la table des formats de règles et n'accepte donc que son nom nu. Si tu avais une règle WebFetch nue pour tout bloquer et que tu comptais sur elle pour couvrir aussi Artifact, elle ne le fait plus : il faut désormais une règle Artifact dédiée, ou une règle WebFetch(domain:claude.ai).

Enfin, dans les sessions Cowork locales configurées pour sauter toutes les approbations, l'outil Artifact refuse maintenant un fichier local situé hors des dossiers de la session, ou caché derrière un lien symbolique, au lieu de le lire sans rien demander.

La régression qui coupait tout sur les endpoints tiers

Depuis la 2.1.265, chaque tour échouait avec une erreur HTTP 400 sur les endpoints compatibles Anthropic mais tiers, ceux configurés via ANTHROPIC_BASE_URL. La cause : une expression régulière dans le schéma d'entrée de l'outil Artifact que ces endpoints rejetaient. Si tu fais tourner Claude Code contre un proxy ou une passerelle compatible plutôt que directement contre l'API Anthropic, tu étais bloqué depuis deux versions, sans rien à faire de ton côté pour t'en sortir à part attendre ce correctif. C'est réparé dans la 2.1.268.

Perte de fichiers silencieuse en session cloud longue

Sur Claude Code sur le web, une session cloud qui tournait plus de six heures environ perdait silencieusement les fichiers enregistrés dans les dossiers persistés de la session, sans erreur ni avertissement. Les sauvegardes tiennent désormais jusqu'à une journée. Si tu fais tourner des routines ou des sessions cloud longues qui écrivent des fichiers au fil de l'eau, c'est la limite de six heures qui vient de sauter.

TaskCreate et TodoWrite ne sont plus universels par défaut

Les outils de suivi de tâches, TaskCreate, TaskGet, TaskUpdate, TaskList et TodoWrite, ne sont désormais proposés par défaut que sur Claude 3.x, Opus 4.0 à 4.7, Sonnet 4.0 à 4.6 et Haiku 4.5 (Opus 4.0 et Sonnet 4.0 désignent ici la borne basse d'anciennes générations déjà retirées de la distribution courante, citées telles quelles dans le changelog officiel pour définir la plage). Sur les modèles plus récents, dont Opus 4.8, Opus 5, Sonnet 5 et les modèles Fable, ils disparaissent par défaut : il faut positionner CLAUDE_CODE_ENABLE_TODO_TOOLS=1 pour les retrouver. Si tu comptais sur le suivi de tâches automatique avec un modèle récent, c'est le genre de changement de comportement par défaut qui casse une habitude sans prévenir.

Le reste, en vrac

claude plugin install, uninstall, update, enable, disable acceptent maintenant --json, avec errorDetails et noteDetails ajoutés à chaque ligne de claude plugin list --json.
/plugin applique désormais une installation, une activation ou une désactivation dès la fermeture du menu, sans qu'il faille relancer /reload-plugins.
Une utilisation CPU élevée et durable dans les sessions longues restées inactives, causée par une boucle d'attente active qui monopolisait un cœur, est corrigée, de même que le CPU qui restait haut après des rapports de focus terminal rapprochés pendant un récapitulatif de session.
WebFetch ne reste plus bloqué indéfiniment face à un serveur qui garde la réponse ouverte sans la terminer : un appel échoue désormais au bout de 300 secondes, délai modifiable avec CLAUDE_CODE_WEBFETCH_DEADLINE_MS (0 le désactive).
Les instructions de sandbox Bash ne prétendent plus à un confinement qu'elles n'appliquent pas quand l'isolation du système de fichiers est désactivée.
Claude in Slack ne perd plus ses outils Slack quand les réglages gérés d'une organisation définissent une liste blanche MCP.
Nouveau réglage gatewayInternalNetworks pour autoriser /login sur une passerelle Claude apps depuis le bloc IPv4 public propre à l'organisation, et un avertissement de démarrage quand access_control.allow_cidrs est vide.

Ce qu'il faut retenir

Si tu es en solo avec un compte claude.ai classique, la ligne de ce digest qui te concerne le plus directement est celle sur TaskCreate et TodoWrite : sur Opus 5, Sonnet 5 ou un modèle Fable, le suivi de tâches automatique ne s'active plus tout seul. Le reste vise des publics précis : les scripts d'automatisation en -p qui s'appuient sur un hook PermissionRequest, les configurations passant par ANTHROPIC_BASE_URL qui étaient purement et simplement cassées depuis deux versions, et les sessions cloud longues dont les fichiers ne disparaissent plus après six heures. Beaucoup de petits verrous refermés cette fois, sur des surfaces différentes plutôt que sur un seul mécanisme récurrent.