Claude Code v2.1.223 ajoute deux contrôles de gouvernance que ceux qui déploient des agents en production attendaient : les wildcards d’organisation pour gérer les marketplaces de skills et les alertes quand un subagent demande un modèle restreint et reçoit à la place le modèle parent.

Comme nous le racontions hier avec la v2.1.222, Claude Code ferme en rapide succession les problèmes opérationnels qui le séparaient de l’usage en équipe. Les wildcards de propriétaire ("owner/*") dans les paramètres gérés strictKnownMarketplaces et blockedMarketplaces permettent d’approuver ou de bloquer tous les dépôts marketplace d’une organisation GitHub avec une seule règle. Jusqu’à présent, vous deviez énumérer les dépôts un par un, ou tout ouvrir.

Le deuxième changement concerne la transparence sur les flux repris. Quand un workflow agent, une skill forked, une slash command ou un background agent repris demande un subagent model que votre organisation a restreint, le système faisait tourner le modèle parent sans vous le dire. Maintenant un avertissement apparaît. Cela semble un détail, mais dans une équipe qui gère les coûts et les permissions par modèle, ne pas savoir quel modèle a exécuté une tâche est un problème d’audit.

La release ferme aussi six bugs de sécurité, dont un contournement des permissions Bash où une commande construite astucieusement pouvait se cacher des contrôles, et un bug qui permettait aux scripts de workflow d’utiliser dynamic import() pour exécuter du code hors du sandbox.

En détail

Le marketplace de skills est le mécanisme par lequel Claude Code distribue des paquets de capacités : une skill peut ajouter une commande, une procédure, un workflow entier. Pour une équipe utilisant Claude Code en production, décider quelles skills sont autorisées est une question de sécurité et de cohérence. Une skill malveillante ou défectueuse peut exposer des données, exécuter des commandes arbitraires, ou casser un flux consolidé.

Jusqu’à la v2.1.223, les paramètres gérés strictKnownMarketplaces et blockedMarketplaces exigeaient l’énumération explicite des dépôts. Si votre organisation publie dix dépôts de skills sur le marketplace GitHub, l’administrateur devait écrire dix entrées. La wildcard "owner/*" condense tout en une ligne : vous approuvez ou bloquez l’organisation entière, et les nouveaux dépôts que cette org publie après suivent automatiquement la même règle.

C’est un compromis entre granularité et maintenabilité. Si vous faites confiance à une organisation interne, la wildcard résout le problème de devoir mettre à jour la configuration à chaque nouveau dépôt. Si vous devez bloquer un dépôt spécifique tout en gardant les autres, la règle granulaire par dépôt reste disponible.

L’avertissement sur le subagent model touche un problème différent mais tout aussi concret. Claude Code peut déléguer des parties d’une tâche à un subagent tournant sur un modèle différent de celui principal. Si votre organisation a restreint l’usage d’un modèle pour le coût ou la conformité, et qu’un flux repris ou une skill forked le demande, le système basculait au modèle parent sans le signaler. En production, un rapport d’audit disant « exécuté sur Opus 5 » pourrait être faux : le subagent a tourné sur le modèle que le parent utilisait.

L’avertissement ne bloque pas l’exécution, il la rend visible. Pour qui gère des agents en équipe, la différence entre « silencieux » et « signalé » est la différence entre un audit possible et un impossible.

Les correctifs de sécurité méritent attention. Le contournement des permissions Bash permettait à une commande construite avec des caractères spécifiques de se cacher des contrôles d’approbation. Le correctif sur les tabulations et caractères Unicode invisibles ferme le même vecteur : une commande avec padding invisible pouvait tromper le dialogue d’approbation en montrant seulement une partie de l’instruction réelle. Le dynamic import() dans les scripts de workflow échappait au sandbox en permettant au code de charger des modules arbitraires. Ce sont trois vecteurs que les experts en sécurité reconnaissent : obfuscation du payload, caractères invisibles, échappée du sandbox. Tous fermés dans une release.

La commande /teleport affiche en session cloud comment continuer localement avec claude --teleport <session id>. C’est une feature de continuité : qui travaille en session cloud peut porter le travail dans son environnement sans recommencer. Le changement vers /review, maintenant alias de /code-review, simplifie la révision du code dans le terminal. Le correctif sur la fenêtre de contexte avec CLAUDE_CODE_DISABLE_1M_CONTEXT maintient maintenant chaque modèle Claude avec fenêtre native de 1M tokens en dessous de 200K via auto-compaction, avec un avertissement quand la compaction ne peut pas contenir la session.