Passer au contenu principal
Une place de marché de plugins est un catalogue qui vous permet de distribuer des plugins à d’autres. Les places de marché offrent une découverte centralisée, un suivi des versions, des mises à jour automatiques et la prise en charge de plusieurs types de sources (dépôts git, chemins locaux, etc.). Ce guide vous montre comment créer votre propre place de marché pour partager des plugins avec votre équipe ou votre communauté. Vous cherchez à installer des plugins à partir d’une place de marché existante ? Consultez Découvrir et installer des plugins préconfigurés.

Aperçu

La création et la distribution d’une place de marché impliquent :
  1. 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.
  2. Créer un fichier de place de marché : définissez un marketplace.json qui répertorie vos plugins et où les trouver (voir Créer le fichier de place de marché).
  3. 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é).
  4. Partager avec les utilisateurs : les utilisateurs ajoutent votre place de marché avec /plugin marketplace add et installent des plugins individuels (voir Découvrir et installer des plugins).
Une fois votre place de marché en ligne, vous pouvez la mettre à jour en poussant les modifications vers votre dépôt. Les utilisateurs actualisent leur copie locale avec /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étence /quality-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

mkdir -p my-marketplace/.claude-plugin
mkdir -p my-marketplace/plugins/quality-review-plugin/.claude-plugin
mkdir -p my-marketplace/plugins/quality-review-plugin/skills/quality-review
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
---
description: Review code for bugs, security, and performance
disable-model-invocation: true
---

Review the code I've selected or the recent changes for:
- Potential bugs or edge cases
- Security concerns
- Performance issues
- Readability improvements

Be concise and actionable.
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
{
  "name": "quality-review-plugin",
  "description": "Adds a /quality-review skill for quick code reviews",
  "version": "1.0.0"
}
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 Version resolution 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
{
  "name": "my-plugins",
  "owner": {
    "name": "Your Name"
  },
  "plugins": [
    {
      "name": "quality-review-plugin",
      "source": "./plugins/quality-review-plugin",
      "description": "Adds a /quality-review skill for quick code reviews"
    }
  ]
}
5

Ajouter et installer

Ajoutez la place de marché et installez le plugin.
/plugin marketplace add ./my-marketplace
/plugin install quality-review-plugin@my-plugins
6

Essayer

Sélectionnez du code dans votre éditeur et exécutez votre nouvelle compétence.
/quality-review
Pour en savoir plus sur ce que les plugins peuvent faire, notamment les hooks, les agents, les serveurs MCP et les serveurs LSP, consultez Plugins.
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 (où la récupérer). Consultez le schéma complet ci-dessous pour tous les champs disponibles.
{
  "name": "company-tools",
  "owner": {
    "name": "DevTools Team",
    "email": "devtools@example.com"
  },
  "plugins": [
    {
      "name": "code-formatter",
      "source": "./plugins/formatter",
      "description": "Automatic code formatting on save",
      "version": "2.1.0",
      "author": {
        "name": "DevTools Team"
      }
    },
    {
      "name": "deployment-tools",
      "source": {
        "source": "github",
        "repo": "company/deploy-plugin"
      },
      "description": "Deployment automation tools"
    }
  ]
}

Schéma de la place de marché

Champs obligatoires

ChampTypeDescriptionExemple
namestringIdentifiant de la place de marché (kebab-case, sans espaces). C’est un élément public : les utilisateurs le voient lors de l’installation de plugins (par exemple, /plugin install my-tool@your-marketplace)."acme-tools"
ownerobjectInformations du responsable de la place de marché (voir les champs ci-dessous)
pluginsarrayListe des plugins disponiblesVoir ci-dessous
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, anthropic-marketplace, anthropic-plugins, agent-skills, knowledge-work-plugins, life-sciences. Les noms qui usurpent l’identité de places de marché officielles (comme official-claude-plugins ou anthropic-tools-v2) sont également bloqués.

Champs du propriétaire

ChampTypeObligatoireDescription
namestringOuiNom du responsable ou de l’équipe
emailstringNonAdresse e-mail de contact du responsable

Champs optionnels

