Gérer les plugins Claude Code pour votre organisation
Contrôlez les plugins que Claude Code installe et autorise sur chaque machine de votre organisation via des paramètres gérés.
Les paramètres gérés vous permettent de décider quels plugins Claude Code installe et autorise sur chaque machine de votre organisation. Les utilisateurs ne peuvent pas les remplacer. Vous les livrez soit sous forme de paramètres gérés par le serveur depuis la console d'administration claude.ai, soit sous forme de paramètres gérés par le point de terminaison via MDM ou un fichier managed-settings.json. La plupart des contrôles de cette page ne prennent effet que depuis les paramètres gérés.
Cette page est destinée aux administrateurs et les paramètres ici gouvernent Claude Code.
Ces cas sont couverts sur d'autres pages :
- Installation de plugins pour vous-même : commencez par Installer des plugins
- Contrôler les plugins que les membres peuvent utiliser dans claude.ai et Cowork : voir Gérer les plugins pour votre organisation dans le centre d'aide
- La page des plugins dans les paramètres d'administration de claude.ai : Paramètres de l'organisation > Plugins et compétences active les plugins pour les comptes claude.ai des membres, et ceux-ci atteignent Claude Code sous forme de plugins synchronisés. Il ne définit aucune des clés de cette page
Les sections suivent l'ordre que prennent la plupart des déploiements : exiger des plugins pour tout le monde ou par référentiel, ensemencer les conteneurs et l'IC, restreindre ce que les utilisateurs peuvent ajouter eux-mêmes, définir la politique de mise à jour, puis auditer ce qui est installé. Pour examiner chaque clé de politique en un seul endroit, voir la matrice de contrôle.
Pré-installer et exiger des plugins
Un marketplace est un catalogue de plugins que Claude Code récupère à partir d'un référentiel git, d'une URL ou d'un chemin local. Une fois que vous enregistrez un marketplace sur une machine, Claude Code peut installer des plugins à partir de celui-ci.
Pour installer des plugins pour une flotte, définissez deux clés ensemble dans les paramètres gérés, le fichier de politique ou la politique livrée par le serveur que chaque machine de votre organisation lit : extraKnownMarketplaces enregistre un marketplace sur chaque machine, et enabledPlugins nomme les plugins à installer et activer à partir de celui-ci. Choisir un mécanisme de livraison couvre comment les paramètres gérés atteignent chaque machine.
Choisir un mécanisme de livraison
Les paramètres gérés atteignent une machine via l'un de trois mécanismes de livraison :
- Paramètres gérés par le serveur : définissez les clés de plugin en JSON à Paramètres de l'organisation > Claude Code > Paramètres gérés. Nécessite un rôle Propriétaire dans votre organisation Claude. Une session cloud récupère ces paramètres avant d'installer les plugins.
- Politiques MDM : sur macOS, livrez un plist dont les clés de niveau supérieur sont les clés de paramètres. Sur Windows, stockez l'ensemble du document JSON en tant que chaîne dans une valeur de registre. Le domaine plist et la clé de registre se trouvent dans Où chaque mécanisme stocke la politique.
- Fichier de paramètres gérés : placez un
managed-settings.jsonau chemin système de la plateforme. Vous pouvez également ajouter des fichiers au répertoire drop-inmanaged-settings.d/à côté de celui-ci. Les chemins de fichier par plateforme se trouvent dans Où chaque mécanisme stocke la politique, et les règles de fusion drop-in se trouvent dans Diviser une politique basée sur fichier entre les équipes.
Utilisez les paramètres gérés par le serveur si vous avez une organisation Claude for Teams ou Enterprise sur claude.ai et que vos appareils ne sont pas tous sous MDM. Sinon, utilisez une politique MDM ou le fichier de paramètres gérés. Pour le compromis, voir Choisir entre les paramètres gérés par le serveur et gérés par le point de terminaison.
Quelle source gérée s'applique sur une machine
Par défaut, une seule de ces trois sources s'applique sur une machine. Claude Code utilise la première qui livre une clé de politique, en vérifiant d'abord les paramètres gérés par le serveur, puis les politiques MDM, puis le fichier de paramètres gérés. Si les paramètres gérés par le serveur livrent même une seule clé non liée, Claude Code ignore les clés de plugin dans une politique MDM ou un fichier de paramètres gérés sur cette machine, à l'exception des clés qu'il lit à partir de chaque source.
Pour appliquer chaque source à la place, définissez managedSourcesBehavior sur "merge".
Comment Claude Code combine les sources gérées liste également les clés que Claude Code lit à partir de chaque source dans les deux modes.
Exiger un marketplace et ses plugins
Ajoutez le marketplace sous extraKnownMarketplaces, indexé par le name propre du marketplace à partir de son marketplace.json. Ensuite, ajoutez chaque plugin sous enabledPlugins en tant que plugin-name@marketplace-name. Chaque entrée de marketplace porte un objet source avec un champ source nommant le type, tel que github. Cet exemple de paramètres gérés enregistre un marketplace d'organisation et force-active deux plugins à partir de celui-ci :
{
"extraKnownMarketplaces": {
"your-marketplace": {
"source": { "source": "github", "repo": "your-org/your-marketplace" },
"autoUpdate": true
}
},
"enabledPlugins": {
"code-formatter@your-marketplace": true,
"deploy-helper@your-marketplace": true
}
}
Une fois que les paramètres atteignent une machine, Claude Code enregistre le marketplace et installe les deux plugins au début de la session suivante de l'utilisateur. Les utilisateurs les voient dans /plugin, et désactiver l'un à leur propre portée ne l'empêche pas de se charger, car les paramètres gérés ont la priorité sur chaque autre portée.
Pour bloquer un plugin à chaque portée et le masquer de la liste du marketplace, définissez-le sur false dans le enabledPlugins géré à la place.
Ajustez les champs autoUpdate et source pour votre marketplace :
autoUpdate:truegarde le marketplace et ses plugins en actualisation en arrière-plan, etfalsedésactive cela. Voir Définir la politique de mise à jour.source:githubest l'un de plusieurs types de sources. Une sourcegitprend uneurlpour GitLab ou un hôte interne, et une sourceurlprend l'adresse d'unmarketplace.jsonhébergé. Chaque forme de source se trouve dans la référence du marketplace.
Si le marketplace est un référentiel git privé, chaque utilisateur a besoin d'un accès en lecture à celui-ci. Le clone d'un marketplace basé sur git s'exécute avec git sur la machine de l'utilisateur, en utilisant les identifiants stockés et sans invites. Pour les utilisateurs sans comptes d'hôte git, utilisez un seed à la place.
Une entrée gérée remplace également une entrée de marketplace de même nom ou une copie --plugin-dir d'une autre source :
- Marketplaces : une entrée de marketplace gérée remplace une entrée de priorité inférieure du même nom, et les champs des deux entrées ne fusionnent pas.
- Copies
--plugin-dir:--plugin-dircharge un plugin à partir d'un répertoire local pour une session. Pour ce qui se passe quand le nom de cette copie correspond à un plugin que votreenabledPluginsgéré nomme, voir Conflits de noms.
Le marketplace officiel d'Anthropic claude-plugins-official n'a besoin d'aucune entrée extraKnownMarketplaces quand enabledPlugins définit l'un de ses plugins sur true. Cette entrée name@claude-plugins-official déclare le marketplace par elle-même, partout où ces clés s'appliquent. Si vous n'activez aucun de ses plugins et souhaitez toujours qu'il soit enregistré sur chaque machine, donnez-lui une entrée explicite, comme Autoriser le marketplace officiel et le vôtre le fait.
Exiger des plugins par référentiel
Pour couvrir les contributeurs d'un seul référentiel au lieu de votre flotte entière, définissez extraKnownMarketplaces et enabledPlugins dans le .claude/settings.json de ce référentiel. Les entrées extraKnownMarketplaces s'appliquent uniquement dans un dossier que le contributeur a approuvé, et dans un dossier non approuvé Claude Code les ignore sans message :
- Sessions interactives : Claude Code enregistre le marketplace uniquement après que le contributeur accepte la boîte de dialogue de confiance de l'espace de travail pour ce dossier.
- Exécutions non interactives
-p: les entrées s'appliquent uniquement dans un dossier dont la confiance que l'utilisateur a déjà acceptée de manière interactive, ou dont vous définissez l'indicateurhasTrustDialogAccepteddans~/.claude.json.
Un plugin que le marketplace liste par un chemin relatif se charge à partir de la copie du marketplace une fois que les entrées extraKnownMarketplaces du référentiel s'appliquent. Un plugin dont l'entrée de marketplace pointe vers une source externe à la place, comme le référentiel GitHub propre du plugin, ne s'installe pas à partir des paramètres du référentiel seuls. Chaque contributeur voit Plugin "<name>" is enabled in project settings but isn't installed jusqu'à ce qu'il exécute claude plugin install <name>@<marketplace> --scope project, comme Installer des plugins le décrit.
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 référentiel. Quand vous exécutez Claude Code à partir d'une git worktree, le chemin pointe toujours vers le checkout principal, donc tous les worktrees partagent le même emplacement de marketplace.
Pour déployer un ensemble de plugins avec des dépendances, mettez le plugin d'ensemble dans enabledPlugins, comme Dépendances des plugins le décrit.
Quand chaque surface applique les clés de plugin
Le tableau montre quand chaque type de session Claude Code applique extraKnownMarketplaces et enabledPlugins, à partir des paramètres gérés et du .claude/settings.json d'un référentiel. Pour l'application Desktop et les extensions IDE, voir Installer un plugin.
| Surface | extraKnownMarketplaces et enabledPlugins gérés |
.claude/settings.json du référentiel |
|---|---|---|
| Terminal, interactif | Appliqué au démarrage de la session sur chaque machine qui reçoit les paramètres | extraKnownMarketplaces appliqué après la confiance ; enabledPlugins appliqué au démarrage de la session |
-p et IC |
Appliqué au démarrage de la session, avec les installations s'exécutant en arrière-plan | extraKnownMarketplaces dans les dossiers approuvés uniquement ; enabledPlugins appliqué |
| Sessions cloud | Dans un environnement hébergé par Anthropic, seuls les paramètres gérés par le serveur atteignent la session, qui les attend avant d'installer les plugins. Les politiques MDM et les fichiers de paramètres gérés restent sur la machine de l'utilisateur. Pour un environnement auto-hébergé, voir Où et quand une politique s'applique | Voir l'onglet Session cloud sous Installer un plugin |
Dans une exécution -p ou IC, les marketplaces et les plugins s'installent en arrière-plan, donc un plugin peut manquer du premier tour. Définissez CLAUDE_CODE_SYNC_PLUGIN_INSTALL=1 pour faire attendre l'exécution à l'installation avant sa première requête.
Confirmer le déploiement
Vérifiez que le marketplace et les plugins sont arrivés sur une machine ou dans une exécution IC :
- Sur une machine : démarrez Claude Code et exécutez
/plugin. Le marketplace et les plugins sont listés. - En IC : exécutez
claude -pavec--output-format stream-json --verbose. L'événementinitliste les plugins chargés sousplugins.
Ensemencer les conteneurs et l'IC
Pour les images de conteneur et les exécuteurs IC qui ne peuvent pas cloner au moment de l'exécution, pré-remplissez un répertoire de plugins au moment de la construction et pointez CLAUDE_CODE_PLUGIN_SEED_DIR vers celui-ci. Claude Code enregistre les marketplaces du seed au démarrage et charge les caches de plugins à partir du seed en place, sans cloner.
Un seed sert également les utilisateurs qui n'ont pas de compte d'hôte git.
Dans les environnements IC/CD, configurez un assistant d'identifiants git avant d'installer des plugins à partir de référentiels privés. Sur GitHub Actions, exportez un jeton avec accès en lecture au référentiel du marketplace en tant que GH_TOKEN, puis exécutez gh auth setup-git. Le jeton de flux de travail par défaut ne peut accéder qu'au référentiel du flux de travail lui-même, donc un marketplace privé dans un autre référentiel a besoin d'un jeton d'accès personnel ou d'un jeton d'application.
Installer dans le seed au moment de la construction
Définissez CLAUDE_CODE_PLUGIN_CACHE_DIR sur le chemin du seed pour que le marketplace et les plugins s'installent là à la place de ~/.claude/plugins :
CLAUDE_CODE_PLUGIN_CACHE_DIR=/opt/claude-seed claude plugin marketplace add your-org/your-marketplace
CLAUDE_CODE_PLUGIN_CACHE_DIR=/opt/claude-seed claude plugin install code-formatter@your-marketplace
Le seed a la même disposition que ~/.claude/plugins : known_marketplaces.json, marketplaces/<name>/, et cache/<marketplace>/<plugin>/<version>/. Vous pouvez monter le seed à un chemin différent de celui où vous l'avez construit.
Pointer l'exécution vers le seed
Définissez CLAUDE_CODE_PLUGIN_SEED_DIR=/opt/claude-seed dans l'environnement du conteneur. Pour utiliser plusieurs seeds, séparez leurs chemins avec : sur Unix ou ; sur Windows. Claude Code utilise le premier seed qui contient un marketplace ou un cache de plugin donné.
Activer les plugins
Les plugins dans un seed ne sont pas activés d'eux-mêmes. Définissez enabledPlugins pour chaque plugin de seed que vous souhaitez charger, dans les paramètres gérés ou dans le .claude/settings.json du référentiel.
Pour vérifier un seed, exécutez claude -p avec --output-format stream-json --verbose dans l'image. Dans la liste plugins de l'événement init, le path de chaque plugin chargé se trouve sous le seed, tel que /opt/claude-seed/cache/your-marketplace/code-formatter/1.0.0.
Les marketplaces de seed suivent ces règles :
- Lecture seule : Claude Code n'écrit jamais dans le seed et force
autoUpdateà off pour les marketplaces de seed. - Les entrées de seed ont la priorité : à chaque démarrage, un marketplace déclaré dans le seed remplace l'entrée de l'utilisateur du même nom. Les utilisateurs se désabonnent d'un plugin de seed avec
claude plugin disable, pas en supprimant le marketplace. - La mise à jour et la suppression échouent :
claude plugin marketplace update <name>etremovesans--scopesur un marketplace de seed échouent avec un message qui nomme le répertoire du seed. - La politique s'applique toujours : la liste blanche et la liste noire vérifient également la source enregistrée d'un marketplace de seed. Autorisez la source à partir de laquelle vous avez construit le seed.
Pour les flottes sans accès git sortant, combinez un seed avec des sources de marketplace directory ou file sur un montage partagé. Définissez également CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1, qui désactive également la mise à jour automatique des plugins. Si un proxy est disponible, voir Configuration du proxy pour les variables à définir.
Restreindre ce que les utilisateurs peuvent installer
La liste blanche gérée strictKnownMarketplaces et la liste noire blockedMarketplaces décident quelles sources de marketplace les plugins peuvent provenir. La source d'un marketplace est le référentiel git, l'URL ou le chemin local que Claude Code récupère. Les deux listes correspondent à la source du marketplace d'où provient un plugin, pas à l'entrée propre du plugin à l'intérieur de ce marketplace.
Pour le verrouillage courant, qui autorise le marketplace officiel et le vôtre, voir Autoriser le marketplace officiel et le vôtre. Associez-le à disableSideloadFlags pour que les utilisateurs ne puissent pas charger les plugins à partir d'un répertoire local ou d'une URL non plus.
Les deux listes s'appliquent avant tout téléchargement et à nouveau au démarrage de la session :
- Avant un téléchargement : les listes s'appliquent quand un utilisateur ajoute un marketplace et à chaque installation, mise à jour, actualisation et mise à jour automatique.
- Au démarrage de la session : les listes s'appliquent à nouveau aux plugins déjà installés, donc un plugin installé dont la source du marketplace ne correspond plus ne se charge pas.
/pluginle liste avecMarketplace "<name>" is not in the allowed marketplace listouMarketplace "<name>" is blocked by enterprise policy.
L'endroit où les deux listes sont appliquées dépend de l'endroit où vous les définissez :
- La console d'administration claude.ai : Claude Code applique les deux listes dans les sessions qui lisent les paramètres gérés par le serveur. claude.ai les vérifie également quand quelqu'un dans votre organisation ajoute un nouveau marketplace à partir d'un référentiel git sur claude.ai, ou à partir de Personnaliser dans l'application Claude Desktop en dehors de son onglet Code. Cela couvre un marketplace qu'un membre ajoute pour son propre compte et un ajouté pour toute l'organisation sous Paramètres de l'organisation > Plugins. claude.ai refuse un référentiel que la liste blanche n'admet pas ou que la liste noire nomme. Il ne re-vérifie pas un marketplace qui a été ajouté dans l'un ou l'autre endroit avant que vous définissiez les listes, et il ne vérifie pas les plugins téléchargés.
- Un fichier de paramètres gérés, une politique au niveau du système d'exploitation ou une autre source gérée : Claude Code applique les deux listes où il lit cette source. claude.ai ne la lit pas.
Tant qu'une liste blanche est définie, ou qu'une liste noire nomme une source autre que skills-dir, un plugin dont Claude Code ne peut pas trouver le marketplace ne se charge pas. /plugin affiche l'erreur de politique pour celui-ci plutôt qu'une erreur de non-trouvé. Le cas courant est une entrée enabledPlugins obsolète pour un marketplace que personne n'a enregistré.
Matrice de contrôle
Le tableau liste chaque clé de politique de plugin, ce qu'elle applique et ce qu'elle ne peut pas faire.
| Clé | Ce qu'elle applique | Ce qu'elle ne peut pas faire |
|---|---|---|
strictKnownMarketplaces |
Liste blanche des sources de marketplace. [] bloque chaque source, y compris le marketplace officiel. Alias : allowedMarketplaces |
N'enregistre pas un marketplace, ne restreint pas les entrées à l'intérieur d'un marketplace autorisé, ou ne bloque pas --plugin-dir |
blockedMarketplaces |
Liste noire des sources de marketplace, vérifiée avant la liste blanche | Ne bloque pas un marketplace déjà enregistré à partir d'une source qu'il ne correspond pas |
syncClaudeAiPlugins |
Définissez false pour arrêter Claude Code de télécharger et charger les plugins synchronisés à partir de claude.ai pour le compte de chaque utilisateur. Nécessite Claude Code v2.1.273 ou ultérieur |
N'éteint pas un plugin synchronisé. Pour cela, définissez "<name>@synced": false dans enabledPlugins |
enabledPlugins |
true force-active, false bloque à chaque portée et masque le plugin |
N'installe pas un plugin dont le marketplace n'est pas enregistré ou autorisé |
disableSideloadFlags |
Rejette --plugin-dir, --plugin-url, --agents, l'option plugins du SDK Agent, et --mcp-config non-SDK au démarrage, et rejette les dossiers nommés dans la variable CLAUDE_CODE_PLUGIN_DIRS de la même manière |
Ne restreint pas .mcp.json, claude mcp add, ou les serveurs fournis par SDK. Associez-le à allowedMcpServers |
disableCommandPluginSources |
Bloque les plugins avec une source command de l'installation, de la mise à jour ou du chargement. Une source command est celle dont le répertoire de plugins est produit en exécutant une commande sur la machine. Quand non défini, il prend la valeur de allowManagedHooksOnly |
N'affecte pas les autres types de sources |
allowManagedHooksOnly |
Restreint les hooks qui s'exécutent. Voir allowManagedHooksOnly |
Ne fait confiance pas aux hooks des plugins que les utilisateurs activent eux-mêmes |
strictPluginOnlyCustomization |
Bloque les compétences, les agents, les hooks et les serveurs MCP qui ne proviennent pas d'un plugin, des paramètres gérés ou des éléments intégrés de Claude Code. Définissez true pour couvrir les quatre types, ou un tableau de valeurs skills, agents, hooks et mcp telles que ["skills", "hooks"] pour en couvrir certains |
Ne restreint pas les plugins que les utilisateurs installent. Associez-le à strictKnownMarketplaces |
pluginSuggestionMarketplaces |
Marketplaces dont les plugins peuvent apparaître comme suggestions d'installation. Voir Recommander des plugins | N'affecte pas les conseils intégrés |
pluginTrustMessage |
Ajoute votre texte à l'avertissement de confiance que /plugin affiche avant l'installation d'un plugin |
Ne change pas le texte de l'avertissement lui-même |
allowedChannelPlugins |
Remplace la liste par défaut des plugins autorisés à envoyer des messages de canal. Nécessite channelsEnabled: true |
Voir Restreindre les plugins de canal qui peuvent s'exécuter |
CLAUDE_CODE_DISABLE_OFFICIAL_MARKETPLACE_AUTOINSTALL=1 |
Arrête les sessions de terminal interactives de l'auto-enregistrement du marketplace officiel | Ne supprime pas un marketplace déjà enregistré. La liste blanche et la liste noire contrôlent le même auto-enregistrement sans celui-ci. Une machine qui a démarré une fois avec celui-ci défini ne reprend pas l'auto-enregistrement après l'avoir désactivé |
Chaque clé du tableau est un paramètre géré, à l'exception de enabledPlugins, syncClaudeAiPlugins et CLAUDE_CODE_DISABLE_OFFICIAL_MARKETPLACE_AUTOINSTALL :
enabledPlugins: vous pouvez le définir dans n'importe quelle portée, et les paramètres gérés le verrouillent.syncClaudeAiPlugins: chaque utilisateur peut également le définir dans ses propres paramètres utilisateur ou locaux. Voir sa portée dans la référence des paramètres.CLAUDE_CODE_DISABLE_OFFICIAL_MARKETPLACE_AUTOINSTALL: c'est une variable d'environnement que vous livrez via le blocenvgéré montré sous Désactiver les mises à jour pour toute la flotte.
Chaque clé de paramètres ici a une entrée dans la référence des paramètres.
Alias pour les clés du marketplace
strictKnownMarketplaces peut également être orthographié allowedMarketplaces, et extraKnownMarketplaces peut également être orthographié additionalMarketplaces.
- Version : les alias nécessitent Claude Code v2.1.232 ou ultérieur, et les clients plus anciens les ignorent. Dans un fichier qu'une flotte mixte lit, gardez les noms canoniques.
- Les deux orthographes définies : quand un fichier définit les deux orthographes, la valeur de la clé canonique s'applique.
Liste blanche avec `strictKnownMarketplaces`
Définissez la liste blanche sur une liste de ces objets de source. La plupart des entrées correspondent exactement, les entrées hostPattern et pathPattern correspondent en tant qu'expressions régulières, et les caractères génériques de propriétaire github correspondent par propriétaire :
github:{ "source": "github", "repo": "your-org/approved-plugins" }, avecrefetpathoptionnels.- Caractère générique de propriétaire
github:{ "source": "github", "repo": "your-org/*" }correspond à chaque référentiel sous ce propriétaire. Le*doit représenter le nom de référentiel entier. Claude Code ignore les entrées telles que*/pluginsetyour-org/tools-*comme invalides, donc elles ne correspondent à rien. Nécessite Claude Code v2.1.223 ou ultérieur. git:{ "source": "git", "url": "https://gitlab.example.com/tools/plugins.git" }, avecrefetpathoptionnels.url:{ "source": "url", "url": "https://plugins.example.com/marketplace.json" }, avecheadersoptionnels.fileetdirectory:{ "source": "file", "path": "/opt/marketplace/marketplace.json" }ou{ "source": "directory", "path": "/opt/marketplace/plugins" }, avec des chemins absolus.hostPattern:{ "source": "hostPattern", "hostPattern": "^github\\.example\\.com$" }, comparé à l'hôte des sourcesgithub,giteturl. Le motif correspond n'importe où dans le nom d'hôte, donc ancrez-le avec^et$comme montré pour correspondre à l'hôte entier. Une sourcegithubcompte toujours commegithub.com. Utilisez une entréehostPatternpour un serveur GitHub Enterprise Server ou un hôte GitLab où les développeurs créent leurs propres marketplaces. La page GHES a l'exemple travaillé.pathPattern:{ "source": "pathPattern", "pathPattern": "^/opt/approved/" }, comparé aupathdes sourcesfileetdirectory. Le motif correspond n'importe où dans le chemin, donc commencez-le par^pour épingler un préfixe de répertoire.".*"autorise chaque chemin local.skills-dir:{ "source": "skills-dir" }garde les plugins du répertoire de compétences en chargement tandis qu'une liste blanche est définie, et ne correspond à aucun marketplace.
Comment les entrées correspondent
Une entrée url correspond sur sa valeur url ; headers ne sont pas comparés. Pour les entrées github et git, le repo ou url, le ref et le path doivent tous correspondre, ou être absents des deux côtés :
- Une entrée sans
refne couvre pas une source avecref: "main". - Une entrée pour
your-org/your-marketplacene couvre pas une URLgitqui clone le même référentiel. - Une barre oblique finale, un suffixe
.gitoussh://à la place dehttps://est une valeur différente. Quand un marketplace peut être cloné par plus d'une URL, préférez une entréehostPattern.
Les entrées de caractère générique de propriétaire suivent les règles exactes pour ref et correspondent à n'importe quel path à l'intérieur du référentiel à moins que l'entrée n'en épingle un. La correspondance de caractère générique est sensible à la casse sur la liste blanche.
Garder les plugins du répertoire de compétences en chargement
Les plugins du répertoire de compétences sont les plugins que les utilisateurs gardent sous ~/.claude/skills/ ou un .claude/skills/ du projet dans des dossiers qui portent un .claude-plugin/plugin.json. Si vous définissez une liste blanche sans une entrée { "source": "skills-dir" }, ils arrêtent de se charger. Les compétences simples, c'est-à-dire un SKILL.md sans ce manifeste, continuent de se charger.
Marketplaces hébergés sur claude.ai
La liste blanche et la liste noire correspondent à un marketplace hébergé sur claude.ai par son hôte. Pour en autoriser ou en bloquer un, ajoutez une entrée hostPattern qui correspond à claude.ai à strictKnownMarketplaces ou blockedMarketplaces. Sur la liste blanche, une telle entrée admet vos marketplaces claude.ai de l'organisation et les marketplaces par défaut de claude.ai, mais pas un marketplace composé des téléchargements claude.ai propres d'un membre ou dont la portée claude.ai n'a pas été déclarée. Nécessite Claude Code v2.1.273 ou ultérieur.
Verrouiller chaque source
Une liste blanche vide, [], verrouille chaque source de marketplace, y compris le marketplace officiel.
Ce verrouillage ne couvre pas les plugins synchronisés à partir de claude.ai, que Claude Code télécharge à partir du compte de chaque utilisateur plutôt qu'à partir d'un marketplace. Pour arrêter ceux-ci aussi, définissez syncClaudeAiPlugins sur false dans les paramètres gérés, ou désactivez les compétences pour votre organisation sur claude.ai.
Liste noire avec `blockedMarketplaces`
blockedMarketplaces prend les mêmes objets de source que strictKnownMarketplaces et est vérifiée en premier, donc une source sur les deux listes est bloquée. La correspondance de liste noire est plus large que la correspondance de liste blanche :
- Les URL git sont canonicalisées, donc les formes
git@ethttps://, les suffixes.gitet les barres obliques finales d'un référentielgithub.comcorrespondent tous à la même entrée. - Une entrée
githubbloque également l'URLgitéquivalente, et vice versa. - Pour une entrée
owner/*, la comparaison du propriétaire est insensible à la casse. - Une entrée sans
refoupathbloque chaque ref et chemin des référentiels qu'elle correspond.
Cette entrée bloque chaque référentiel sous un propriétaire GitHub :
{
"blockedMarketplaces": [
{ "source": "github", "repo": "untrusted-org/*" }
]
}
Les entrées url dans blockedMarketplaces s'appliquent également quand un utilisateur ajoute une URL de référentiel https:// que Claude Code clone plutôt que récupère, comme une URL de référentiel github.com ou gitlab.com nue. L'utilisateur ne peut pas ajouter cette URL si une entrée la nomme. La correspondance ignore le suffixe .git et tout ref que l'utilisateur ajoute après #. Nécessite Claude Code v2.1.232 ou ultérieur.
Une entrée { "source": "skills-dir" } ici arrête les plugins du répertoire de compétences de se charger, à partir de ~/.claude/skills/ et du .claude/skills/ d'un projet.
Une liste noire qui nomme uniquement cette entrée ne compte pas comme une restriction active, donc elle ne arrête pas les plugins dont Claude Code ne peut pas trouver le marketplace de se charger.
Autoriser le marketplace officiel et le vôtre
La plupart des organisations autorisent le marketplace officiel et le leur, et enregistrent les deux pour que chaque machine les ait. Cette politique de paramètres gérés autorise les deux marketplaces, enregistre les deux, force-active deux plugins et rejette --plugin-dir :
{
"strictKnownMarketplaces": [
{ "source": "github", "repo": "anthropics/claude-plugins-official" },
{ "source": "github", "repo": "your-org/*" },
{ "source": "skills-dir" }
],
"extraKnownMarketplaces": {
"claude-plugins-official": {
"source": { "source": "github", "repo": "anthropics/claude-plugins-official" }
},
"your-marketplace": {
"source": { "source": "github", "repo": "your-org/your-marketplace" }
}
},
"enabledPlugins": {
"code-formatter@your-marketplace": true,
"deploy-helper@your-marketplace": true
},
"disableSideloadFlags": true
}
Sur une machine avec cette politique, ajouter une source en dehors de la liste, par exemple /plugin marketplace add https://example.com/other-marketplace.git, échoue avec un message contenant is blocked by enterprise policy suivi des sources autorisées. claude --plugin-dir ./x se termine avec un message nommant disableSideloadFlags.
L'entrée { "source": "skills-dir" } garde les plugins du répertoire de compétences en chargement sous cette liste blanche. Supprimez cette entrée et ils arrêtent de se charger.
Enregistrez les deux marketplaces avec des entrées extraKnownMarketplaces explicites, comme cette politique le fait, plutôt que de compter sur la liste blanche ou sur l'auto-enregistrement du marketplace officiel :
- La liste blanche n'enregistre rien : une entrée
extraKnownMarketplacesle fait, et elle doit elle-même passer la liste blanche. Claude Code refuse d'enregistrer un marketplace géré dont la source ne correspond pas à la liste blanche. - Le marketplace officiel ne s'enregistre que dans une session de terminal interactif : même là, il ne s'enregistre que quand la liste blanche le permet. Une exécution
-pou un terminal attaché à une session cloud ne l'enregistre jamais. - Une tentative bloquée est mémorisée : si une machine a jamais fonctionné sous une politique qui bloquait le marketplace officiel, Claude Code enregistre la tentative bloquée et ne réessaie pas après le changement de politique. Un verrouillage
[]est une telle politique. Cette machine l'enregistre à nouveau uniquement via une entréeextraKnownMarketplacescomme celle de cette politique, une entréeenabledPluginspour l'un de ses plugins, ou un/plugin marketplace addmanuel.
Définir la politique de mise à jour
Vous pouvez définir la politique de mise à jour par marketplace, pour toute la flotte, ou par groupe d'utilisateurs via les canaux de version.
Activer ou désactiver la mise à jour automatique par marketplace
La mise à jour automatique des plugins s'exécute en arrière-plan après le démarrage pour les marketplaces qui l'ont activée. Pour savoir quels marketplaces l'ont activée par défaut, voir Quand la mise à jour automatique s'exécute. Pour décider pour la flotte, définissez "autoUpdate": true ou false sur une entrée extraKnownMarketplaces gérée :
- Si l'entrée gérée définit le champ, Claude Code rejette le basculement
/pluginde l'utilisateur avec une erreur qui commence parAuto-update for '<name>' is set by. - Si l'entrée gérée laisse le champ non défini, le basculement de l'utilisateur persiste.
Désactiver les mises à jour pour toute la flotte
Pour désactiver la mise à jour automatique des plugins pour chaque marketplace, définissez DISABLE_AUTOUPDATER dans le bloc env géré, comme cet exemple le fait. La même variable arrête également les mises à jour de Claude Code lui-même :
{
"env": {
"DISABLE_AUTOUPDATER": "1"
}
}
Pour arrêter les mises à jour de Claude Code lui-même mais garder la mise à jour automatique des plugins, ajoutez "FORCE_AUTOUPDATE_PLUGINS": "1" au même bloc. Les autres variables d'environnement qui arrêtent la mise à jour automatique des plugins fonctionnent de la même manière.
DISABLE_AUTOUPDATER ne couvre pas les plugins avec une source command. Claude Code réexécute la commande de chaque plugin activé à chaque session et installe la sortie quand elle a changé. Pour ce qui arrête ces exécutions, voir Quand une source de commande réexécute.
Assigner les canaux de version aux groupes d'utilisateurs
Pour exécuter des canaux stables et d'accès anticipé, hébergez deux marketplaces qui pointent vers différents refs des mêmes plugins. Ensuite, donnez à chaque groupe d'utilisateurs son propre marketplace via soit des paramètres gérés par le point de terminaison séparés, soit une politique de passerelle. Les paramètres gérés par le serveur de la console d'administration s'appliquent à chaque utilisateur de votre organisation, donc ils ne peuvent pas assigner des paramètres différents à différents groupes.
- Déployez des paramètres gérés par le point de terminaison séparés, tels qu'un fichier de paramètres gérés ou un profil MDM, sur les appareils de chaque groupe. Pour vérifier si le fichier ou le profil par groupe s'applique sur un appareil qui a également une source au niveau de l'organisation, voir Comment Claude Code combine les sources gérées.
- Définissez une politique de passerelle d'applications Claude par groupe. La passerelle applique la première politique dont la règle de correspondance correspond à un utilisateur, donc ordonnez les politiques pour que chaque utilisateur atteigne la politique de son groupe. La
extraKnownMarketplacesde cette politique ne fusionne pas avec celle d'une autre politique, donc listez chaque marketplace dont le groupe a besoin, pas seulement son marketplace de canal.
Avec l'un ou l'autre mécanisme, le groupe stable reçoit cette configuration :
{
"extraKnownMarketplaces": {
"stable-tools": {
"source": { "source": "github", "repo": "your-org/stable-tools" }
}
}
}
Le groupe d'accès anticipé reçoit latest-tools à la place. Pour configurer les deux marketplaces, voir Exécuter les canaux de version.
Recommander des plugins
Les propriétaires de marketplace peuvent joindre des signaux relevance aux entrées pour que Claude Code suggère le plugin quand un projet correspond.
Les suggestions d'un marketplace n'apparaissent que quand il est enregistré sur la machine de l'utilisateur, vous listez son nom dans pluginSuggestionMarketplaces dans les paramètres gérés, et vous déclarez sa source dans la même politique. Déclarez la source soit comme l'entrée extraKnownMarketplaces du marketplace, soit comme une entrée de liste blanche. Le marketplace officiel a besoin uniquement du nom. Voir Activer les suggestions dans les paramètres gérés.
Auditer et examiner
Les événements OpenTelemetry et l'API Analytics vous disent ce que votre flotte installe et exécute.
Pour ce qu'un plugin peut exécuter sur une machine et ce que chaque niveau de confiance permet, lisez Sécurité des plugins avant d'approuver un marketplace.
Événements OpenTelemetry
claude_code.plugin_installed enregistre chaque installation, et claude_code.plugin_loaded enregistre chaque plugin activé au démarrage de la session. Les deux événements masquent ou omettent les noms de plugins et de marketplaces tiers à moins que vous définissiez OTEL_LOG_TOOL_DETAILS=1, comme Noms de plugins masqués dans votre backend le montre. Les listes de champs se trouvent sous Événement de plugin installé et Événement de plugin chargé.
API Analytics
Sur le plan Enterprise, GET /v1/organizations/analytics/plugins retourne les comptes d'installation et d'invocation par plugin, par jour, sur Claude Code et Cowork. Vous pouvez grouper les comptes par utilisateur ou groupe RBAC. L'activité de plugin qui atteint Anthropic sans un nom de plugin apparaît dans une ligne third-party agrégée. Voir la référence du point de terminaison et Accéder aux données par programmation pour la clé dont elle a besoin.
Planifier ce que les paramètres gérés ne peuvent pas appliquer
Ces demandes des examens de sécurité n'ont pas de clé dédiée dans le schéma de paramètres actuel. Les contrôles existants les plus proches sont :
- Ciblage par utilisateur ou par groupe : chaque clé de plugin s'applique à chaque utilisateur qui reçoit les paramètres. Les paramètres gérés par le serveur livrent une configuration par organisation. Pour une politique par groupe, utilisez des paramètres gérés par le point de terminaison séparés ou des politiques de passerelle, comme sous Assigner les canaux de version aux groupes d'utilisateurs.
- Restreindre les entrées à l'intérieur d'un marketplace autorisé : la liste blanche correspond aux sources de marketplace. Pour bloquer un plugin d'un marketplace autorisé, définissez-le sur
falsedansenabledPluginsgéré. - Masquer
/plugin: aucune clé ne désactive la commande. L'équivalent le plus proche combine une liste blanche nommant uniquement votre marketplace, des entréesenabledPluginsgérées pour les plugins que vous fournissez, etdisableSideloadFlags. - Contrôler
--plugin-dirvia la liste blanche : la liste blanche ne couvre pas--plugin-dir.disableSideloadFlagsle fait. - Appliquer les bascules de plugin claude.ai via ces clés : Paramètres de l'organisation > Plugins et compétences ne définit pas les clés de cette page. Ce que les membres et votre organisation activent là atteint l'interface de ligne de commande sous forme de plugins synchronisés, qui ont leurs propres contrôles.
Dépanner la politique
Si la politique de plugin ne se comporte pas comme prévu sur une machine, vérifiez d'abord ces symptômes :
- Le fichier géré n'a pas été analysé : quand un
managed-settings.jsonn'est pas un JSON valide, Claude Code refuse de démarrer et imprime une erreur nommant le fichier. Un fichier qui s'analyse mais a une entrée invalide garde le reste de sa politique. Voir Entrées invalides dans les paramètres gérés. - La source gérée n'a pas chargé : exécutez
/statuset cherchezEnterprise managed settingsdans la ligneSetting sources. S'il manque, la source n'a pas chargé. - Un utilisateur signale
blocked by enterprise policy: le message nomme le marketplace ou sa source. Pour une liste blanche, il liste également les sources autorisées. Les entrées visibles par l'utilisateur se trouvent sur Dépanner les plugins. - Un plugin que l'utilisateur a désactivé dans
~/.claude/settings.jsonse charge toujours : une autre source de paramètres l'a réactivé, comme une entréeenabledPluginsgérée qui le force-active./pluginetclaude plugin listaffichentDisabled in ~/.claude/settings.json but still loadsavec cette source de paramètres.
Étapes suivantes
- Référence du marketplace : les valeurs
sourcequeextraKnownMarketplaces,strictKnownMarketplacesetblockedMarketplacesacceptent - Héberger et maintenir un marketplace : exécutez le marketplace vers lequel votre politique pointe
- Sécurité et confiance des plugins : ce qu'un plugin peut faire sur une machine et comment en examiner un avant l'installation
- Paramètres gérés par le serveur : livrez ces clés à partir de la console d'administration claude.ai
- Dépanner les plugins : les messages que les utilisateurs voient quand la politique les bloque