Claude Code v2.1.307 ajoute des événements de sécurité et restreint les nouvelles tentatives MCP

Anthropic a publié Claude Code v2.1.307 avec de nouveaux rapports de sécurité et une restriction des nouvelles tentatives qui dupliquaient auparavant certains appels à des outils externes. Publiée le 21 octobre, cette mise à jour ajoute également une commande de migration d’API et corrige des erreurs d’authentification trompeuses. Son intérêt pratique se situe dans les mécanismes qui entourent le codage : déterminer quand un agent doit continuer, s’arrêter ou expliquer ce qui l’a bloqué.

La tension centrale oppose la récupération automatique à une exécution prévisible. Réessayer une requête ayant échoué aide souvent un logiciel à terminer son travail. Réessayer une opération ayant déjà modifié un système externe peut répéter cette modification. Cette version traite cette distinction tout en offrant aux administrateurs davantage de visibilité sur les interventions de sécurité.

Cursor fournit un point de comparaison concurrentiel utile, car il combine lui aussi validations, revues automatisées et restrictions d’exécution. La comparaison porte sur le fonctionnement des agents de codage sous contraintes, plutôt que sur le modèle qui écrit le meilleur code. Pour les développeurs exécutant des sessions sans supervision, la question immédiate est de savoir si les échecs deviennent plus faciles à diagnostiquer sans créer d’effets secondaires supplémentaires.

Ce que change Claude Code v2.1.307

La mise à jour modifie la manière dont Claude Code signale les interventions, gère une exécution d’outil incertaine et se remet de certaines défaillances de connexion.

Les notes de version d’Anthropic présentent /claude-api api-version, une commande permettant de migrer du code Claude API vers la version d’API 2026-10-21. Une API, ou interface de programmation applicative, définit la manière dont un logiciel communique avec un service. La date identifie la version d’interface visée par le code applicatif, plutôt que la version installée de Claude Code.

Cette distinction est importante lors de la lecture de l’annonce. Mettre à jour l’application de codage et modifier la version d’API d’une application sont deux opérations distinctes. Une commande de migration aide à effectuer la seconde, mais sa présence ne signifie pas que chaque projet doit migrer immédiatement. Les responsables d’applications doivent toujours examiner les changements obtenus et valider leurs intégrations.

L’autre ajout majeur est claude_code.safety_event. Il utilise OpenTelemetry, un cadre standard pour exporter des mesures et des événements opérationnels. Anthropic indique que l’événement couvre les appels d’outils que les règles d’autorisation, le mode automatique, les contrôles de sécurité, les hooks ou les contrôles de sandbox arrêtent, soumettent à confirmation ou renvoient.

Les hooks sont des programmes configurés qui s’exécutent à des moments définis du flux de travail d’un agent. Une sandbox limite l’accès d’un processus à des ressources telles que les fichiers et les réseaux. Ces mécanismes interviennent à différentes étapes ; enregistrer les interventions peut donc aider à expliquer pourquoi une tâche apparemment simple s’est arrêtée.

La version modifie également les nouvelles tentatives pour les outils HTTP MCP. HTTP transporte des requêtes entre systèmes, tandis que MCP, le Model Context Protocol, connecte les applications d’IA à des outils et données externes. Anthropic indique que des fermetures de connexion pendant l’exécution d’outils entraînaient auparavant l’envoi en double de certains appels.

Avec le nouveau comportement, seules les tentatives concernant des outils classés en lecture seule ou idempotents sont renouvelées. Une opération idempotente a le même effet prévu lorsqu’elle est répétée que lorsqu’elle est effectuée une seule fois. Cette restriction traite directement le risque qu’une récupération automatique répète une modification externe.

D’autres correctifs concernent les alias de modèles, les passerelles personnalisées et l’état des connexions. Ces détails semblent plus restreints qu’une nouvelle fonctionnalité de codage, mais ils déterminent si une session parvient à un travail utile. Une erreur de sélection de modèle ou un identifiant inaccessible peut interrompre une tâche pourtant valide avant le début des modifications de code.