ChampTypeDescription
metadata.descriptionstringBrève description de la place de marché
metadata.versionstringVersion de la place de marché
metadata.pluginRootstringRépertoire de base ajouté aux chemins de source de plugin relatifs (par exemple, "./plugins" vous permet d’écrire "source": "formatter" au lieu de "source": "./plugins/formatter")
allowCrossMarketplaceDependenciesOnarrayAutres places de marché sur lesquelles les plugins de cette place de marché peuvent dépendre. Les dépendances d’une place de marché non listée ici sont bloquées à l’installation. Voir Dépendre d’un plugin d’une autre place de marché.

Entrées de plugin

Chaque entrée de plugin dans le tableau plugins décrit un plugin et où le trouver. Vous pouvez inclure n’importe quel champ du schéma du manifeste du plugin (comme description, version, author, commands, hooks, etc.), plus ces champs spécifiques à la place de marché : source, category, tags et strict.

Champs obligatoires

ChampTypeDescription
namestringIdentifiant du plugin (kebab-case, sans espaces). C’est un élément public : les utilisateurs le voient lors de l’installation (par exemple, /plugin install my-plugin@marketplace).
sourcestring|objectOù récupérer le plugin (voir Sources de plugin ci-dessous)

Champs de plugin optionnels

Champs de métadonnées standard :
ChampTypeDescription
descriptionstringBrève description du plugin
versionstringVersion du plugin. Si défini (ici ou dans plugin.json), le plugin est épinglé à cette chaîne et les utilisateurs ne reçoivent des mises à jour que lorsqu’elle change. Omettez pour revenir au SHA du commit git. Voir Résolution de version.
authorobjectInformations sur l’auteur du plugin (name obligatoire, email optionnel)
homepagestringURL de la page d’accueil ou de la documentation du plugin
repositorystringURL du dépôt du code source
licensestringIdentifiant de licence SPDX (par exemple, MIT, Apache-2.0)
keywordsarrayBalises pour la découverte et la catégorisation des plugins
categorystringCatégorie du plugin pour l’organisation
tagsarrayBalises pour la recherche
strictbooleanContrôle si plugin.json est l’autorité pour les définitions de composants (par défaut : true). Voir Mode strict ci-dessous.
Champs de configuration des composants :
ChampTypeDescription
skillsstring|arrayChemins personnalisés vers les répertoires de compétences contenant <name>/SKILL.md
commandsstring|arrayChemins personnalisés vers les fichiers de compétences .md plats ou les répertoires
agentsstring|arrayChemins personnalisés vers les fichiers d’agents
hooksstring|objectConfiguration personnalisée des hooks ou chemin vers le fichier des hooks
mcpServersstring|objectConfigurations du serveur MCP ou chemin vers la configuration MCP
lspServersstring|objectConfigurations du serveur LSP ou chemin vers la configuration LSP

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 champ source de chaque entrée de plugin dans marketplace.json. Une fois qu’un plugin est cloné ou copié sur la machine locale, il est copié dans le cache de plugin local versionné à ~/.claude/plugins/cache.
SourceTypeChampsNotes
Chemin relatifstring (par exemple "./my-plugin")Répertoire local dans le dépôt de la place de marché. Doit commencer par ./. Résolu par rapport à la racine de la place de marché, pas au répertoire .claude-plugin/
githubobjectrepo, ref?, sha?
urlobjecturl, ref?, sha?Source d’URL Git
git-subdirobjecturl, path, ref?, sha?Sous-répertoire dans un dépôt git. Clone partiellement pour minimiser la bande passante pour les monodépôts
npmobjectpackage, version?, registry?Installé via npm install
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.json lui-même. Défini lorsque les utilisateurs exécutent /plugin marketplace add ou dans les paramètres extraKnownMarketplaces. Prend en charge ref (branche/tag) mais pas sha.
  • Source de plugin — où récupérer un plugin individuel répertorié dans la place de marché. Défini dans le champ source de chaque entrée de plugin dans marketplace.json. Prend en charge à la fois ref (branche/tag) et sha (commit exact).
