Les mods de Claude Code arrivent, mais l’interface personnalisée s’accompagne d’un accès complet à la machine

Anthropic a lancé les mods de Claude Code le 1er octobre, transformant un agent de programmation auparavant figé en une surface programmable offrant un accès approfondi à son comportement. Les développeurs peuvent désormais utiliser TypeScript pour réécrire des prompts, intercepter des appels d’outils, modifier des éléments d’interface ou remplacer des fonctionnalités intégrées.

Cette sortie est plus importante qu’une simple mise à jour de plugins. Les mods de Claude Code peuvent s’exécuter avant, après, autour ou à la place d’événements générés par l’agent de programmation. Anthropic permet de fait à des développeurs externes de modifier le produit depuis son flux d’événements.

Cette souplesse crée une tension directe entre contrôle et confiance. Un mod utile peut masquer un secret avant que le modèle ne le lise. Un mod malveillant ou mal conçu peut accéder aux mêmes ressources machine que celles disponibles pour Claude Code lui-même.

La comparaison ne se limite plus à déterminer quel agent de programmation écrit le meilleur code. OpenAI et Google distribuent également des extensions, des skills, des hooks et des outils connectés. Anthropic accentue la pression en rendant le comportement et l’interface de l’agent inhabituellement remplaçables.

Les mods de Claude Code transforment les événements en points d’extension

Le changement central est que les développeurs peuvent désormais intervenir au sein du chemin d’exécution de Claude Code, plutôt que de seulement ajouter des instructions ou des commandes externes.

Anthropic décrit un mod comme une petite fonction TypeScript qui modifie le fonctionnement de Claude Code. Son annonce de lancement indique que les mods fonctionnent à la fois dans l’interface en ligne de commande et dans l’application de bureau.

Claude Code émet des événements lorsqu’il exécute des actions. Ces actions comprennent l’envoi de prompts, l’appel d’outils, les demandes d’autorisation et le rendu de certaines parties de l’interface.

Un mod enregistre une fonction pour un ou plusieurs de ces événements. Cette fonction peut s’exécuter avant un événement, après celui-ci ou à sa place. Elle peut également envelopper l’événement, c’est-à-dire effectuer une tâche des deux côtés de l’action originale.

Cette organisation ressemble à un middleware dans une application web. Chaque couche reçoit un événement et peut l’inspecter, le transformer, le bloquer ou le transmettre. L’ordre de chargement détermine la façon dont plusieurs mods interagissent.

Le premier mod chargé voit un événement en premier. Il reçoit le résultat final en dernier, une fois que les couches internes ont achevé leur travail. Ce modèle d’imbrication permet à plusieurs mods développés indépendamment de participer au même flux de travail.

Les effets pratiques vont bien au-delà du changement de couleurs ou de l’ajout de raccourcis. Selon Anthropic, un mod peut réécrire un prompt avant que le modèle ne le reçoive. Il peut également bloquer, modifier ou relancer un appel d’outil.

Les mods peuvent approuver ou refuser des demandes d’autorisation. Ils peuvent filtrer la sortie des outils avant que Claude ne la lise, notamment en supprimant des identifiants ou d’autres valeurs sensibles. Ils peuvent remplacer le contenu présenté à l’utilisateur sans modifier le modèle sous-jacent.

La couche d’interface est elle aussi ouverte aux interventions. Les mods peuvent modifier un résultat d’outil, remplacer une question, ajouter des boutons, accepter des saisies ou créer un volet distinct. D’autres mods peuvent répondre lorsqu’un utilisateur interagit avec ces contrôles.

Cela fait de l’interface personnalisée de Claude Code bien plus qu’une capacité décorative. Une équipe pourrait afficher l’état d’une compilation à côté d’une conversation, demander une approbation structurée ou montrer une vue en direct des fichiers modifiés.

Un même mod peut cibler le terminal, l’application de bureau ou les deux. Les développeurs n’ont donc pas besoin de créer des extensions entièrement distinctes pour chaque interface, même si le comportement peut toujours varier selon la surface.

Anthropic a également relié cette fonctionnalité au système de plugins existant de Claude Code. Les mods sont empaquetés à l’intérieur de plugins plutôt que distribués via un mécanisme d’installation distinct.

Les utilisateurs peuvent parcourir les plugins compatibles ou les installer via /plugin dans la CLI. Anthropic dispose ainsi d’un chemin établi pour la découverte, le partage et le contrôle administratif.