Pris ensemble, ces changements appuient une interprétation précise : Anthropic améliore la couche d’exécution qui entoure le modèle. Les notes de version décrivent des corrections ciblées et une visibilité accrue. Elles ne fournissent pas de preuve d’une meilleure précision de codage, d’un raisonnement plus étendu ou d’un gain de productivité mesuré.

Le travail sans supervision rend les erreurs trompeuses plus coûteuses

Les développeurs qui exploitent des sessions sans supervision ont la raison la plus claire d’examiner les correctifs liés à la connexion et à l’authentification.

Anthropic indique que les serveurs MCP sur macOS pouvaient afficher une exigence d’authentification alors que le trousseau de connexion était en réalité verrouillé. Le trousseau stocke les identifiants utilisés par les applications. Dans le parcours d’exécution claude -p concerné, le message orientait les utilisateurs vers une connexion, même si l’accessibilité des identifiants était le problème sous-jacent.

Le comportement révisé explique la condition de trousseau verrouillé. Selon les notes de version, une exécution ultérieure se connecte après le déverrouillage du trousseau sans exiger une nouvelle connexion. Il s’agit d’une correction diagnostique significative, car elle dirige l’opérateur vers la condition qu’il doit modifier.

Prenons un flux de travail illustratif qui lit un outil de suivi des tickets avant de préparer une modification de code. Si les identifiants stockés deviennent inaccessibles, l’agent ne peut pas récupérer le ticket. Un message suggérant une authentification expirée envoie le développeur sur une piste de dépannage différente d’un message identifiant un magasin d’identifiants verrouillé.

Cet exemple n’établit pas la fréquence de cette défaillance. Il montre pourquoi la classification des erreurs est importante. Se connecter à nouveau, déverrouiller un trousseau, corriger une autorisation et réparer une connexion réseau sont des réponses différentes. Un logiciel qui les confond transfère un travail d’investigation inutile à l’utilisateur.

Anthropic indique également avoir corrigé des serveurs MCP qui semblaient expirer lorsqu’un ordinateur macOS ou Linux se mettait en veille pendant l’établissement de la connexion. Dans les exécutions headless, qui fonctionnent sans interface interactive, les serveurs concernés pouvaient rester en échec. La correction cible la récupération après une interruption précise plutôt que de promettre une connectivité ininterrompue.

Ces changements exercent une pression pratique sur les développeurs qui maintiennent des automatisations. Ils doivent distinguer une tâche échouée d’une dépendance indisponible, et une dépendance indisponible d’une restriction délibérée. Sans cette distinction, redémarrer l’ensemble du flux de travail devient une réponse séduisante mais mal informée.

Les équipes de plateforme font face à un problème connexe lorsque des développeurs signalent que « l’agent s’est arrêté ». Cette description couvre de nombreuses causes, notamment des opérations bloquées, des identifiants manquants, des machines en veille et des défaillances de services distants. De meilleurs messages réduisent l’ambiguïté, à condition que les procédures de support préservent le contexte pertinent.

L’avantage immédiat est donc plus restreint et plus utile qu’une affirmation générale de fiabilité. Ces correctifs devraient aider les utilisateurs concernés à choisir une action de récupération plus appropriée. Déterminer s’ils réduisent le volume de support ou améliorent les taux d’achèvement nécessite des preuves opérationnelles allant au-delà de l’annonce.

Pour les équipes qui évaluent cette version, les interruptions représentatives comptent davantage qu’une démonstration ininterrompue. Une session réussie montre que le parcours normal fonctionne. Une session interrompue par l’accès à des identifiants ou la mise en veille d’une machine révèle si le système peut expliquer son état et récupérer de manière appropriée.

Cela modifie la discussion sur la mise à niveau. La question pertinente est de savoir quelles conditions d’échec existent dans l’environnement réel d’une équipe. Les développeurs utilisant des outils externes dans un travail en arrière-plan sont exposés différemment d’une personne demandant à Claude Code d’examiner un fichier local.