Par exemple, une place de marché hébergée à 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.

Chemins relatifs

Pour les plugins dans le même dépôt, utilisez un chemin commençant par ./ :
{
  "name": "my-plugin",
  "source": "./plugins/my-plugin"
}
Les chemins se résolvent par rapport à la racine de la place de marché, qui est le répertoire contenant .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 ne fonctionnent que lorsque les utilisateurs ajoutent votre place de marché via Git (GitHub, GitLab ou URL git). 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 correctement. 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

{
  "name": "github-plugin",
  "source": {
    "source": "github",
    "repo": "owner/plugin-repo"
  }
}
Vous pouvez épingler à une branche, un tag ou un commit spécifique :
{
  "name": "github-plugin",
  "source": {
    "source": "github",
    "repo": "owner/plugin-repo",
    "ref": "v2.0.0",
    "sha": "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0"
  }
}
ChampTypeDescription
repostringObligatoire. Dépôt GitHub au format owner/repo
refstringOptionnel. Branche ou tag Git (par défaut la branche par défaut du dépôt)
shastringOptionnel. SHA de commit git complet de 40 caractères pour épingler à une version exacte

Dépôts Git

{
  "name": "git-plugin",
  "source": {
    "source": "url",
    "url": "https://gitlab.com/team/plugin.git"
  }
}
Vous pouvez épingler à une branche, un tag ou un commit spécifique :
{
  "name": "git-plugin",
  "source": {
    "source": "url",
    "url": "https://gitlab.com/team/plugin.git",
    "ref": "main",
    "sha": "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0"
  }
}
ChampTypeDescription
urlstringObligatoire. URL complète du dépôt git (https:// ou git@). Le suffixe .git est optionnel, donc les URL Azure DevOps et AWS CodeCommit sans le suffixe fonctionnent
refstringOptionnel. Branche ou tag Git (par défaut la branche par défaut du dépôt)
shastringOptionnel. SHA de commit git complet de 40 caractères pour épingler à une version exacte

Sous-répertoires Git

Utilisez git-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.
{
  "name": "my-plugin",
  "source": {
    "source": "git-subdir",
    "url": "https://github.com/acme-corp/monorepo.git",
    "path": "tools/claude-plugin"
  }
}
Vous pouvez épingler à une branche, un tag ou un commit spécifique :
{
  "name": "my-plugin",
  "source": {
    "source": "git-subdir",
    "url": "https://github.com/acme-corp/monorepo.git",
    "path": "tools/claude-plugin",
    "ref": "v2.0.0",
    "sha": "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0"
  }
}
Le champ url accepte également un raccourci GitHub (owner/repo) ou des URL SSH (git@github.com:owner/repo.git).
ChampTypeDescription
urlstringObligatoire. URL du dépôt Git, raccourci GitHub owner/repo ou URL SSH
pathstringObligatoire. Chemin du sous-répertoire dans le dépôt contenant le plugin (par exemple, "tools/claude-plugin")
refstringOptionnel. Branche ou tag Git (par défaut la branche par défaut du dépôt)
shastringOptionnel. SHA de commit git complet de 40 caractères pour épingler à une version exacte

Paquets npm

Les plugins distribués en tant que paquets npm sont installés à l’aide de npm install. Cela fonctionne avec n’importe quel paquet du registre npm public ou d’un registre privé que votre équipe héberge.
{
  "name": "my-npm-plugin",
  "source": {
    "source": "npm",
    "package": "@acme/claude-plugin"
  }
}
Pour épingler à une version spécifique, ajoutez le champ version :
{
  "name": "my-npm-plugin",
  "source": {
    "source": "npm",
    "package": "@acme/claude-plugin",
    "version": "2.1.0"
  }
}
Pour installer à partir d’un registre privé ou interne, ajoutez le champ registry :
{
  "name": "my-npm-plugin",
  "source": {
    "source": "npm",
    "package": "@acme/claude-plugin",
    "version": "^2.0.0",
    "registry": "https://npm.example.com"
  }
}
ChampTypeDescription
packagestringObligatoire. Nom du paquet ou paquet scopé (par exemple, @org/plugin)
versionstringOptionnel. Version ou plage de version (par exemple, 2.1.0, ^2.0.0, ~1.5.0)
registrystringOptionnel. URL du registre npm personnalisé. Par défaut le registre npm du système (généralement npmjs.org)

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 :
{
  "name": "enterprise-tools",
  "source": {
    "source": "github",
    "repo": "company/enterprise-plugin"
  },
  "description": "Enterprise workflow automation tools",
  "version": "2.1.0",
  "author": {
    "name": "Enterprise Team",
    "email": "enterprise@example.com"
  },
  "homepage": "https://docs.example.com/plugins/enterprise-tools",
  "repository": "https://github.com/company/enterprise-plugin",
  "license": "MIT",
  "keywords": ["enterprise", "workflow", "automation"],
  "category": "productivity",
  "commands": [
    "./commands/core/",
    "./commands/enterprise/",
    "./commands/experimental/preview.md"
  ],
  "agents": ["./agents/security-reviewer.md", "./agents/compliance-checker.md"],
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PLUGIN_ROOT}/scripts/validate.sh"
          }
        ]
      }
    ]
  },
  "mcpServers": {
    "enterprise-db": {
      "command": "${CLAUDE_PLUGIN_ROOT}/servers/db-server",
      "args": ["--config", "${CLAUDE_PLUGIN_ROOT}/config.json"]
    }
  },
  "strict": false
}
Points clés à noter :
  • commands et agents : 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 hooks 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. 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 propre plugin.json. L’entrée de la place de marché définit tout. Voir Mode strict ci-dessous.