Un développeur n’a pas nécessairement besoin d’écrire le code manuellement. Anthropic indique que Claude Code peut créer un mod à partir d’une demande, l’installer et le recharger à chaud durant la session active.

Cette boucle abaisse la barrière à l’expérimentation. Une personne peut décrire une protection ou un élément d’interface souhaité, inspecter le TypeScript généré et le tester sans redémarrer le produit.

Toutefois, le code généré n’élimine pas le besoin de révision. Il déplace le goulot d’étranglement de la production d’une extension vers la décision de savoir si cette extension se comporte de manière sûre.

Pourquoi les mods TypeScript de Claude Code vont au-delà des hooks traditionnels

Les mods TypeScript de Claude Code réduisent l’écart entre l’observation de l’activité de l’agent et la modification de cette activité elle-même.

Claude Code prenait déjà en charge les hooks avant ce lancement. Les hooks traditionnels exécutent des commandes à des points sélectionnés du cycle de vie, en échangeant souvent des données structurées avec l’hôte via l’entrée et la sortie standard.

Ce modèle fonctionne pour les notifications, le formatage, la validation et les contrôles de politique simples. Il devient restrictif lorsqu’une extension nécessite un état persistant, des contrôles interactifs ou l’accès à l’interface rendue.

Anthropic indique que les hooks traditionnels ne peuvent pas réécrire chaque événement, dessiner de nouveaux composants d’interface ou remplacer des fonctionnalités existantes. Les mods ajoutent ces capacités en exécutant des fonctions typées sur le système d’événements interne de l’agent.

La distinction importe, car une commande externe se situe généralement à côté d’un flux de travail produit. Un hook de fonction peut se placer directement dans ce flux et modifier ce qui se produit ensuite.

Par exemple, un hook conventionnel pourrait rejeter une commande dangereuse après avoir reçu ses détails. Un mod peut inspecter l’événement, réviser la commande, demander une nouvelle confirmation ou fournir une réponse de remplacement.

Un mod peut également conserver un état pendant une session. Cela permet des contrôles qui se mettent à jour au fur et à mesure que l’agent travaille, comme un indicateur de déploiement ou une liste de vérification liée à l’activité des outils.

L’interface TypeScript fournit aux développeurs des types déclarés pour les événements et les capacités. Claude Code peut générer ces déclarations via /plugin-types, permettant aux éditeurs et aux compilateurs d’identifier les appels non pris en charge avant l’exécution.

La documentation des mods d’Anthropic présente les hooks de fonction comme le mécanisme sous-jacent. « Mods » est l’appellation produit des plugins construits autour de ces hooks.

Il s’agit d’une frontière importante. Un mod n’est ni un nouveau modèle, ni un modèle de prompt, ni une application indépendante. C’est du code d’extension exécutable qui participe à la session existante de Claude Code.

Anthropic a discuté publiquement de ce mécanisme avant la sortie complète. Une discussion de conception ouverte le 3 septembre demandait aux développeurs leur avis sur les hooks de fonction TypeScript.

La proposition mettait l’accent sur la composabilité. Les fonctions utilisent un modèle de continuation : chaque mod peut appeler la couche suivante et agir sur la réponse lorsque le contrôle revient.

Anthropic a confirmé le nom Claude Mods dans une mise à jour du 9 septembre. L’entreprise a également rendu disponibles des exemples intégrés précoces et activé les tests via un indicateur d’environnement expérimental.

La sortie du 1er octobre a suivi cet aperçu public. Cette séquence suggère qu’Anthropic souhaitait recueillir des retours sur le contrat d’extension avant de le présenter comme une capacité produit finalisée.

Cette sortie modifie également la relation entre le cœur de Claude Code et ses fonctions optionnelles. Anthropic a déplacé /diff, qui affiche les modifications non validées, dans un mod intégré.

Les utilisateurs peuvent désactiver cette implémentation ou la remplacer par une autre. Anthropic indique prévoir de déplacer davantage de fonctionnalités existantes vers des mods au fil du temps.

Cette orientation pointe vers un cœur plus réduit, entouré de composants remplaçables. Elle crée également une bibliothèque de référence publique montrant comment Anthropic utilise lui-même l’interface.

Le dépôt expose actuellement le code source de quatre mods intégrés. Son code source intégré documente sec-default, diff, telemetry et agents-md.

Ces exemples sont utiles, car ils démontrent davantage qu’une API promise. Ils montrent comment Anthropic structure des plugins complets, enregistre des événements, définit des types et teste les comportements.