Des nouvelles tentatives MCP plus sûres laissent davantage de décisions aux opérateurs

Restreindre les nouvelles tentatives échange une part de récupération automatique contre un meilleur contrôle des actions externes répétées.

Une défaillance réseau n’indique pas toujours au client si une opération a été exécutée. Le service externe peut terminer la requête avant que la réponse ne disparaisse. Du point de vue du client, une erreur est survenue ; du point de vue du service, la modification demandée a déjà eu lieu.

Répéter une lecture a généralement des conséquences limitées. Répéter une opération qui crée un enregistrement, envoie un message ou lance une tâche exige davantage de prudence. La propriété importante est ce que fait l’opération lorsqu’elle est répétée, plutôt que si son nom semble inoffensif.

Dans une intégration illustrative avec un outil de suivi des tickets, une connexion peut se fermer après la création d’un nouveau ticket, mais avant que la confirmation ne parvienne à l’agent. Une nouvelle tentative automatique pourrait créer un autre ticket. La requête initiale et la nouvelle tentative ressembleraient à des instructions distinctes, à moins que le service ne reconnaisse leur identité commune.

La nouvelle restriction des tentatives répond à ce type d’incertitude en limitant les appels d’outils que Claude Code répète automatiquement après la défaillance de connexion spécifiée. Elle n’établit pas de garantie universelle selon laquelle les actions externes ne se produisent qu’une seule fois. D’autres couches logicielles et actions de l’opérateur peuvent encore influencer le résultat.

Cette limitation est particulièrement pertinente pour les équipes disposant de leurs propres enveloppes de flux de travail. Si un script externe redémarre l’ensemble d’une tâche après toute erreur, il peut répéter un travail terminé, même lorsque le client interne évite les nouvelles tentatives. La politique de récupération doit tenir compte de l’ensemble du chemin d’exécution.

Les descriptions d’outils comptent également. La spécification des outils MCP décrit les métadonnées relatives au comportement des outils et avertit les clients de ne pas faire confiance aux annotations provenant de serveurs non fiables. Une déclaration indiquant qu’un outil peut être répété sans danger n’est utile que si son implémentation la respecte.

Cela crée du travail pour les auteurs d’intégrations. Un outil présenté comme idempotent doit préserver son effet prévu en cas de répétition, y compris lors d’échecs partiels. Un outil qui crée systématiquement un nouvel objet ne devrait pas recevoir cette classification simplement pour rendre les erreurs transitoires moins visibles.

L’expérience de l’opérateur peut donc devenir moins pratique dans un sens restreint. Un appel qui faisait auparavant l’objet d’une nouvelle tentative automatique peut désormais faire apparaître un échec non résolu. Le développeur doit déterminer si le système externe a changé avant de décider si une autre tentative est appropriée.

Ce résultat est défendable lorsque l’alternative est une action dupliquée non examinée. Néanmoins, le qualifier de plus sûr exige de prêter attention au comportement réel. Si les utilisateurs répondent en relançant aveuglément l’ensemble du processus, la restriction a déplacé la décision sans nécessairement l’améliorer.

L’implémentation la plus solide combine des nouvelles tentatives prudentes à un statut clair des opérations. Une expérience de récupération utile aide les utilisateurs à examiner ce qui s’est passé et à reprendre depuis un point connu. La version d’Anthropic traite la décision de nouvelle tentative ; les propriétaires d’applications et d’outils restent responsables des systèmes qui l’entourent.

C’est le principal compromis de Claude Code v2.1.307. Une exécution plus autonome crée une demande de récupération automatique, tandis que des actions externes significatives exigent de la prudence face à la répétition. La mise à jour trace une frontière plus ferme entre ces objectifs pour les défaillances de connexion MCP concernées.

Les événements de sécurité apportent des éléments sur les raisons de l’arrêt du travail

