Aperçu
La création et la distribution d’une place de marché impliquent :- Créer des plugins : créez un ou plusieurs plugins avec des compétences, des agents, des hooks, des serveurs MCP ou des serveurs LSP. Ce guide suppose que vous avez déjà des plugins à distribuer ; consultez Créer des plugins pour plus de détails sur la création de plugins.
- Créer le fichier de place de marché : définissez un
marketplace.jsonqui répertorie vos plugins et où les trouver. Voir Créer le fichier de place de marché. - Héberger la place de marché : poussez vers GitHub, GitLab ou un autre hôte git. Voir Héberger et distribuer les places de marché.
- Partager avec les utilisateurs : les utilisateurs ajoutent votre place de marché avec
/plugin marketplace addet installent des plugins individuels. Voir Découvrir et installer des plugins.
/plugin marketplace update.
Procédure pas à pas : créer une place de marché locale
Cet exemple crée une place de marché avec un plugin : une compétencequality-review pour les révisions de code. Vous allez créer la structure de répertoires, ajouter une compétence, créer le manifeste du plugin et le catalogue de la place de marché, puis l’installer et la tester.
1
Créer la structure de répertoires
2
Créer la compétence
Créez un fichier
SKILL.md qui définit ce que fait la compétence quality-review.my-marketplace/plugins/quality-review-plugin/skills/quality-review/SKILL.md
3
Créer le manifeste du plugin
Créez un fichier
plugin.json qui décrit le plugin. Le manifeste se trouve dans le répertoire .claude-plugin/.my-marketplace/plugins/quality-review-plugin/.claude-plugin/plugin.json
La définition de
version signifie que les utilisateurs ne reçoivent des mises à jour que lorsque vous modifiez ce champ, donc augmentez-le à chaque version. Si vous omettez version et hébergez cette place de marché dans git, chaque commit compte automatiquement comme une nouvelle version. Consultez Résolution de version pour choisir la bonne approche.4
Créer le fichier de place de marché
Créez le catalogue de la place de marché qui répertorie votre plugin.
my-marketplace/.claude-plugin/marketplace.json
5
Ajouter et installer
Ajoutez la place de marché et installez le plugin.
6
Essayer
Sélectionnez du code dans votre éditeur et exécutez votre nouvelle compétence. Les compétences des plugins sont espacées avec le nom du plugin.
Comment les plugins sont installés : Lorsque les utilisateurs installent un plugin, Claude Code copie le répertoire du plugin vers un emplacement de cache. Cela signifie que les plugins ne peuvent pas référencer des fichiers en dehors de leur répertoire en utilisant des chemins comme
../shared-utils, car ces fichiers ne seront pas copiés.Si vous devez partager des fichiers entre les plugins, utilisez des symlinks. Consultez Plugin caching and file resolution pour plus de détails.Créer le fichier de place de marché
Créez.claude-plugin/marketplace.json à la racine de votre dépôt. Ce fichier définit le nom de votre place de marché, les informations du propriétaire et une liste de plugins avec leurs sources.
Chaque entrée de plugin a besoin au minimum d’un name et d’une source qui indique à Claude Code où la récupérer. Consultez le schéma complet ci-dessous pour tous les champs disponibles.
Schéma de la place de marché
Champs obligatoires
Noms réservés : les noms de place de marché suivants sont réservés à l’usage officiel d’Anthropic et ne peuvent pas être utilisés par les places de marché tierces :
claude-code-marketplace, claude-code-plugins, claude-plugins-official, claude-plugins-community, claude-community, anthropic-marketplace, anthropic-plugins, agent-skills, anthropic-agent-skills, knowledge-work-plugins, life-sciences, claude-for-legal, claude-for-financial-services, financial-services-plugins, first-party-plugins, healthcare. Les noms qui usurpent l’identité de places de marché officielles, comme official-claude-plugins ou anthropic-plugins-v2, sont également bloqués. La réservation de ces noms empêche une place de marché tierce de se présenter comme une source publiée par Anthropic.Claude Code revérifie les noms réservés chaque fois qu’il charge une place de marché, pas seulement lorsque vous en ajoutez une. Une place de marché qui a été enregistrée sous l’un de ces noms avant que le nom ne soit réservé cesse de se charger et signale qu’elle est enregistrée à partir d’une source non fiable. Supprimez cette place de marché et rajoutez-la à partir de la source officielle d’Anthropic. Une place de marché tierce affectée par un nom nouvellement réservé se charge à nouveau dès que vous la rajoutez sous un nom différent. Avant la v2.1.205, first-party-plugins et healthcare n’étaient pas réservés, et une place de marché déjà enregistrée sous un nom réservé continuait à se charger.Champs du propriétaire
Champs optionnels
description et version sont également acceptés sous metadata pour la compatibilité rétroactive.
Entrées de plugin
Chaque entrée de plugin dans le tableauplugins décrit un plugin et où le trouver. Vous pouvez inclure n’importe quel champ du schéma du manifeste du plugin, tel que description, version, author, commands et hooks, plus ces champs spécifiques à la place de marché : source, category, tags, strict et relevance.
Champs obligatoires
Champs de plugin optionnels
Champs de métadonnées standard :
Champs de configuration des composants :
Sources de plugin
Les sources de plugin indiquent à Claude Code où récupérer chaque plugin individuel répertorié dans votre place de marché. Elles sont définies dans le champsource de chaque entrée de plugin dans marketplace.json.
Une fois qu’un plugin est cloné ou téléchargé sur la machine locale, il est copié dans le cache de plugin local versionné à ~/.claude/plugins/cache.
Sources de place de marché vs sources de plugin : Ce sont des concepts différents qui contrôlent des choses différentes.
- Source de place de marché : où récupérer le catalogue
marketplace.jsonlui-même. Défini lorsque les utilisateurs exécutent/plugin marketplace addou dans les paramètresextraKnownMarketplaces. Prend en chargeref(branche/tag) mais passha. - Source de plugin : où récupérer un plugin individuel répertorié dans la place de marché. Défini dans le champ
sourcede chaque entrée de plugin dansmarketplace.json. Prend en charge à la foisref(branche/tag) etsha(commit exact).
acme-corp/plugin-catalog (source de place de marché) peut répertorier un plugin récupéré à partir de acme-corp/code-formatter (source de plugin). La source de place de marché et la source de plugin pointent vers des dépôts différents et sont épinglées indépendamment.github, url et git-subdir. Lorsque ref et sha sont tous deux définis sur l’un d’eux, le sha est l’épingle effective. Claude Code récupère et vérifie le commit épinglé directement.
Sur la plupart des hôtes git, y compris GitHub, GitLab et Bitbucket, cela signifie que l’installation réussit même si la branche ou le tag nommé par ref a depuis été supprimé en amont, tant que le commit est toujours accessible à partir du dépôt. Certains serveurs, tels qu’AWS CodeCommit, ne prennent pas en charge la récupération des commits par SHA. Sur ces serveurs, le ref doit toujours exister et le commit épinglé doit être accessible à partir de celui-ci.
Chemins relatifs
Pour les plugins dans le même dépôt, utilisez un chemin commençant par./ :
.claude-plugin/. Dans l’exemple ci-dessus, ./plugins/my-plugin pointe vers <repo>/plugins/my-plugin, même si marketplace.json se trouve à <repo>/.claude-plugin/marketplace.json. N’utilisez pas ../ pour référencer des chemins en dehors de la racine de la place de marché.
Les chemins relatifs se résolvent par rapport à une copie locale de la place de marché, donc ils fonctionnent lorsque les utilisateurs ajoutent votre place de marché à partir d’une source git ou d’un répertoire local. Si les utilisateurs ajoutent votre place de marché via une URL directe vers le fichier
marketplace.json, les chemins relatifs ne se résoudront pas, car seul ce fichier est téléchargé. Pour la distribution basée sur les URL, utilisez plutôt les sources GitHub, npm ou URL git. Consultez Dépannage pour plus de détails.Dépôts GitHub
Dépôts Git
Sous-répertoires Git
Utilisezgit-subdir pour pointer vers un plugin qui se trouve dans un sous-répertoire d’un dépôt git. Claude Code utilise un clone partiel et clairsemé pour récupérer uniquement le sous-répertoire, minimisant la bande passante pour les grands monodépôts.
url accepte également un raccourci GitHub (owner/repo) ou des URL SSH (git@github.com:owner/repo.git).
Paquets npm
Les plugins distribués en tant que paquets npm sont installés à l’aide denpm install. Cela fonctionne avec n’importe quel paquet du registre npm public ou d’un registre privé que votre équipe héberge.
version :
registry :
Entrées de plugin avancées
Cet exemple montre une entrée de plugin utilisant de nombreux champs optionnels, notamment des chemins personnalisés pour les commandes, les agents, les hooks et les serveurs MCP :commandsetagents: vous pouvez spécifier plusieurs répertoires ou fichiers individuels. Les chemins sont relatifs à la racine du plugin.${CLAUDE_PLUGIN_ROOT}: utilisez cette variable dans les commandes de hook et les configurations du serveur MCP pour référencer les fichiers dans le répertoire d’installation du plugin. C’est nécessaire car les plugins sont copiés vers un emplacement de cache lors de l’installation.- Consultez le tableau de substitution pour savoir quels champs de configuration le substituent par type de serveur
- Pour les dépendances ou l’état qui doivent survivre aux mises à jour des plugins, utilisez
${CLAUDE_PLUGIN_DATA}à la place
strict: false: puisque ceci est défini sur false, le plugin n’a pas besoin de son propreplugin.json. L’entrée de la place de marché définit tout. Voir Mode strict ci-dessous.
skills/ sous sa source. Les chemins répertoriés dans le champ skills s’ajoutent à cette analyse :
skills/ à la racine de la place de marché (source: "./"), énumérez plutôt des sous-répertoires spécifiques afin que chaque entrée ne charge que ses propres compétences :
skills/ partagé ne se chargent pas. L’énumération du répertoire skills/ lui-même, ou de la racine du plugin, maintient l’analyse complète. Si aucun des chemins énumérés n’existe, l’analyse par défaut s’exécute à la place.
Mode strict
Le champstrict contrôle si plugin.json est l’autorité pour les définitions de composants (compétences, agents, hooks, serveurs MCP, styles de sortie).
Quand utiliser chaque mode :
strict: true: le plugin a son propreplugin.jsonet gère ses propres composants. L’entrée de la place de marché peut ajouter des compétences ou des hooks supplémentaires par-dessus. C’est la valeur par défaut et fonctionne pour la plupart des plugins.strict: false: l’opérateur de la place de marché veut le contrôle total. Le dépôt du plugin fournit des fichiers bruts, et l’entrée de la place de marché définit lesquels de ces fichiers sont exposés en tant que compétences, agents, hooks, etc. Utile lorsque la place de marché restructure ou sélectionne les composants d’un plugin différemment de ce que l’auteur du plugin avait prévu.
Héberger et distribuer les places de marché
Héberger sur GitHub (recommandé)
GitHub est la méthode recommandée pour héberger et distribuer une place de marché :- Créer un dépôt : Configurez un nouveau dépôt pour votre place de marché
- Ajouter le fichier de place de marché : Créez
.claude-plugin/marketplace.jsonavec vos définitions de plugins - Partager avec les équipes : Les utilisateurs ajoutent votre place de marché avec
/plugin marketplace add owner/repo
Héberger sur d’autres services git
N’importe quel service d’hébergement git fonctionne, comme GitLab, Bitbucket et les serveurs auto-hébergés. Les utilisateurs ajoutent avec l’URL complète du dépôt :Dépôts privés
Claude Code prend en charge l’installation de plugins à partir de dépôts privés. Pour l’installation manuelle et les mises à jour, Claude Code utilise vos assistants de credentials git existants, donc l’accès HTTPS viagh auth login, Keychain macOS ou git-credential-store fonctionne de la même manière que dans votre terminal. L’accès SSH fonctionne tant que l’hôte est déjà dans votre fichier known_hosts et que la clé est chargée dans ssh-agent, puisque Claude Code supprime les invites SSH interactives pour l’empreinte digitale de l’hôte et la phrase de passe de la clé. Les sources de raccourci owner/repo GitHub clonent par défaut via SSH ; définissez CLAUDE_CODE_PLUGIN_PREFER_HTTPS=1 pour les cloner via HTTPS à la place.
Les mises à jour automatiques en arrière-plan fonctionnent différemment. Par défaut, l’actualisation en arrière-plan désactive les assistants de credentials git pour son git pull, donc le pull ne peut pas s’authentifier auprès des dépôts privés sur HTTPS même lorsqu’un assistant est configuré. Les remotes SSH ne sont pas affectées : une clé chargée dans ssh-agent authentifie les pulls en arrière-plan de la même manière que les opérations manuelles. Lorsque le pull en arrière-plan échoue, Claude Code revient à re-cloner la place de marché à partir de zéro. Le re-clone utilise vos credentials git stockés, mais il peut expirer sur les grands dépôts, donc les mises à jour automatiques de places de marché privées peuvent échouer par intermittence.
Deux paramètres rendent les places de marché privées prévisibles :
- Définissez
CLAUDE_CODE_PLUGIN_KEEP_MARKETPLACE_ON_FAILURE=1pour conserver le clone existant lorsque le pull en arrière-plan échoue, au lieu de supprimer et re-cloner. Vos plugins continuent de fonctionner à partir du dernier état synchronisé, et les mises à jour manuelles avec/plugin marketplace updatetirent toujours avec vos credentials. - Configurez un assistant de credentials git, par exemple avec
gh auth setup-gitpour GitHub, afin que le fallback re-clone puisse s’authentifier sans inviter.
GITHUB_TOKEN dans votre environnement n’active pas par lui-même l’authentification en arrière-plan. Les jetons ne prennent effet que via un assistant de credentials configuré, par exemple l’assistant de l’CLI gh, qui lit GH_TOKEN et GITHUB_TOKEN.
Pour que le pull en arrière-plan lui-même s’authentifie sur HTTPS, configurez une réécriture d’URL git globale. La réécriture intègre un jeton dans l’URL distante, donc elle prend effet même si le pull en arrière-plan désactive les assistants de credentials, et un pull réussi ignore le fallback re-clone. L’exemple suivant réécrit l’URL du dépôt de la place de marché pour inclure un jeton d’accès :
La réécriture stocke le jeton en texte brut dans votre gitconfig, donc utilisez un jeton avec accès en lecture seule au dépôt de la place de marché.
Dans les environnements CI/CD, configurez un assistant de credentials git avant d’installer des plugins à partir de dépôts privés. Sur GitHub Actions, exportez un jeton avec accès en lecture au dépôt de la place de marché en tant que
GH_TOKEN, puis exécutez gh auth setup-git. Le jeton de workflow par défaut ne peut accéder qu’au dépôt du workflow lui-même, donc une place de marché privée dans un autre dépôt a besoin d’un jeton d’accès personnel ou d’un jeton d’application. Une réécriture d’URL globale configurée dans le pipeline authentifie également le pull en arrière-plan directement.Tester localement avant la distribution
Testez votre place de marché localement avant de la partager :Exiger des places de marché pour votre équipe
Vous pouvez configurer votre dépôt pour que les membres de l’équipe soient automatiquement invités à installer votre place de marché lorsqu’ils font confiance au dossier du projet. Ajoutez votre place de marché à.claude/settings.json :
Si vous utilisez une source
directory ou file locale avec un chemin relatif, le chemin se résout par rapport au checkout principal de votre dépôt. Lorsque vous exécutez Claude Code à partir d’une worktree git, le chemin pointe toujours vers le checkout principal, donc toutes les worktrees partagent le même emplacement de place de marché. L’état de la place de marché est stocké une fois par utilisateur dans ~/.claude/plugins/known_marketplaces.json, pas par projet.Pré-remplir les plugins pour les conteneurs
Pour les images de conteneur et les environnements CI, vous pouvez pré-remplir un répertoire de plugins au moment de la construction afin que Claude Code démarre avec des places de marché et des plugins déjà disponibles, sans rien cloner au moment de l’exécution. Définissez la variable d’environnementCLAUDE_CODE_PLUGIN_SEED_DIR pour pointer vers ce répertoire.
Pour superposer plusieurs répertoires de seed, séparez les chemins avec : sur Unix ou ; sur Windows. Claude Code recherche chaque répertoire dans l’ordre et utilise le premier seed qui contient une place de marché ou un cache de plugin donné.
Le répertoire de seed reflète la structure de ~/.claude/plugins :
~/.claude/plugins résultant dans votre image et pointez CLAUDE_CODE_PLUGIN_SEED_DIR vers lui.
Pour ignorer l’étape de copie, définissez CLAUDE_CODE_PLUGIN_CACHE_DIR sur votre chemin de seed cible lors de la construction afin que les plugins s’installent directement là :
CLAUDE_CODE_PLUGIN_SEED_DIR=/opt/claude-seed dans l’environnement d’exécution de votre conteneur afin que Claude Code lise à partir du seed au démarrage.
Au démarrage, Claude Code enregistre les places de marché trouvées dans le known_marketplaces.json du seed dans la configuration principale, et utilise les caches de plugins trouvés sous cache/ en place sans re-cloner. Cela fonctionne à la fois en mode interactif et en mode non-interactif avec le drapeau -p.
Détails du comportement :
- Lecture seule : le répertoire de seed n’est jamais écrit. Les mises à jour automatiques sont désactivées pour les places de marché de seed puisque git pull échouerait sur un système de fichiers en lecture seule.
- Les entrées de seed ont la priorité : les places de marché déclarées dans le seed remplacent toutes les entrées correspondantes dans la configuration de l’utilisateur à chaque démarrage. Pour refuser un plugin de seed, utilisez
/plugin disableplutôt que de supprimer la place de marché. - Résolution des chemins : Claude Code localise le contenu de la place de marché en sondant
$CLAUDE_CODE_PLUGIN_SEED_DIR/marketplaces/<name>/au moment de l’exécution, pas en faisant confiance aux chemins stockés dans le JSON du seed. Cela signifie que le seed fonctionne correctement même lorsqu’il est monté à un chemin différent de celui où il a été construit. - La mutation est bloquée : l’exécution de
/plugin marketplace removeou/plugin marketplace updatecontre une place de marché gérée par seed échoue avec des conseils pour demander à votre administrateur de mettre à jour l’image de seed. - Compose avec les paramètres : si
extraKnownMarketplacesouenabledPluginsdéclarent une place de marché qui existe déjà dans le seed, Claude Code utilise la copie du seed au lieu de cloner.
Restrictions des places de marché gérées
Pour les organisations nécessitant un contrôle strict sur les sources de plugins, les administrateurs peuvent restreindre les places de marché de plugins que les utilisateurs sont autorisés à ajouter en utilisant le paramètrestrictKnownMarketplaces dans les paramètres gérés. Pour également rejeter les drapeaux CLI qui chargent les plugins, les agents et les serveurs MCP pour une seule exécution, associez-le à disableSideloadFlags. Pour créer une liste blanche des places de marché dont les plugins peuvent apparaître comme suggestions d’installation contextuelle, définissez pluginSuggestionMarketplaces.
Lorsque strictKnownMarketplaces est configuré dans les paramètres gérés, le comportement de restriction dépend de la valeur :
Configurations courantes
Désactiver tous les ajouts de place de marché :".*" comme pathPattern pour autoriser n’importe quel chemin du système de fichiers tout en contrôlant les sources réseau avec hostPattern.
strictKnownMarketplaces restreint ce que les utilisateurs peuvent ajouter, mais n’enregistre pas les places de marché par lui-même. Pour rendre les places de marché autorisées disponibles automatiquement sans que les utilisateurs exécutent /plugin marketplace add, associez-le à extraKnownMarketplaces dans le même managed-settings.json. Voir Utiliser les deux ensemble.Comment fonctionnent les restrictions
Les restrictions sont vérifiées avant toute opération réseau ou système de fichiers. La vérification s’exécute lors de l’ajout de place de marché et lors de l’installation, la mise à jour, l’actualisation et la mise à jour automatique du plugin. Si une place de marché a été ajoutée avant la configuration de la politique et que sa source ne correspond plus à la liste d’autorisation, Claude Code refuse d’installer ou de mettre à jour les plugins à partir de celle-ci. L’application de la même restriction s’applique àblockedMarketplaces.
La liste d’autorisation utilise la correspondance exacte pour la plupart des types de sources. Pour qu’une place de marché soit autorisée, tous les champs spécifiés doivent correspondre exactement :
- Pour les sources GitHub :
repoest obligatoire, etrefoupathdoivent également correspondre s’ils sont spécifiés dans la liste d’autorisation - Pour les sources URL : l’URL complète doit correspondre exactement
- Pour les sources
hostPattern: l’hôte de la place de marché est comparé au motif regex - Pour les sources
pathPattern: le chemin du système de fichiers de la place de marché est comparé au motif regex
.git ou une forme ssh:// par rapport à https:// sont traités comme des valeurs différentes. Si la place de marché de votre organisation peut être clonée par plus d’une forme d’URL, préférez une entrée hostPattern à une URL littérale afin que toutes les formes correspondent.
Parce que strictKnownMarketplaces est défini dans les paramètres gérés, les configurations individuelles des utilisateurs et des projets ne peuvent pas contourner ces restrictions.
Pour les détails de configuration complets, y compris tous les types de sources pris en charge et la comparaison avec extraKnownMarketplaces, consultez la référence strictKnownMarketplaces.
Résolution des versions et canaux de publication
Les versions des plugins déterminent les chemins du cache et la détection des mises à jour : si la version résolue correspond à ce qu’un utilisateur possède déjà,/plugin update et la mise à jour automatique ignorent le plugin.
Claude Code résout la version d’un plugin à partir du premier de ces éléments qui est défini :
versiondans leplugin.jsondu pluginversiondans l’entrée de la place de marché du plugin- Le SHA du commit git de la source du plugin
github, url, git-subdir et les chemins relatifs à l’intérieur d’une place de marché hébergée sur git, vous pouvez omettre entièrement version et chaque nouveau commit est traité comme une nouvelle version. C’est la configuration la plus simple pour les plugins internes ou en développement actif.
Configurer les canaux de publication
Pour prendre en charge les canaux de publication « stable » et « latest » pour vos plugins, vous pouvez configurer deux places de marché qui pointent vers différentes refs ou SHAs du même dépôt. Vous pouvez ensuite assigner les deux places de marché à différents groupes d’utilisateurs via les paramètres gérés.latest-tools à la place :
Épingler les versions des dépendances
Un plugin peut contraindre ses dépendances à une plage semver afin que les mises à jour d’une dépendance ne cassent pas le plugin dépendant. Consultez Contraindre les versions des dépendances de plugins pour la convention de balise git{plugin-name}--v{version}, la syntaxe de plage et la façon dont plusieurs contraintes sur la même dépendance sont combinées.
Renommer ou supprimer un plugin
Lename d’un plugin est son identifiant stable. Les utilisateurs le référencent dans enabledPlugins, pluginConfigs et les commandes /plugin install, donc le changer casse chaque installation existante. Pour changer l’étiquette affichée dans l’interface utilisateur sans casser les installations, définissez displayName et gardez name inchangé.
Si vous devez changer le name d’un plugin, ou si vous supprimez un plugin du tableau plugins, ajoutez une entrée renames au niveau supérieur afin que les utilisateurs existants migrent au lieu de voir une erreur plugin-not-found. La migration automatique nécessite Claude Code v2.1.193 ou ultérieur. Mappez chaque ancien nom à son nouveau nom, ou à null si le plugin n’existe plus. L’exemple suivant renomme formatter en code-formatter et enregistre que legacy-linter a été supprimé :
renames :
- Si l’entrée pointe vers un nouveau nom, Claude Code charge le plugin sous son nouveau nom et affiche un avis d’une ligne tel que
Renamed to "code-formatter" in the "acme-tools" marketplace. Il réécrit ensuite l’ancienne clé vers la nouvelle clé dans les portées de paramètres utilisateur, projet et local pourenabledPluginsetpluginConfigs, afin que l’avis n’apparaisse qu’une fois. - Pour une entrée
null, Claude Code supprime l’ancienne clé et l’avis signale que le plugin a été supprimé de la place de marché. - Si le plugin renommé utilise une source distante telle que
githubounpm, Claude Code signaleplugin-cache-missaprès le renommage et l’utilisateur doit exécuter/plugin installune fois pour le récupérer sous le nouveau nom.
renames comme un historique d’ajout uniquement : gardez les anciennes entrées en place même après vous attendre à ce que chaque utilisateur ait migré. Claude Code suit les chaînes, donc si vous renommez ultérieurement code-formatter en formatter-pro, ajoutez une deuxième entrée plutôt que de modifier la première. Un utilisateur qui a toujours le formatter original activé se résout ensuite à travers les deux entrées vers formatter-pro.
Exécutez claude plugin validate . après avoir modifié la carte ; il rejette toute entrée dont la chaîne forme un cycle ou ne se termine pas à null ou à un nom listé dans plugins.
Les paramètres gérés et de politique sont en lecture seule pour Claude Code, donc les plugins activés là ne peuvent pas être réécrits automatiquement. Le plugin renommé se charge toujours à chaque session, mais l’avis de renommage se répète jusqu’à ce qu’un administrateur mette à jour
enabledPlugins dans le fichier de paramètres gérés pour utiliser le nouveau nom. La même chose s’applique aux plugins activés via d’autres sources en lecture seule telles que --add-dir.renames et signalent plugin-not-found pour l’ancien nom.
Validation et test
Testez votre place de marché avant de la partager. Validez la syntaxe JSON de votre place de marché :Gérer les places de marché à partir de la CLI
Claude Code fournit des sous-commandesclaude plugin marketplace non-interactives pour les scripts et l’automatisation. Elles sont équivalentes aux commandes /plugin marketplace disponibles dans une session interactive.
Plugin marketplace add
Ajoutez une place de marché à partir d’un dépôt GitHub, d’une URL git, d’une URL distante ou d’un chemin local.<source>: Raccourci GitHubowner/repo, URL git, URL distante vers un fichiermarketplace.jsonou chemin de répertoire local. Pour épingler à une branche ou un tag, ajoutez@refau raccourci GitHub ou#refà une URL git
gitlab.example.com/team/plugins, est rejeté comme un raccourci owner/repo invalide et l’erreur vous indique d’ajouter https:// ou d’utiliser ./ pour un chemin local. Les versions antérieures l’interprétaient mal comme un chemin de dépôt GitHub et échouent au moment du clonage avec une erreur GitHub non trouvé.
Options :
Ajoutez une place de marché à partir de GitHub en utilisant le raccourci
owner/repo :
@ref :
marketplace.json directement :
.claude/settings.json :
Plugin marketplace list
Listez toutes les places de marché configurées.
Avec
--json, chaque entrée inclut name, source et des champs spécifiques à la source : repo pour les sources GitHub, url pour les sources git et URL, et path pour les sources locales. Les sources GitHub et git incluent également un champ ref lorsque la place de marché a été ajoutée avec une branche ou un tag épinglé.
Plugin marketplace remove
Supprimez une place de marché configurée. L’aliasrm est également accepté.
<name>: nom de la place de marché à supprimer, comme indiqué parclaude plugin marketplace list. C’est lenamedemarketplace.json, pas la source que vous avez passée àadd
Plugin marketplace update
Actualisez les places de marché à partir de leurs sources pour récupérer les nouveaux plugins et les changements de version. Une place de marché ajoutée avec une branche ou un tagref se met à jour vers le dernier commit de cette ref, pas la branche par défaut du dépôt.
[name]: nom de la place de marché à mettre à jour, comme indiqué parclaude plugin marketplace list. Met à jour toutes les places de marché si omis
remove et update échouent lorsqu’ils sont exécutés contre une place de marché gérée par seed, qui est en lecture seule. Lors de la mise à jour de toutes les places de marché, les entrées gérées par seed sont ignorées et les autres places de marché se mettent toujours à jour. Pour modifier les plugins fournis par seed, demandez à votre administrateur de mettre à jour l’image de seed. Voir Pré-remplir les plugins pour les conteneurs.
Dépannage
La place de marché ne se charge pas
Symptômes : Impossible d’ajouter la place de marché ou de voir les plugins qu’elle contient Solutions :- Vérifiez que l’URL de la place de marché est accessible
- Vérifiez que
.claude-plugin/marketplace.jsonexiste au chemin spécifié - Assurez-vous que la syntaxe JSON est valide en utilisant
claude plugin validateou/plugin validate. Pour vérifier le frontmatter des compétences, agents et commandes, exécutez la commande sur chaque répertoire de plugin - Pour les dépôts privés, confirmez que vous avez les permissions d’accès
Erreurs de validation de la place de marché
Exécutezclaude plugin validate . ou /plugin validate . à partir de votre répertoire de place de marché pour vérifier les problèmes. Lorsqu’il est pointé sur un répertoire de place de marché, le validateur vérifie marketplace.json pour les erreurs de schéma, les noms de plugins en doublon et la traversée de chemin source. Pour chaque entrée dont la source est un chemin local, il valide également le plugin.json de ce plugin et avertit lorsque la version de l’entrée ne correspond pas à celle dans plugin.json. Les problèmes trouvés dans le plugin.json d’un plugin sont préfixés par l’index d’entrée, sous la forme plugins[2] plugin.json →.
À partir de Claude Code v2.1.196, la passe par entrée inclut également :
- les plugins dont la
sourceest. - s’exécute lorsque
marketplace.jsonest en dehors d’un répertoire.claude-plugin, en résolvant les sources par rapport au répertoire du fichier lui-même - signale les problèmes de chaque entrée même lorsqu’une autre partie du fichier a des erreurs de schéma
.claude-plugin/marketplace.json.
Pour valider le plugin.json d’un plugin individuel et ses fichiers de compétence, agent, commande et hook, exécutez la commande sur le répertoire du plugin lui-même, par exemple claude plugin validate ./plugins/my-plugin. Erreurs courantes :
Avertissements (non bloquants) :
Marketplace has no plugins defined: ajoutez au moins un plugin au tableaupluginsNo marketplace description provided: ajoutez unedescriptionau niveau supérieur pour aider les utilisateurs à comprendre votre place de marchéPlugin name "x" is not kebab-case: le nom du plugin contient des lettres majuscules, des espaces ou des caractères spéciaux. Renommez en minuscules, chiffres et tirets uniquement (par exemple,my-plugin). Claude Code accepte d’autres formes, mais la synchronisation de la place de marché Claude.ai les rejette.
Échecs d’installation de plugins
Symptômes : La place de marché apparaît mais l’installation du plugin échoue Solutions :- Vérifiez que les URL sources des plugins sont accessibles
- Vérifiez que les répertoires des plugins contiennent les fichiers requis
- Pour les sources GitHub, assurez-vous que les dépôts sont publics ou que vous avez accès
- Testez manuellement les sources de plugins en les clonant/téléchargeant
- Si la source épingle à la fois
refetsha, une branche ou un tag en amont supprimé ne bloque pas l’installation sur la plupart des hôtes git, y compris GitHub, GitLab et Bitbucket. Sur les serveurs qui ne supportent pas la récupération des commits par SHA, comme AWS CodeCommit, lerefdoit toujours exister et le commit épinglé doit être accessible à partir de celui-ci. Si l’installation échoue toujours, confirmez que le commit épinglé existe toujours dans le dépôt
L’authentification du dépôt privé échoue
Symptômes : Erreurs d’authentification lors de l’installation de plugins à partir de dépôts privés Solutions : Pour l’installation manuelle et les mises à jour :- Vérifiez que vous êtes authentifié auprès de votre fournisseur git (par exemple, exécutez
gh auth statuspour GitHub) - Vérifiez que votre assistant de credentials est configuré correctement :
git config --global credential.helper - Essayez de cloner le dépôt manuellement pour vérifier que vos credentials fonctionnent
- Par défaut, les actualisations en arrière-plan désactivent les assistants de credentials git pour la récupération, de sorte que la récupération ne peut pas s’authentifier via HTTPS. Les dépôts SSH avec une clé chargée dans
ssh-agents’authentifient toujours. Un échec de récupération déclenche un re-clonage à partir de zéro, qui utilise vos credentials stockés mais peut expirer sur les grands dépôts - Définissez
CLAUDE_CODE_PLUGIN_KEEP_MARKETPLACE_ON_FAILURE=1pour conserver le clone existant lorsque la récupération en arrière-plan échoue - Configurez un assistant de credentials git, par exemple
gh auth setup-git, de sorte que le re-clonage de secours puisse s’authentifier - Si le re-clonage expire sur un grand dépôt, augmentez la limite avec
CLAUDE_CODE_PLUGIN_GIT_TIMEOUT_MS - Configurez une réécriture d’URL git limitée au dépôt de la place de marché de sorte que la récupération en arrière-plan s’authentifie directement
- Ou mettez à jour les places de marché privées manuellement avec
/plugin marketplace update <name>, qui utilise vos credentials
Les mises à jour de la place de marché échouent dans les environnements hors ligne
Symptômes : Legit pull de la place de marché échoue en arrière-plan et Claude Code tente à plusieurs reprises un re-clonage qui ne peut pas réussir.
Cause : Par défaut, lorsqu’un git pull échoue, Claude Code tente un re-clonage à partir de zéro. Dans les environnements hors ligne ou isolés, le re-clonage échoue de la même manière, et la restauration du cache précédent après est au mieux un effort. L’actualisation s’exécute en arrière-plan après le démarrage, de sorte qu’elle ne retarde pas le démarrage, mais chaque session répète les tentatives échouées et chaque opération git peut attendre le délai d’expiration de 120 secondes.
Solution : Définissez CLAUDE_CODE_PLUGIN_KEEP_MARKETPLACE_ON_FAILURE=1 pour ignorer la tentative de re-clonage et continuer à utiliser le cache existant lorsque la récupération échoue :
git pull et continue d’utiliser le dernier état connu bon. Pour les déploiements entièrement hors ligne où le dépôt ne sera jamais accessible, utilisez CLAUDE_CODE_PLUGIN_SEED_DIR pour pré-remplir le répertoire des plugins au moment de la construction à la place.
Les opérations Git expirent
Symptômes : L’installation du plugin ou les mises à jour de la place de marché échouent avec une erreur de délai d’expiration comme « Git clone timed out after 120s » ou « Git pull timed out after 120s ». Cause : Claude Code utilise un délai d’expiration de 120 secondes pour toutes les opérations git, y compris le clonage des dépôts de plugins et l’extraction des mises à jour de la place de marché. Les grands dépôts ou les connexions réseau lentes peuvent dépasser cette limite. Solution : Augmentez le délai d’expiration en utilisant la variable d’environnementCLAUDE_CODE_PLUGIN_GIT_TIMEOUT_MS. La valeur est en millisecondes :
Les plugins avec chemins relatifs échouent dans les places de marché basées sur les URL
Symptômes : Vous avez ajouté une place de marché via URL (commehttps://example.com/marketplace.json), mais les plugins avec des sources de chemin relatif comme "./plugins/my-plugin" échouent à installer avec des erreurs « path not found ».
Cause : Les places de marché basées sur les URL téléchargent uniquement le fichier marketplace.json lui-même. Elles ne téléchargent pas les fichiers de plugins du serveur. Les chemins relatifs dans l’entrée de la place de marché référencent des fichiers sur le serveur distant qui n’ont pas été téléchargés.
Solutions :
- Utiliser des sources externes : Changez les entrées de plugins pour utiliser les sources GitHub, npm ou URL git au lieu des chemins relatifs :
- Utiliser une place de marché basée sur Git : Hébergez votre place de marché dans un dépôt Git et ajoutez-la avec l’URL git. Les places de marché basées sur Git clonent le dépôt entier, ce qui rend les chemins relatifs fonctionnels.
Fichiers non trouvés après l’installation
Symptômes : Le plugin s’installe mais les références aux fichiers échouent, en particulier les fichiers en dehors du répertoire du plugin Cause : Les plugins sont copiés vers un répertoire de cache plutôt que d’être utilisés sur place. Les chemins qui référencent des fichiers en dehors du répertoire du plugin (comme../shared-utils) ne fonctionneront pas car ces fichiers ne sont pas copiés.
Solutions : Consultez Plugin caching and file resolution pour les solutions de contournement, y compris les symlinks et la restructuration des répertoires.
Pour des outils de débogage supplémentaires et des problèmes courants, consultez Debugging and development tools.
Voir aussi
- Découvrir et installer des plugins préconfigurés - Installation de plugins à partir de places de marché existantes
- Plugins - Création de vos propres plugins
- Référence des plugins - Spécifications techniques complètes et schémas
- Paramètres des plugins - Options de configuration des plugins
- Référence strictKnownMarketplaces - Restrictions des places de marché gérées