Le dépôt étiquette toujours les hooks de fonction comme un accès anticipé. Il avertit que l’API peut changer entre les versions sans préavis. Les développeurs doivent donc considérer les intégrations actuelles comme sensibles aux versions.

Cette réserve limite la rapidité avec laquelle les équipes devraient faire dépendre des flux de travail essentiels des mods. Un panneau d’état interne est facile à réviser. Une couche d’autorisation de production exige une gestion des changements bien plus stricte.

La compétition sur l’extensibilité se déplace au cœur de l’agent

Anthropic concurrence ses rivaux sur la question de savoir qui contrôle l’environnement de programmation, et pas seulement sur le modèle qui produit la meilleure complétion.

Les agents de programmation prennent de plus en plus en charge des instructions réutilisables, des outils externes, des hooks de cycle de vie et des packages installables. Ces systèmes permettent aux développeurs d’adapter un agent généraliste à un dépôt ou à une organisation particulière.

Les extensions Gemini CLI de Google peuvent regrouper des prompts, des serveurs MCP, des commandes personnalisées, des thèmes, des hooks, des sous-agents et des skills. Son système d’extensions officiel met l’accent sur des packages que les utilisateurs peuvent installer et partager.

Le modèle de plugin Codex d’OpenAI combine des skills, des serveurs MCP, des ressources d’interface facultatives et des hooks de cycle de vie. L’architecture de plugin publiée prend en charge des packages partagés entre les surfaces ChatGPT et Codex.

Les mods de Claude Code recoupent ces systèmes, mais l’argument d’Anthropic se concentre sur le remplacement d’événements et le rendu natif. Le mod peut modifier le propre chemin d’action de l’agent plutôt que de seulement fournir un autre outil ou ensemble d’instructions.

Cela crée une pression concurrentielle sur plusieurs fronts.

Premièrement, les développeurs peuvent s’attendre à ce que les agents de programmation exposent leurs interfaces comme des surfaces programmables. Un transcript fixe devient moins attrayant lorsqu’un autre produit permet des volets, des boutons et des résultats rendus personnalisés.

Deuxièmement, les équipes peuvent s’attendre à ce que les politiques de l’agent soient exécutables et contextuelles. Des paramètres statiques peuvent définir des règles générales, mais un mod peut évaluer l’événement actif et prendre une décision plus précise.

Troisièmement, les développeurs peuvent s’attendre à ce que les fonctionnalités intégrées deviennent remplaçables. La décision d’Anthropic d’implémenter /diff sous forme de mod démontre que le même contrat d’extension peut servir du code propriétaire comme du code tiers.

Cela ne rend pas tous les systèmes d’extension directement interchangeables. OpenAI, Google et Anthropic exposent des événements, des règles d’empaquetage, des mécanismes de confiance et des expériences utilisateur différents.

Leurs priorités sous-jacentes diffèrent également. Certains systèmes sont centrés sur des instructions portables. D’autres mettent l’accent sur les connexions à des services externes, les hooks de commande ou les applications intégrées.

Les mods TypeScript de Claude Code mettent davantage l’accent sur la modification de l’agent en cours d’exécution lui-même. Cela est utile lorsqu’un flux de travail doit intercepter une activité plutôt qu’attendre qu’un modèle sélectionne un autre outil.

Prenons une équipe qui interdit les modifications directes de la configuration de production. Un mod pourrait inspecter les commandes proposées et exiger une confirmation dédiée avant leur exécution.

Un autre mod pourrait surveiller les événements CI et maintenir un volet d’état à côté de la conversation. Les développeurs n’auraient pas besoin de changer de fenêtre ni de demander au modèle un résumé actualisé.

Un autre encore pourrait masquer les secrets dans la sortie des commandes avant que cette sortie n’entre dans le contexte du modèle. C’est particulièrement pertinent lorsque des commandes de diagnostic exposent des tokens, des chaînes de connexion ou des identifiants de clients.

Ces scénarios combinent des modifications de comportement, de politique et d’interface. Ils nécessiteraient autrement un mélange de hooks shell, de scripts d’encapsulation, de tableaux de bord et d’instructions de dépôt.

L’avantage concurrentiel le plus puissant réside donc peut-être dans la consolidation. Un seul plugin peut distribuer un workflow cohérent contenant à la fois la logique d’événement et son interface utilisateur personnalisée pour Claude Code.

Toutefois, la flexibilité du produit ne garantit pas sa portabilité. Un mod conçu pour les événements et les composants d’interface de Claude Code restera lié à l’environnement d’exécution d’Anthropic.