Mode strict

Le champ strict contrôle si plugin.json est l’autorité pour les définitions de composants (compétences, agents, hooks, serveurs MCP, styles de sortie).
ValeurComportement
true (par défaut)plugin.json est l’autorité. L’entrée de la place de marché peut la compléter avec des composants supplémentaires, et les deux sources sont fusionnées.
falseL’entrée de la place de marché est la définition complète. Si le plugin a également un plugin.json qui déclare des composants, c’est un conflit et le plugin ne se charge pas.
Quand utiliser chaque mode :
  • strict: true : le plugin a son propre plugin.json et 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 offre la méthode de distribution la plus facile :
  1. Créer un dépôt : Configurez un nouveau dépôt pour votre place de marché
  2. Ajouter le fichier de place de marché : Créez .claude-plugin/marketplace.json avec vos définitions de plugins
  3. Partager avec les équipes : Les utilisateurs ajoutent votre place de marché avec /plugin marketplace add owner/repo
Avantages : Contrôle de version intégré, suivi des problèmes et fonctionnalités de collaboration d’équipe.

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 :
/plugin marketplace add https://gitlab.com/company/plugins.git

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 via gh 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 mises à jour automatiques en arrière-plan s’exécutent au démarrage sans assistants de credentials, car les invites interactives bloqueraient le démarrage de Claude Code. Pour activer les mises à jour automatiques pour les places de marché privées, définissez le jeton d’authentification approprié dans votre environnement :
FournisseurVariables d’environnementNotes
GitHubGITHUB_TOKEN ou GH_TOKENJeton d’accès personnel ou jeton GitHub App
GitLabGITLAB_TOKEN ou GL_TOKENJeton d’accès personnel ou jeton de projet
BitbucketBITBUCKET_TOKENMot de passe d’application ou jeton d’accès au dépôt
Définissez le jeton dans votre configuration de shell (par exemple, .bashrc, .zshrc) ou passez-le lors de l’exécution de Claude Code :
export GITHUB_TOKEN=ghp_xxxxxxxxxxxxxxxxxxxx
Pour les environnements CI/CD, configurez le jeton en tant que variable d’environnement secrète. GitHub Actions fournit automatiquement GITHUB_TOKEN pour les dépôts de la même organisation.

Tester localement avant la distribution