La télémétrie de sécurité peut faciliter l’enquête sur les interventions, mais l’émission d’un événement ne prouve pas qu’une décision était correcte.

Anthropic décrit claude_code.safety_event comme un enregistrement d’interventions spécifiées lors d’opérations d’outils. Sa valeur réside dans l’explication de ce qui a interrompu l’exécution. Cela donne aux administrateurs un point de départ plus concret qu’un rapport d’échec générique ou qu’une transcription de conversation incomplète.

La configuration de surveillance de Claude Code prend déjà en charge l’exportation de données opérationnelles via OpenTelemetry. Le nouvel événement s’inscrit dans cette approche plus large de surveillance. Les équipes ont toujours besoin d’une configuration d’exportation appropriée et d’une destination capable de conserver et de présenter ces informations.

Un développeur qui voit une commande bloquée souhaite généralement une explication immédiate. Un administrateur qui examine une tendance sur plusieurs sessions a besoin de quelque chose de différent : suffisamment de contexte pour identifier quel mécanisme est intervenu et si ce comportement reflète une politique. Ce sont des utilisations liées, mais distinctes, des mêmes éléments de preuve opérationnels.

Imaginez un projet dans lequel un agent s'arrête à plusieurs reprises avant de contacter un service externe. La cause peut être une restriction réseau intentionnelle ou une commande nécessitant une approbation. L'investigation doit établir l'intervention réelle avant que quiconque n'élargisse les autorisations ou ne modifie le flux de travail.

L'existence de l'événement ne signifie pas que chaque intervention doit devenir une alerte. Des restrictions attendues peuvent générer des enregistrements légitimes pendant le travail ordinaire. Traiter toute cette activité comme un incident risque de submerger les personnes chargées de distinguer l'application d'une politique d'un comportement inattendu.

L'interprétation inverse est également faible. Un faible nombre d'événements ne démontre pas une exécution sûre. Cela peut refléter une charge de travail comportant peu d'actions restreintes, une collecte incomplète ou une politique autorisant un accès étendu. Le volume d'événements nécessite du contexte sur ce que l'agent a tenté de faire.

Il existe une distinction similaire entre observer une décision et l'évaluer. Un enregistrement peut montrer qu'un mécanisme est intervenu sans prouver que cette intervention était appropriée. Évaluer sa justesse exige d'examiner l'action, la politique applicable et le résultat recherché par l'utilisateur.

Pour cette raison, cet ajout soutient plus directement l'investigation que les affirmations d'amélioration de la sécurité. La version ne publie pas de réduction mesurée des actions nuisibles ni d'amélioration chiffrée de la précision des décisions. Ces conclusions nécessiteraient des preuves issues d'évaluations réelles.

Les questions opérationnelles utiles restent concrètes. Un ingénieur de support peut-il relier une interruption signalée à l'événement correspondant ? L'équipe peut-elle distinguer une restriction attendue d'une erreur de configuration ? Les informations exportées arrivent-elles de manière suffisamment fiable pour étayer cette investigation ?

Un registre interrogeable des décisions peut compléter la collecte d'événements. Les équipes d'ingénierie qui maintiennent une base de connaissances technique peuvent préserver des explications de configuration, les conclusions d'incidents et les procédures de reprise approuvées aux côtés de leur autre documentation.

Cette documentation remplit un objectif différent de la télémétrie. Les événements décrivent des occurrences particulières ; des explications maintenues aident les personnes à interpréter des conditions récurrentes. Ensemble, ils peuvent réduire la tentation de résoudre chaque interruption en affaiblissant un contrôle.

L'implication plus large est simple : exploiter des agents de programmation exige une visibilité sur leurs limites. Les équipes doivent comprendre les actions réussies comme les tentatives interrompues. Cette version ajoute une source de preuves supplémentaire pour ce travail tout en laissant l'interprétation à l'opérateur.

Les correctifs de passerelle montrent que l'environnement compte autant que le modèle