Cela crée un arbitrage stratégique pour les éditeurs d’outils. Une intégration native approfondie peut offrir une meilleure expérience, tandis qu’un serveur MCP ou un outil en ligne de commande portable peut toucher davantage d’agents.

La réponse probable du marché élargi ne sera pas une copie exacte des fonctionnalités. Les concurrents peuvent plutôt améliorer la couverture des hooks, les surfaces interactives, la distribution de packages et les contrôles de sécurité.

Le lancement d’Anthropic relève néanmoins le niveau de référence. Les développeurs peuvent désormais se demander pourquoi un autre agent de code expose des outils, mais pas son propre pipeline de rendu, ses demandes d’autorisation ou ses fonctionnalités intégrées.

L’accès complet à la machine fait de la confiance la véritable contrainte

Le détail le plus important est aussi le moins rassurant : les mods ne sont pas isolés de la machine qui exécute Claude Code.

Anthropic indique que les mods disposent du même accès à la machine que Claude Code lui-même. L’entreprise conseille aux utilisateurs d’installer des mods uniquement depuis des sources auxquelles ils font confiance.

Cet avertissement change la manière dont les équipes devraient évaluer cette fonctionnalité. Un mod Claude Code est du code exécutable, et non un prompt passif ou un thème cosmétique.

Un mod peut participer aux appels d’outils et aux décisions d’autorisation. Il peut aussi modifier ce que les utilisateurs voient, y compris la présentation des résultats et des questions.

Cette combinaison crée plusieurs risques.

Un mod malveillant pourrait tenter de lire des fichiers locaux, de contacter des services distants ou d’influencer des commandes. Un mod négligent pourrait divulguer des informations sans chercher délibérément à attaquer l’utilisateur.

Une modification d’interface trompeuse pourrait masquer une sortie pertinente ou présenter une opération dangereuse comme habituelle. Un gestionnaire d’autorisations défaillant pourrait approuver une action qui aurait dû nécessiter un examen.

Les mods composés ajoutent une autre couche d’incertitude. Plusieurs fonctions peuvent observer ou transformer le même événement, et leur ordre de chargement détermine le comportement final.

Les tests isolés sont donc insuffisants. Les équipes doivent également tester les combinaisons, en particulier lorsque plusieurs plugins modifient les prompts, les outils, les autorisations ou la sortie d’interface.

Anthropic traite en partie le contrôle en entreprise par la gouvernance des plugins. Les administrateurs peuvent autoriser ou bloquer des places de marché de plugins en utilisant les contrôles existants plutôt qu’en créant un canal de politique distinct pour les mods.

Les environnements gérés chargent également en premier un mod intégré nommé sec-default. Anthropic affirme qu’il empêche les mods installés par les utilisateurs de remplacer les prompts, paramètres, politiques d’outils et règles de refus gérés.

Le chargement en premier est important, car la fonction la plus externe voit un événement avant les couches inférieures et le reçoit de nouveau après leur retour. Cette position permet à une politique administrative d’envelopper les extensions installées.

Anthropic autorise les administrateurs à préfixer leurs propres mods. L’entreprise leur conseille de conserver sec-default dans ce cas, afin de préserver les restrictions fournies.

Cette conception est réfléchie, mais elle ne transforme pas du code tiers arbitraire en code digne de confiance. sec-default protège certains contrôles gérés plutôt que d’isoler dans un sandbox tous les effets secondaires possibles.

Cette distinction doit rester claire lors des achats et des revues de sécurité. La priorité administrative réduit une catégorie de contournement des politiques. Elle n’élimine pas le risque lié à la chaîne d’approvisionnement.

La distribution de plugins crée également un problème d’identité familier. Une fiche soignée, un dépôt populaire ou un nom reconnaissable ne prouvent pas que chaque version contient du code sûr.

Les équipes ont besoin de provenance, de versions figées, de revue du code source et de tests reproductibles. Elles doivent savoir qui maintient un mod et comment les mises à jour arrivent sur les machines des développeurs.

Les mods générés exigent le même examen. Claude Code peut en créer un rapidement, mais le TypeScript généré peut contenir des erreurs de logique, des vérifications incomplètes ou des accès non intentionnels.

Un mod de sécurité mérite une revue particulièrement attentive, car les utilisateurs peuvent lui accorder une confiance accrue. Une couche de masquage des secrets qui omet un seul chemin de sortie peut créer un faux sentiment de protection.