Testez votre place de marché localement avant de la partager :
/plugin marketplace add ./my-local-marketplace
/plugin install test-plugin@my-local-marketplace
Pour la gamme complète de commandes add (GitHub, URL Git, chemins locaux, URL distantes), consultez Ajouter des places de marché.

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 :
{
  "extraKnownMarketplaces": {
    "company-tools": {
      "source": {
        "source": "github",
        "repo": "your-org/claude-plugins"
      }
    }
  }
}
Vous pouvez également spécifier quels plugins doivent être activés par défaut :
{
  "enabledPlugins": {
    "code-formatter@company-tools": true,
    "deployment-tools@company-tools": true
  }
}
Pour les options de configuration complètes, consultez Paramètres des plugins.
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’environnement CLAUDE_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 le premier seed qui contient une place de marché ou un cache de plugin donné gagne. Le répertoire de seed reflète la structure de ~/.claude/plugins :
$CLAUDE_CODE_PLUGIN_SEED_DIR/
  known_marketplaces.json
  marketplaces/<name>/...
  cache/<marketplace>/<plugin>/<version>/...
Pour construire un répertoire de seed, exécutez Claude Code une fois lors de la construction de l’image, installez les plugins dont vous avez besoin, puis copiez le répertoire ~/.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_CACHE_DIR=/opt/claude-seed claude plugin marketplace add your-org/plugins
CLAUDE_CODE_PLUGIN_CACHE_DIR=/opt/claude-seed claude plugin install my-tool@your-plugins
Ensuite, définissez 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 disable plutô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 remove ou /plugin marketplace update contre 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 extraKnownMarketplaces ou enabledPlugins dé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ètre strictKnownMarketplaces dans les paramètres gérés. Lorsque strictKnownMarketplaces est configuré dans les paramètres gérés, le comportement de restriction dépend de la valeur :
ValeurComportement
Non défini (par défaut)Aucune restriction. Les utilisateurs peuvent ajouter n’importe quelle place de marché
Tableau vide []Verrouillage complet. Les utilisateurs ne peuvent pas ajouter de nouvelles places de marché
Liste de sourcesLes utilisateurs ne peuvent ajouter que les places de marché qui correspondent exactement à la liste d’autorisation

Configurations courantes

Désactiver tous les ajouts de place de marché :
{
  "strictKnownMarketplaces": []
}
Autoriser uniquement les places de marché spécifiques :
{
  "strictKnownMarketplaces": [
    {
      "source": "github",
      "repo": "acme-corp/approved-plugins"
    },
    {
      "source": "github",
      "repo": "acme-corp/security-tools",
      "ref": "v2.0"
    },
    {
      "source": "url",
      "url": "https://plugins.example.com/marketplace.json"
    }
  ]
}
Autoriser toutes les places de marché d’un serveur git interne en utilisant la correspondance de motif regex sur l’hôte. C’est l’approche recommandée pour GitHub Enterprise Server ou les instances GitLab auto-hébergées :
{
  "strictKnownMarketplaces": [
    {
      "source": "hostPattern",
      "hostPattern": "^github\\.example\\.com$"
    }
  ]
}
Autoriser les places de marché basées sur le système de fichiers à partir d’un répertoire spécifique en utilisant la correspondance de motif regex sur le chemin :
{
  "strictKnownMarketplaces": [
    {
      "source": "pathPattern",
      "pathPattern": "^/opt/approved/"
    }
  ]
}
Utilisez ".*" 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 : repo est obligatoire, et ref ou path doivent é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
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 :
  1. version dans le plugin.json du plugin
  2. version dans l’entrée de la place de marché du plugin
  3. Le SHA du commit git de la source du plugin