Un modèle performant ne peut pas compenser une intégration qui sélectionne le mauvais identifiant ou envoie des en-têtes de requête inappropriés.

Anthropic indique avoir corrigé une erreur de modèle introuvable impliquant CLAUDE_CODE_DISABLE_1M_CONTEXT et des alias portant le suffixe [1m], tels que opus[1m]. Un alias est un identifiant abrégé utilisé pour sélectionner un modèle. La combinaison concernée échouait avant que les utilisateurs puissent évaluer la réponse du modèle.

La version corrige également l'en-tête bêta prompt-caching-scope envoyé via des passerelles personnalisées ANTHROPIC_BASE_URL et sur Foundry, où Anthropic indique qu'il n'a aucun effet. Une passerelle se situe entre une application et son service de modèle. Les en-têtes de requête transportent des informations supplémentaires avec la requête principale.

Ces correctifs illustrent pourquoi l'environnement de déploiement doit faire partie de l'évaluation d'un produit. Le même prompt utilisateur peut emprunter des chemins différents de routage, d'authentification et de configuration. Une équipe qui n'évalue que le chemin de connexion par défaut peut manquer des problèmes qui apparaissent dans sa configuration de production.

La commande de migration d'API s'inscrit dans le même tableau opérationnel. Une commande qui met à jour le code d'une application réduit une partie de l'effort d'édition, mais elle ne supprime pas les dépendances extérieures à ce code. Les tests, le routage du service et les hypothèses de l'application déterminent toujours si une migration est adaptée.

Rien dans cette version ne justifie de traiter la version d'API datée comme un résultat de benchmark de programmation. Les changements d'interface et les performances du modèle répondent à des questions différentes. Les acheteurs devraient évaluer chacun selon les preuves qui lui sont pertinentes, plutôt que de les combiner dans une vaste affirmation de capacité.

Cursor offre une comparaison utile en matière de contrôle d'exécution. Ses modes d'exécution d'agent décrivent des listes d'autorisation, des commandes isolées et une revue automatisée pour d'autres actions. L'approche documentée reconnaît également que la classification automatisée peut commettre des erreurs.

Cette comparaison replace le reporting de sécurité d'Anthropic dans un contexte produit plus large sans désigner de vainqueur. Les deux produits exposent des décisions sur la quantité de travail qui avance automatiquement et les actions nécessitant un examen supplémentaire. Leur documentation seule ne peut pas démontrer quelle implémentation fonctionne mieux pour la charge de travail d'une organisation donnée.

Une comparaison équitable maintiendrait la tâche et l'environnement relativement constants. Les évaluateurs pourraient examiner si chaque produit explique les restrictions, préserve les limites prévues et gère correctement les actions externes interrompues. La production de code reste pertinente, mais elle ne répond pas à ces questions opérationnelles.

Les intégrations MCP de Claude Code montrent pourquoi le périmètre dépasse l'édition locale. Les outils connectés peuvent exposer des outils de suivi des problèmes, des bases de données et d'autres systèmes à un agent. Dès que le flux de travail franchit cette frontière, le comportement de connexion et les décisions de reprise deviennent partie intégrante de l'expérience produit.

Pour les acheteurs en entreprise, cela crée une évaluation plus exigeante qu'une démonstration de génération de code. Ils doivent examiner le comportement avec leur passerelle, leurs modalités d'identification et leurs outils externes. Une configuration qui fonctionne bien pour un développeur individuel ne représente pas automatiquement un déploiement géré.

Pour les responsables des intégrations, la pression est plus immédiate. La sémantique des outils, les messages d'erreur et le comportement de nouvelle tentative doivent s'accorder sur ce qui s'est produit. Lorsqu'ils divergent, l'utilisateur hérite de l'incertitude même si le modèle sous-jacent a correctement compris la tâche.