L’API en accès anticipé ajoute un risque opérationnel. Des changements incompatibles peuvent désactiver un mod de politique ou modifier le comportement des événements après une mise à jour de Claude Code.

Pour une personnalisation personnelle à faible risque, cette instabilité peut être gérable. Pour la journalisation d’audit, les protections de production ou les contrôles de conformité, les équipes ont besoin d’une validation avant chaque déploiement.

Les développeurs doivent également distinguer la confiance dans l’interface de la confiance dans l’exécution. Un mod qui modifie l’interface utilisateur personnalisée de Claude Code peut influencer ce qu’un utilisateur pense s’être produit, même si le journal de commandes sous-jacent diffère.

Cela rend les enregistrements indépendants importants. Les systèmes de production devraient conserver des journaux faisant autorité en dehors de l’affichage et du stockage propres au mod.

L’incertitude critique ne concerne pas la capacité des mods à produire des extensions utiles. Anthropic a déjà présenté des exemples concrets et publié des implémentations intégrées fonctionnelles.

La question est de savoir si l’écosystème environnant développera de solides pratiques de revue avant que l’installation à grande échelle ne devienne normale. La commodité évolue souvent plus vite qu’une inspection minutieuse.

Le remplacement des fonctionnalités intégrées change qui possède le workflow

Déplacer des fonctionnalités propriétaires dans des mods transforme Claude Code d’un produit configurable en un produit partiellement remplaçable.

L’exemple de /diff est facile à sous-estimer. L’affichage des différences semble être une fonctionnalité d’interface limitée, mais son implémentation établit un précédent plus large.

Anthropic peut fournir des fonctionnalités par le même mécanisme que celui accessible aux développeurs d’extensions. Les utilisateurs peuvent alors désactiver la version intégrée, étudier son code source ou la remplacer par une autre implémentation.

Cette organisation réduit l’écart entre les fonctionnalités propriétaires et tierces. Elle offre aux développeurs un exemple qui reflète le comportement réel de l’environnement d’exécution plutôt qu’un tutoriel abstrait.

Elle permet aussi aux équipes d’effectuer des remplacements assumés. Une organisation pourrait exiger des différences regroupées par service. Une autre pourrait masquer les fichiers générés ou ajouter des contrôles de revue propres au dépôt.

Une implémentation personnalisée pourrait ajouter des boutons d’approbation à côté de changements sélectionnés. Elle pourrait relier un fichier modifié à l’état des tests ou mettre en évidence les chemins régis par une politique plus stricte.

L’avantage ne se limite pas à la personnalisation. Le workflow peut rester au sein de la session de code, ce qui réduit la nécessité de passer d’un outil à l’autre pendant la revue.

Le même modèle pourrait s’étendre à d’autres fonctionnalités de Claude Code si Anthropic suit son plan annoncé. Davantage de fonctionnalités intégrées deviendraient des couches facultatives autour d’un moteur plus restreint.

Cela crée des opportunités pour les développeurs indépendants. Un mod bien maintenu pourrait servir un public spécialisé sans attendre qu’Anthropic priorise cette fonctionnalité.

Cela donne aussi aux entreprises un autre endroit où encoder leurs workflows internes. Une entreprise peut distribuer des plugins contenant à la fois des fonctionnalités de productivité et l’application des politiques.

La remplaçabilité introduit toutefois de la fragmentation. Deux développeurs utilisant Claude Code pourraient voir des interfaces différentes, recevoir des demandes d’autorisation différentes et exécuter des transformations d’événements différentes.

Les équipes de support devront savoir quels mods étaient chargés lorsqu’un problème s’est produit. Les rapports de bogues sans ce contexte pourraient devenir difficiles à reproduire.

L’ordre de chargement devient une partie de l’environnement. Un mod qui se comporte correctement seul peut produire une sortie différente lorsqu’il est enveloppé par une autre extension.

Cela ressemble à la complexité des extensions de navigateur, des plugins d’éditeur et des middlewares de systèmes de build. L’extensibilité crée un effet de levier, mais elle élargit aussi le nombre d’états d’exécution possibles.

Le support des tests par Anthropic est donc important. Le dépôt présente des tests construits sur la même interface d’événements et comprend des commandes permettant de valider le comportement des plugins.

La vérification de types peut identifier des déclarations incompatibles. Les tests unitaires peuvent vérifier la réponse d’un mod aux événements attendus. Ni l’un ni l’autre ne peut garantir la sécurité lorsque du code non fiable reçoit de larges capacités.