Pour les types de sources basés sur git 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.
Définir version épingle le plugin. Si plugin.json déclare "version": "1.0.0", pousser de nouveaux commits sans changer cette chaîne ne fait rien pour les utilisateurs existants, car Claude Code voit la même version et conserve la copie en cache. Augmentez le champ à chaque publication, ou omettez-le pour utiliser le SHA du commit.Évitez de définir version à la fois dans plugin.json et dans l’entrée de la place de marché. La valeur plugin.json gagne toujours silencieusement, donc une version de manifeste obsolète peut masquer une version que vous avez définie dans marketplace.json.

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.
Chaque canal doit se résoudre en une version différente. Si vous utilisez des versions explicites, plugin.json doit déclarer une version différente à chaque ref ou SHA épinglé. Si vous omettez version, les SHAs de commit distincts distinguent déjà les canaux. Si deux refs se résolvent en la même chaîne de version, Claude Code les traite comme identiques et ignore la mise à jour.
Exemple
{
  "name": "stable-tools",
  "plugins": [
    {
      "name": "code-formatter",
      "source": {
        "source": "github",
        "repo": "acme-corp/code-formatter",
        "ref": "stable"
      }
    }
  ]
}
{
  "name": "latest-tools",
  "plugins": [
    {
      "name": "code-formatter",
      "source": {
        "source": "github",
        "repo": "acme-corp/code-formatter",
        "ref": "latest"
      }
    }
  ]
}
Assigner les canaux aux groupes d’utilisateurs
Assignez chaque place de marché au groupe d’utilisateurs approprié via les paramètres gérés. Par exemple, le groupe stable reçoit :
{
  "extraKnownMarketplaces": {
    "stable-tools": {
      "source": {
        "source": "github",
        "repo": "acme-corp/stable-tools"
      }
    }
  }
}
Le groupe early-access reçoit latest-tools à la place :
{
  "extraKnownMarketplaces": {
    "latest-tools": {
      "source": {
        "source": "github",
        "repo": "acme-corp/latest-tools"
      }
    }
  }
}

É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.

Validation et test

Testez votre place de marché avant de la partager. Validez la syntaxe JSON de votre place de marché :
claude plugin validate .
Ou depuis Claude Code :
/plugin validate .
Ajoutez la place de marché pour le test :
/plugin marketplace add ./path/to/marketplace
Installez un plugin de test pour vérifier que tout fonctionne :
/plugin install test-plugin@marketplace-name
Pour les flux de travail complets de test de plugins, consultez Tester vos plugins localement. Pour le dépannage technique, consultez Référence des plugins.

Gérer les places de marché à partir de la CLI

Claude Code fournit des sous-commandes claude 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.
claude plugin marketplace add <source> [options]
Arguments :
  • <source> : Raccourci GitHub owner/repo, URL git, URL distante vers un fichier marketplace.json ou chemin de répertoire local. Pour épingler à une branche ou un tag, ajoutez @ref au raccourci GitHub ou #ref à une URL git
Options :
OptionDescriptionPar défaut
--scope <scope>Où déclarer la place de marché : user, project ou local. Voir Portées d’installation des pluginsuser
--sparse <paths...>Limiter le checkout à des répertoires spécifiques via git sparse-checkout. Utile pour les monodépôts
Ajoutez une place de marché à partir de GitHub en utilisant le raccourci owner/repo :
claude plugin marketplace add acme-corp/claude-plugins
Épinglez à une branche ou un tag spécifique avec @ref :
claude plugin marketplace add acme-corp/claude-plugins@v2.0
Ajoutez à partir d’une URL git sur un hôte non-GitHub :
claude plugin marketplace add https://gitlab.example.com/team/plugins.git
Ajoutez à partir d’une URL distante qui sert le fichier marketplace.json directement :
claude plugin marketplace add https://example.com/marketplace.json
Ajoutez à partir d’un répertoire local pour le test :
claude plugin marketplace add ./my-marketplace
Déclarez la place de marché à la portée du projet afin qu’elle soit partagée avec votre équipe via .claude/settings.json :
claude plugin marketplace add acme-corp/claude-plugins --scope project
Pour un monodépôt, limitez le checkout aux répertoires qui contiennent le contenu du plugin :
claude plugin marketplace add acme-corp/monorepo --sparse .claude-plugin plugins

Plugin marketplace list

Listez toutes les places de marché configurées.
claude plugin marketplace list [options]
Options :
OptionDescription
--jsonSortie en JSON

Plugin marketplace remove

Supprimez une place de marché configurée. L’alias rm est également accepté.
claude plugin marketplace remove <name>
Arguments :
  • <name> : nom de la place de marché à supprimer, comme indiqué par claude plugin marketplace list. C’est le name de marketplace.json, pas la source que vous avez passée à add