L'importance concurrentielle est donc opérationnelle. Les agents de programmation rivalisent sur la qualité des modifications générées et sur la capacité des équipes à superviser leur exécution. Ce correctif contribue au second aspect, avec des corrections ciblées plutôt qu'un changement démontré des performances de programmation.

Ce qu'il faut surveiller après la mise à jour

Les éléments de suivi les plus utiles concerneront le comportement de reprise, l'utilité du diagnostic et la compatibilité dans des environnements représentatifs.

Le premier signal est de savoir si les actions externes interrompues évitent les répétitions involontaires. Les équipes disposant d'intégrations MCP devraient examiner les échecs de connexion pendant les opérations qui modifient un état externe. Les preuves devraient inclure les enregistrements du système de destination, car une erreur côté client seule ne peut établir si une requête a été exécutée.

Si les flux de travail concernés cessent de produire des actions dupliquées lors d'interruptions comparables, cela étayerait la valeur pratique de la version. Si les doublons persistent ailleurs dans le flux de travail, l'investigation devrait identifier la couche responsable. Le résultat important est une exécution prévisible dans l'ensemble du système.

Le deuxième signal est de savoir si les événements de sécurité améliorent le diagnostic. Les équipes peuvent examiner si les enregistrements collectés aident à expliquer les interruptions réelles et conduisent à des réponses appropriées. Un événement qui atteint le stockage mais n'aide jamais l'investigation offre moins de valeur opérationnelle que sa disponibilité ne le laisse entendre.

Des preuves d'explications plus rapides et plus précises renforceraient l'intérêt de cet ajout. Des enregistrements manquants, une présentation confuse ou un contexte incomplet le limiteraient. Aucun de ces résultats n'exige de supposer que chaque intervention est bénéfique ou que chaque interruption indique un défaut.

Le troisième signal est de savoir si les correctifs de compatibilité tiennent dans les environnements qu'ils ciblent. Les cas pertinents incluent les passerelles personnalisées, la configuration d'alias de modèle concernée, les trousseaux macOS verrouillés et la configuration de connexion interrompue par la mise en veille. Ces conditions sont plus instructives qu'une affirmation générale selon laquelle l'application semble désormais plus fluide.

Une reprise réussie dans ces cas étayerait l'explication d'Anthropic concernant les correctifs. De nouvelles régressions ou des échecs répétés nuanceraient la conclusion et identifieraient les domaines où davantage de travail reste nécessaire. La version devrait être jugée selon ces comportements spécifiques plutôt que selon une promesse indéfinie de fiabilité.

Au cours des prochains mois, les notes de version ultérieures et les rapports reproductibles aideront à distinguer les corrections durables des cas limites restants. Les rapports devraient préciser l'environnement d'exécution et le résultat observé. Sans ce contexte, des échecs superficiellement similaires peuvent mener à des conclusions contradictoires.

L'implication plus large pour l'achat est de faire preuve de retenue face aux fonctionnalités phares. Une autonomie accrue a de la valeur lorsque les équipes peuvent comprendre et gérer ses conséquences. Des erreurs plus claires, des nouvelles tentatives prudentes et des interventions visibles répondent à cette exigence, même s'ils ne remplacent ni les tests applicatifs ni une conception soignée de l'intégration.

Pour les développeurs qui envisagent Claude Code v2.1.307, commencez par les flux de travail qui dépendent d'outils externes ou d'une exécution en arrière-plan. Comparez le comportement avant et après la mise à jour lors d'interruptions représentatives. Inspectez le système externe lorsqu'une opération d'écriture renvoie un résultat incertain, et confirmez que la supervision capture des explications utiles. Gardez les changements de migration d'API suffisamment séparés pour les examiner au regard des tests de l'application. Consignez les correctifs qui affectent votre environnement et ceux qui restent sans effet sur votre configuration. Ces éléments rendront la décision de mise à niveau plus utile qu'une impression générale tirée d'une session ininterrompue. Quelle partie de votre flux de travail actuel est la plus difficile à expliquer lorsque l'agent s'arrête ?