Les organisations auront besoin d’une approche à plusieurs niveaux. La revue statique, les tests automatisés, le contrôle de version, le déploiement progressif et la journalisation à l’exécution traitent chacun des modes de défaillance différents.

Le modèle de place de marché pourrait aussi nécessiter à terme des signaux plus solides. Une identité d’éditeur vérifiée, des capacités déclarées, des builds reproductibles et un historique de mises à jour visible aideraient les utilisateurs à évaluer le risque.

Anthropic n’a pas démontré, à travers cette annonce, que de tels contrôles résoudront le problème. Le lancement fournit des briques de contrôle administratif, et non un système complet d’assurance.

Pour les développeurs, la décision immédiate consiste à déterminer si un comportement souhaité nécessite réellement un mod. Certains besoins restent mieux servis par une instruction de dépôt, une compétence, un outil externe ou un hook conventionnel.

Un mod est pertinent lorsque le workflow doit transformer des événements, conserver un état en direct, remplacer le rendu ou répondre directement à une interaction d’interface.

L’utiliser pour de simples indications textuelles ajouterait du code exécutable inutile. Une intégration plus profonde doit correspondre à un besoin réel de contrôle plus profond.

Ce qu’il faut surveiller après le lancement des mods Claude Code

La prochaine phase sera déterminée par la qualité de l’écosystème, les contrôles pour les entreprises et les preuves que les mods restent fiables entre les versions de Claude Code.

Le premier signal est l’éventail de plugins crédibles qui adoptent les mods. De petites expérimentations visuelles prouvent que le rendu fonctionne, mais l’utilisation en production exige des intégrations maintenues avec une responsabilité clairement établie.

Surveillez les mods qui connectent les workflows de développement sans masquer leur comportement. L’état de CI, la revue de code, la coordination des tests et la confirmation de production sont de solides candidats.

Les éléments clés seront l’utilisation répétée, un code source transparent et une maintenance cohérente. Un vaste répertoire ne mesurerait que l’offre, pas la confiance ni la valeur.

Le deuxième signal est la manière dont Anthropic gère les frontières de sécurité. L’architecture actuelle fournit sec-default pour les environnements gérés, mais les mods continuent de s’exécuter sans sandbox général.

De futures documentations et versions pourraient ajouter des déclarations de capacités, des demandes d’autorisation plus claires, une isolation renforcée ou une revue améliorée des places de marché. De tels changements renforceraient les arguments en faveur d’une adoption organisationnelle large.

Un incident de sécurité grave produirait l’effet inverse. Il montrerait que la facilité d’installation a dépassé les contrôles nécessaires pour du code disposant d’un accès à la machine locale.

Le troisième signal est la stabilité de l’API. Anthropic identifie actuellement l’interface des hooks de fonctions comme étant en accès anticipé et avertit que les versions peuvent introduire des changements.

Les développeurs devraient surveiller la fréquence des changements dans les contrats d’événements et la manière dont Anthropic communique les migrations. Des types stables, des conseils de compatibilité et des périodes de dépréciation prévisibles favoriseraient des intégrations durables.

Des ruptures fréquentes confineraient les mods aux expérimentations et aux commodités facultatives. Les équipes ne fonderont pas de contrôles obligatoires sur une interface qui change sans préavis suffisant.

Les réponses des concurrents constituent un contexte utile. Google et OpenAI proposent déjà des packages d’extensions, des hooks, des compétences, des outils connectés et des intégrations d’interface.

La question est de savoir s’ils exposeront davantage des flux internes d’événements et de rendu de leurs agents de code. Si c’est le cas, les interfaces d’agents programmables pourraient devenir une catégorie standard plutôt qu’une distinction propre à Anthropic.

Les mods Claude Code modifient déjà les frontières du produit. Les développeurs peuvent désormais modifier les prompts, les outils, les autorisations, le rendu et certaines fonctionnalités intégrées avec des fonctions TypeScript.

Ce qui reste non résolu est de savoir si cette liberté peut évoluer sans créer une chaîne d’approvisionnement d’extensions que les utilisateurs ne peuvent pas raisonnablement inspecter.

Pour l’instant, traitez chaque mod comme un logiciel local, examinez son code source, testez-le avec les autres plugins installés et figez la version utilisée par votre équipe. Posez ensuite une question plus difficile avant l’installation : ce workflow a-t-il besoin d’accéder au chemin d’exécution de l’agent, ou une extension plus limitée produirait-elle le même résultat ?