La suppression d’une place de marché désinstalle également tous les plugins que vous avez installés à partir de celle-ci. Pour actualiser une place de marché sans perdre les plugins installés, utilisez claude plugin marketplace update à la place.

Plugin marketplace update

Actualisez les places de marché à partir de leurs sources pour récupérer les nouveaux plugins et les changements de version.
claude plugin marketplace update [name]
Arguments :
  • [name] : nom de la place de marché à mettre à jour, comme indiqué par claude plugin marketplace list. Met à jour toutes les places de marché si omis
À la fois 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.json existe au chemin spécifié
  • Assurez-vous que la syntaxe JSON est valide et que le frontmatter est bien formé en utilisant claude plugin validate ou /plugin validate
  • 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écutez claude plugin validate . ou /plugin validate . à partir de votre répertoire de place de marché pour vérifier les problèmes. Le validateur vérifie plugin.json, le frontmatter des compétences/agents/commandes et hooks/hooks.json pour les erreurs de syntaxe et de schéma. Erreurs courantes :
ErreurCauseSolution
File not found: .claude-plugin/marketplace.jsonManifeste manquantCréez .claude-plugin/marketplace.json avec les champs obligatoires
Invalid JSON syntax: Unexpected token...Erreur de syntaxe JSON dans marketplace.jsonVérifiez les virgules manquantes, les virgules supplémentaires ou les chaînes non citées
Duplicate plugin name "x" found in marketplaceDeux plugins partagent le même nomDonnez à chaque plugin une valeur name unique
plugins[0].source: Path contains ".."Le chemin source contient ..Utilisez des chemins relatifs à la racine de la place de marché sans ... Voir Chemins relatifs
YAML frontmatter failed to parse: ...YAML invalide dans un fichier de compétence, d’agent ou de commandeCorrigez la syntaxe YAML dans le bloc frontmatter. À l’exécution, ce fichier se charge sans métadonnées.
Invalid JSON syntax: ... (hooks.json)hooks/hooks.json mal forméCorrigez la syntaxe JSON. Un hooks/hooks.json mal formé empêche le chargement du plugin entier.
Avertissements (non bloquants) :
  • Marketplace has no plugins defined : ajoutez au moins un plugin au tableau plugins
  • No marketplace description provided : ajoutez metadata.description 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

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 status pour 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
Pour les mises à jour automatiques en arrière-plan :
  • Définissez le jeton approprié dans votre environnement : echo $GITHUB_TOKEN
  • Vérifiez que le jeton a les permissions requises (accès en lecture au dépôt)
  • Pour GitHub, assurez-vous que le jeton a la portée repo pour les dépôts privés
  • Pour GitLab, assurez-vous que le jeton a au moins la portée read_repository
  • Vérifiez que le jeton n’a pas expiré

Les mises à jour de la place de marché échouent dans les environnements hors ligne

Symptômes : Le git pull de la place de marché échoue et Claude Code efface le cache existant, rendant les plugins indisponibles. Cause : Par défaut, lorsqu’un git pull échoue, Claude Code supprime le clone obsolète et tente de re-cloner. Dans les environnements hors ligne ou isolés, le re-clonage échoue de la même manière, laissant le répertoire de la place de marché vide. Solution : Définissez CLAUDE_CODE_PLUGIN_KEEP_MARKETPLACE_ON_FAILURE=1 pour conserver le cache existant lorsque le pull échoue au lieu de l’effacer :
export CLAUDE_CODE_PLUGIN_KEEP_MARKETPLACE_ON_FAILURE=1
Avec cette variable définie, Claude Code conserve le clone obsolète de la place de marché en cas d’échec de 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’environnement CLAUDE_CODE_PLUGIN_GIT_TIMEOUT_MS. La valeur est en millisecondes :
export CLAUDE_CODE_PLUGIN_GIT_TIMEOUT_MS=300000  # 5 minutes

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 (comme https://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 :
    { "name": "my-plugin", "source": { "source": "github", "repo": "owner/repo" } }
    
  • 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