Plugins

Gérer les plugins Gateway, les packs de hooks et les bundles compatibles.

Plugin system

Guide de l’utilisateur final pour l’installation, l’activation et le troubleshooting des plugins.

Manage plugins

Exemples rapides pour l’installation, la liste, la mise à jour, la désinstallation et la publication.

Plugin bundles

Modèle de compatibilité des bundles.

Plugin manifest

Champs du manifeste et schéma de configuration.

Security

Renforcement de la sécurité pour l’installation des plugins.

Commandes

openclaw plugins list
openclaw plugins list --enabled
openclaw plugins list --verbose
openclaw plugins list --json
openclaw plugins search <query>
openclaw plugins search <query> --limit 20
openclaw plugins search <query> --json
openclaw plugins install <path-or-spec>
openclaw plugins inspect <id>
openclaw plugins inspect <id> --runtime
openclaw plugins inspect <id> --json
openclaw plugins inspect --all
openclaw plugins info <id>
openclaw plugins enable <id>
openclaw plugins disable <id>
openclaw plugins registry
openclaw plugins registry --refresh
openclaw plugins uninstall <id>
openclaw plugins doctor
openclaw plugins update <id-or-npm-spec>
openclaw plugins update --all
openclaw plugins marketplace list <marketplace>
openclaw plugins marketplace list <marketplace> --json
openclaw plugins init <id>
openclaw plugins init <id> --directory ./my-plugin --name "My Plugin"
openclaw plugins build --entry ./dist/index.js
openclaw plugins build --entry ./dist/index.js --check
openclaw plugins validate --entry ./dist/index.js

Pour les investigations d’installation lente, d’inspection, de désinstallation ou d’actualisation du registre, exécutez la commande avec OPENCLAW_PLUGIN_LIFECYCLE_TRACE=1. La trace écrit les durées des phases sur stderr et maintient la sortie JSON analysable. Voir Débogage.

Auteur

openclaw plugins init stock-quotes --name "Stock Quotes"
cd stock-quotes
npm run plugin:build
npm run plugin:validate

plugins init crée un plugin tool TypeScript minimal qui utilise defineToolPlugin. plugins build importe cette entrée, lit ses métadonnées tool statiques, écrit openclaw.plugin.json et maintient package.json openclaw.extensions alignés. plugins validate vérifie que le manifeste généré, les métadonnées du package et l’export de l’entrée actuelle sont toujours en accord. Voir Tool Plugins pour le flux de travail complet de création.

L’échafaudage écrit le source TypeScript mais génère les métadonnées à partir de l’entrée construite ./dist/index.jsCLI, donc le flux de travail fonctionne également avec le CLI publié. Utilisez --entry <path> lorsque l’entrée n’est pas l’entrée par défaut du package. Utilisez plugins build --check dans CI pour échouer lorsque les métadonnées générées sont obsolètes sans réécrire les fichiers.

Installer

openclaw plugins search "calendar"                   # search ClawHub plugins
openclaw plugins install <package>                      # source auto-detection
openclaw plugins install clawhub:<package>              # ClawHub only
openclaw plugins install npm:<package>                  # npm only
openclaw plugins install npm-pack:<path.tgz>            # local npm pack through npm install semantics
openclaw plugins install git:github.com/<owner>/<repo>  # git repo
openclaw plugins install git:github.com/<owner>/<repo>@<ref>
openclaw plugins install <package> --force              # overwrite existing install
openclaw plugins install <package> --pin                # pin version
openclaw plugins install <package> --dangerously-force-unsafe-install
openclaw plugins install <path>                         # local path
openclaw plugins install <plugin>@<marketplace>         # marketplace
openclaw plugins install <plugin> --marketplace <name>  # marketplace (explicit)
openclaw plugins install <plugin> --marketplace https://github.com/<owner>/<repo>

Les mainteneurs testant les installations au moment de la configuration peuvent remplacer les sources d’installation automatique des plugins par des variables d’environnement protégées. Voir Plugin install overrides.

plugins search interroge ClawHub pour trouver des packages de plugins installables et affiche les noms des packages prêts à l’installation. Il recherche les packages de plugins de type code-plugin et bundle-plugin, mais pas les compétences. Utilisez openclaw skills search pour les compétences de ClawHub.

Config includes and invalid-config repair

Si votre section plugins est basée sur un $include à fichier unique, plugins install/update/enable/disable/uninstall écrit directement dans ce fichier inclus et laisse openclaw.json intact. Les inclusions racines, les tableaux d’inclusions et les inclusions avec des substitutions sœurs échouent en mode fermé (fail closed) au lieu d’être aplaties. Voir Config includes pour les formes prises en charge.

Si la configuration est invalide lors de l’installation, plugins install échoue normalement en mode fermé et vous invite à exécuter d’abord openclaw doctor --fix. Lors du démarrage et du rechargement à chaud de Gateway, une configuration de plugin invalide échoue en mode fermé comme toute autre configuration invalide ; openclaw doctor --fix peut mettre en quarantaine l’entrée de plugin invalide. La seule exception documentée au moment de l’installation est un chemin étroit de récupération pour les plugins groupés qui optent explicitement pour openclaw.install.allowInvalidConfigRecovery.

--force and reinstall vs update

--forceClawHubnpmnpm réutilise la cible d’installation existante et écrase à la place un plugin ou un pack de hooks déjà installé. Utilisez-le lorsque vous réinstallez intentionnellement le même identifiant à partir d’un nouveau chemin local, d’une archive, d’un package ClawHub ou d’un artefact npm. Pour les mises à niveau de routine d’un plugin npm déjà suivi, préférez `openclaw plugins update

Si vous exécutez `plugins install`OpenClaw pour un identifiant de plugin déjà installé, OpenClaw s'arrête et vous dirige vers `plugins update

pour une mise à niveau normale, ou versplugins install

—force` lorsque vous souhaitez véritablement écraser l’installation actuelle à partir d’une source différente.

--pin scope

--pinnpm s’applique uniquement aux installations npm. Il n’est pas pris en charge avec les installations git: ; utilisez une référence git explicite telle que git:github.com/acme/[email protected] lorsque vous souhaitez une source épinglée. Il n’est pas pris en charge avec --marketplacenpm, car les installations de marketplace conservent les métadonnées de source de la marketplace au lieu d’une spécification npm.

--dangerously-force-unsafe-install

--dangerously-force-unsafe-install est une option de dernier recours pour les faux positifs dans l’analyse de code dangereux intégrée. Elle permet à l’installation de se poursuivre même lorsque l’analyse intégrée signale des résultats critical, mais elle ne contourne pas les blocages de stratégie de hook du plugin before_install et ne contourne pas les échecs de l’analyse.

Les analyses d’installation ignorent les fichiers et répertoires de test courants tels que tests/, __tests__/, *.test.* et *.spec.* pour éviter de bloquer les simulacres de test empaquetés ; les points d’entrée d’exécution de plugin déclarés sont toujours analysés même s’ils utilisent l’un de ces noms.

Ce drapeau CLI s’applique aux flux d’installation/de mise à jour de plugins. Les installations de dépendances de compétences soutenues par Gateway utilisent la substitution de requête dangerouslyForceUnsafeInstall correspondante, tandis que openclaw skills install reste un flux de téléchargement/installation de compétence ClawHub distinct.

Si un plugin que vous avez publié sur ClawHub est masqué ou bloqué par une analyse de registre, suivez les étapes de l’éditeur dans Publication ClawHub. --dangerously-force-unsafe-install n’affecte que les installations sur votre propre machine ; il ne demande pas à ClawHub de réanalyser le plugin ou de rendre une version bloquée publique.

Hook packs et npm specs

plugins install est également la surface d’installation pour les hook packs qui exposent openclaw.hooks dans package.json. Utilisez openclaw hooks pour la visibilité filtrée des hooks et l’activation par hook, et non pour l’installation de packages.

Les specs npm sont uniquement de registre (nom du package + version exacte optionnelle ou dist-tag). Les specs Git/URL/fichier et les plages semver sont rejetées. Les installations de dépendances s’exécutent dans un projet npm géré par plugin avec --ignore-scripts pour la sécurité, même lorsque votre shell possède des paramètres d’installation npmOpenClaw globaux. Les projets npm de plugins gérés héritent des npmoverrides npm au niveau du package d’npm, donc les épingles de sécurité de l’hôte s’appliquent également aux dépendances de plugins hissées.

Utilisez `npm:

` lorsque vous souhaitez rendre la résolution Discord explicite. Les specs de package nus s’installent également directement depuis OpenClaw lors du basculement de lancement, sauf s’ils correspondent à un identifiant de plugin officiel.

Les specs de package `@openclaw/*` brutes qui correspondent à des plugins groupés sont résolues vers la copie groupée détenue par l'image avant le repli vers npm. Par exemple, `openclaw plugins install @openclaw/[email protected] --pin` utilise le plugin npm groupé de la version actuelle d'OpenClawnpm au lieu de créer un remplacement OpenClaw géré. Pour forcer le package npm externe, utilisez `openclaw plugins install npm:@openclaw/[email protected] --pin`.

Les specs nues et `@latest` restent sur la voie stable. Les versions de correction d'OpenClaw horodatées telles que `2026.5.3-1` sont des versions stables pour cette vérification. Si OpenClaw résout l'un ou l'autre vers une préversion, API s'arrête et vous demande d'accepter explicitement avec une balise de préversion telle que `@beta`/`@rc` ou une version de préversion exacte telle que `@1.2.3-beta.4`.

Pour les installations OpenClaw sans version exacte (`npm:

ounpm:

@latest), OpenClaw vérifie les métadonnées du package résolu avant l'installation. Si le dernier package stable nécessite une API de plugin OpenClawnpm plus récente ou une version d'hôte minimale, npm inspecte les versions stables plus anciennes et installe à la place la dernière version compatible. Les versions exactes et les dist-tags explicites tels que @beta` restent stricts : si le package sélectionné est incompatible, la commande échoue et vous demande de mettre à jour npm ou de choisir une version compatible.

Si une spec d'installation nue correspond à un identifiant de plugin officiel (par exemple `diffs`), npm installe directement l'entrée du catalogue. Pour installer un package npm portant le même nom, utilisez une spec avec portée explicite (par exemple `@scope/diffs`).

Dépôts Git

Utilisez `git:

pour installer directement depuis un dépôt git. Les formats pris en charge incluentgit:github.com/owner/repo, git:owner/repo, le https://complet,ssh://, git://, file://etgit@host:owner/repo.gitles URL de clone. Ajoutez@

ou#

` pour extraire une branche, une balise ou un commit avant l’installation.

Les installations git clonent dans un répertoire temporaire, extraient la référence demandée si elle est présente, puis utilisent le programme d'installation normal du répertoire de plugins. Cela signifie que la validation du manifeste, l'analyse de code dangereux, le travail d'installation du gestionnaire de packages et les enregistrements d'installation se comportent comme les installations npm. Les installations git enregistrées incluent l'URL/référence source plus le commit résolu afin que `openclaw plugins update` puisse résoudre à nouveau la source ultérieurement.

Après l'installation depuis git, utilisez `openclaw plugins inspect

—runtime —jsonpour vérifier les enregistrements d'exécution tels que les méthodes de passerelle et les commandes CLI. Si le plugin a enregistré une racine CLI avecapi.registerCli, exécutez cette commande directement via la racine OpenClaw CLI, par exemple openclaw demo-plugin ping`.

Abréviation de la marketplace

Utilisez la forme abrégée plugin@marketplace lorsque le nom de la place de marché existe dans le cache du registre local de Claude à ~/.claude/plugins/known_marketplaces.json :

openclaw plugins marketplace list <marketplace-name>
openclaw plugins install <plugin-name>@<marketplace-name>

Utilisez --marketplace lorsque vous souhaitez spécifier explicitement la source de la place de marché :

openclaw plugins install <plugin-name> --marketplace <marketplace-name>
openclaw plugins install <plugin-name> --marketplace <owner/repo>
openclaw plugins install <plugin-name> --marketplace https://github.com/<owner>/<repo>
openclaw plugins install <plugin-name> --marketplace ./my-marketplace

un nom de place de marché connue de Claude issu de ~/.claude/plugins/known_marketplaces.json
un chemin racine local vers une place de marché ou un chemin marketplace.json
un raccourci de dépôt GitHub tel que owner/repo
une URL de dépôt GitHub telle que https://github.com/owner/repo
une URL git

Pour les chemins locaux et les archives, OpenClaw détecte automatiquement :

plugins natifs OpenClaw (openclaw.plugin.json)
bundles compatibles Codex (.codex-plugin/plugin.json)
Bundles compatibles avec Claude (.claude-plugin/plugin.json ou la disposition par défaut des composants Claude)
Bundles compatibles avec Cursor (.cursor-plugin/plugin.json)

Liste

openclaw plugins list
openclaw plugins list --enabled
openclaw plugins list --verbose
openclaw plugins list --json
openclaw plugins search <query>
openclaw plugins search <query> --limit 20
openclaw plugins search <query> --json

Afficher uniquement les plugins activés. Passer de la vue tableau à des lignes de détail par plugin avec les métadonnées source/origine/version/activation. Inventaire lisible par machine ainsi que diagnostics de registre et état d'installation des dépendances de package.

Note

plugins list lit d’abord le registre local persistant des plugins, avec une solution de repli dérivée uniquement à partir du manifeste lorsque le registre est manquant ou invalide. C’est utile pour vérifier si un plugin est installé, activé et visible pour la planification du démarrage à froid, mais ce n’est pas une sonde runtime en direct d’un processus Gateway déjà en cours d’exécution. Après avoir modifié le code du plugin, l’activation, la politique de hook ou plugins.load.paths, redémarrez le Gateway qui sert le channel avant de vous attendre à ce que le nouveau register(api) ou les hooks s’exécutent. Pour les déploiements distants/conteneurs, vérifiez que vous redémarrez bien l’enfant openclaw gateway run réel, et pas seulement un processus wrapper.

plugins list --json inclut les dependencyStatus de chaque plugin à partir de package.json dependencies et optionalDependencies. OpenClaw vérifie si ces noms de packages sont présents le long du chemin de recherche Node node_modules normal du plugin ; il n’importe pas le code runtime du plugin, n’exécute pas de gestionnaire de packages, ni ne répare les dépendances manquantes.

plugins search est une recherche distante dans le catalogue ClawHub. Il n’inspecte pas l’état local, ne modifie pas la configuration, n’installe pas de packages, ni ne charge le code runtime du plugin. Les résultats de recherche incluent le nom du package ClawHub, la famille, le channel, la version, le résumé et un indice d’installation tel que openclaw plugins install clawhub:<package>.

Pour que les plugins groupés fonctionnent dans une image Docker empaquetée, montez en liaison le répertoire source du plugin sur le chemin source empaqueté correspondant, tel que /app/extensions/synology-chat. OpenClaw découvrira cette superposition source montée avant /app/dist/extensions/synology-chat ; un répertoire source copié tel quel reste inerte, de sorte que les installations empaquetées normales utilisent toujours la version compilée dist.

Pour le débogage des hooks d’exécution :

openclaw plugins inspect <id> --runtime --json affiche les hooks enregistrés et les diagnostics d’une passe d’inspection par chargement de module. L’inspection d’exécution n’installe jamais les dépendances ; utilisez openclaw doctor --fix pour nettoyer l’état des dépendances héritées ou pour récupérer les plugins téléchargeables manquants qui sont référencés par la configuration.
openclaw gateway status --deep --require-rpc confirme l’URL/le profil Gateway accessible, les indicateurs de service/processus, le chemin de configuration et l’état de santé RPC.
Les hooks de conversation non groupés (llm_input, llm_output, before_model_resolve, before_agent_reply, before_agent_run, before_agent_finalize, agent_end) nécessitent plugins.entries.<id>.hooks.allowConversationAccess=true.

Utilisez --link pour éviter de copier un répertoire local (ajoute à plugins.load.paths) :

openclaw plugins install -l ./my-plugin

Les fichiers de plugin autonomes doivent être listés dans plugins.load.paths plutôt que placés directement dans ~/.openclaw/extensions ou <workspace>/.openclaw/extensions. Ces racines détectées automatiquement chargent les répertoires de packages ou de bundles de plugins, tandis que les fichiers de script de premier niveau sont traités comme des helpers locaux et ignorés.

Note

Les plugins d’origine de l’espace de travail découverts à partir d’une racine d’extensions de l’espace de travail ne sont ni importés ni exécutés tant qu’ils ne sont pas explicitement activés. Pour un développement local, exécutez `openclaw plugins enable

ou définissezplugins.entries.

.enabled: true; si votre configuration utilise plugins.allow, incluez-y également le même identifiant de plugin. Cette règle de refus par défaut (fail-closed) s'applique également lorsque la configuration du canal cible explicitement un plugin d'origine de l'espace de travail pour un chargement configuration uniquement, de sorte que le code de configuration du plugin de canal local ne s'exécutera pas tant que ce plugin de l'espace de travail reste désactivé ou exclu de la liste autorisée. Les installations liées et les entrées plugins.load.paths` explicites suivent la politique normale pour leur origine de plugin résolue. Voir Configurer la politique de plugin et Référence de configuration.

--force n’est pas pris en charge avec --link car les installations liées réutilisent le chemin source au lieu de copier sur une cible d’installation gérée.

Utilisez --pinnpm sur les installations npm pour enregistrer la spécification exacte résolue (name@version) dans l’index de plugins géré tout en gardant le comportement par défaut non épinglé.

Index des plugins

Les métadonnées d’installation de plugin sont un état géré par la machine, et non une configuration utilisateur. Les installations et les mises à jour les écrivent dans la base de données d’état SQLite partagée sous le répertoire d’état actif d’OpenClaw. La ligne OpenClawinstalled_plugin_index stocke des métadonnées installRecords durables, y compris des enregistrements pour les manifestes de plugin brisés ou manquants, plus un cache de registre à froid dérivé du manifeste utilisé par openclaw plugins update, la désinstallation, les diagnostics et le registre de plugins à froid.

Lorsqu’OpenClaw voit des enregistrements hérités expédiés OpenClawplugins.installs dans la configuration, les lectures d’exécution les traitent comme une entrée de compatibilité sans réécrire openclaw.json. Les écritures de plugin explicites et openclaw doctor --fix déplacent ces enregistrements dans l’index de plugin et suppriment la clé de configuration lorsque les écritures de configuration sont autorisées; si l’une ou l’autre écriture échoue, les enregistrements de configuration sont conservés afin que les métadonnées d’installation ne soient pas perdues.

Désinstaller

openclaw plugins uninstall <id>
openclaw plugins uninstall <id> --dry-run
openclaw plugins uninstall <id> --keep-files

uninstall supprime les enregistrements de plugins de plugins.entries, l’index de plugins persisté, les entrées de la liste d’autorisation/refus de plugins, et les entrées plugins.load.paths liées, le cas échéant. Sauf si --keep-files est défini, la désinstallation supprime également le répertoire d’installation géré suiv lorsqu’il se trouve à la racine des extensions de plugins de OpenClaw. Pour les plugins en mémoire actifs, l’emplacement mémoire est réinitialisé à memory-core.

Mettre à jour

openclaw plugins update <id-or-npm-spec>
openclaw plugins update --all
openclaw plugins update <id-or-npm-spec> --dry-run
openclaw plugins update @openclaw/voice-call
openclaw plugins update openclaw-codex-app-server --dangerously-force-unsafe-install

Les mises à jour s’appliquent aux installations de plugins suivies dans l’index de plugins géré et aux installations de packs de hooks suivies dans hooks.internal.installs.

Résolution de l'id de plugin par rapport à la spec npm

Lorsque vous transmettez un id de plugin, OpenClaw réutilise la spec d’installation enregistrée pour ce plugin. Cela signifie que les dist-tags précédemment stockés, tels que @beta et les versions exactes épinglées, continuent d’être utilisés lors des exécutions ultérieures de `update

Pour les installations npm, vous pouvez également transmettre une spec de package npm explicite avec un dist-tag ou une version exacte. OpenClaw résout ce nom de package vers l'enregistrement de plugin suivi, met à jour ce plugin installé et enregistre la nouvelle spec npm pour les futures mises à jour basées sur l'id.

Transmettre le nom du package npm sans version ni tag permet également de revenir à l'enregistrement de plugin suivi. Utilisez cette option lorsqu'un plugin a été épinglé à une version exacte et que vous souhaitez le ramener à la ligne de publication par défaut du registre.

Mises à jour du canal bêta

openclaw plugins update réutilise la spécification du plugin suivie, sauf si vous passez une nouvelle spécification. openclaw update connaît également le canal de mise à jour OpenClaw actif : sur le canal bêta, les enregistrements de plugins par défaut de npm et ClawHub essaient d’abord @beta. Ils reviennent à la spécification par défaut/dernière enregistrée si aucune version bêta de plugin n’existe ; les plugins npm reviennent également lorsque le package bêta existe mais échoue à la validation d’installation. Ce repli est signalé par un avertissement et ne fait pas échouer la mise à jour principale. Les versions exactes et les balises explicites restent épinglées à ce sélecteur.

Vérifications des versions et dérive de l'intégrité

Avant une mise à jour en direct de npm, OpenClaw vérifie la version du package installée par rapport aux métadonnées du registre npm. Si la version installée et l’identité de l’artefact enregistré correspondent déjà à la cible résolue, la mise à jour est ignorée sans téléchargement, réinstallation ou réécriture de openclaw.json.

Lorsqu’un hachage d’intégrité stocké existe et que le hachage de l’artefact récupéré change, OpenClaw considère cela comme une dérive de l’artefact npm. La commande interactive openclaw plugins update imprime les hachages attendus et réels et demande confirmation avant de continuer. Les assistants de mise à jour non interactifs échouent en mode fermé, sauf si l’appelant fournit une stratégie de continuation explicite.

--dangerously-force-unsafe-install lors de la mise à jour

--dangerously-force-unsafe-install est également disponible sur plugins update en tant que substitut de dernier recours pour les faux positifs de l’analyse de code dangereux intégrée lors des mises à jour de plugins. Il ne contourne toujours pas les blocages de stratégie before_install des plugins ou le blocage en cas d’échec de l’analyse, et il ne s’applique qu’aux mises à jour de plugins, pas aux mises à jour des packs de hooks.

Inspecter

openclaw plugins inspect <id>
openclaw plugins inspect <id> --runtime
openclaw plugins inspect <id> --json

Inspect affiche l’identité, l’état de chargement, la source, les capacités du manifeste, les indicateurs de stratégie, les diagnostics, les métadonnées d’installation, les capacités du bundle et toute prise en charge détectée des serveurs MCP ou LSP sans importer le runtime du plugin par défaut. Ajoutez --runtime pour charger le module du plugin et inclure les hooks, outils, commandes, services, méthodes de passerelle et routes HTTP enregistrés. L’inspection du runtime signale directement les dépendances de plugin manquantes ; les installations et réparations restent dans openclaw plugins install, openclaw plugins update et openclaw doctor --fix.

Les commandes CLI détenues par des plugins sont généralement installées en tant que groupes de commandes racine CLIopenclaw, mais les plugins peuvent également enregistrer des commandes imbriquées sous un parent principal tel que openclaw nodes. Une fois que inspect --runtime affiche une commande sous cliCommands, exécutez-la au chemin indiqué ; par exemple, un plugin qui enregistre demo-git peut être vérifié avec openclaw demo-git ping.

Chaque plugin est classé selon ce qu’il enregistre réellement lors de l’exécution :

plain-capability — un type de capacité (ex. un plugin de type provider uniquement)
hybrid-capability — plusieurs types de capacités (ex. texte + parole + images)
hook-only — uniquement des hooks, aucune capacité ni surface
non-capability — outils/commandes/services mais aucune capacité

Voir Plugin shapes pour plus d’informations sur le modèle de capacité.

Doctor

openclaw plugins doctor

doctor signale les erreurs de chargement des plugins, les diagnostics de manifeste/découverte, les avis de compatibilité et les références de configuration de plugin obsolètes telles que les emplacements de plugin manquants. Lorsque l’arborescence d’installation et la configuration du plugin sont propres, il imprime No plugin issues detected. Si une configuration obsolète reste mais que l’arborescence d’installation est autrement saine, le résumé l’indique au lieu d’impliquer une santé complète du plugin.

Si un plugin configuré est présent sur le disque mais bloqué par les vérifications de sécurité du chemin du chargeur, la validation de la configuration conserve l’entrée du plugin et le signale comme present but blocked. Corrigez le diagnostic précédent de plugin bloqué, tel que la propriété du chemin ou les autorisations d’écriture mondiales, au lieu de supprimer la configuration plugins.entries.<id> ou plugins.allow.

En cas d’échecs de structure de module tels que des exportations register/activate manquantes, réexécutez avec OPENCLAW_PLUGIN_LOAD_DEBUG=1 pour inclure un résumé compact de la structure des exportations dans la sortie de diagnostic.

Registre

openclaw plugins registry
openclaw plugins registry --refresh
openclaw plugins registry --json

Le registre local de plugins est le modèle de lecture à froid persistant d’OpenClaw pour l’identité des plugins installés, leur activation, les métadonnées source et la propriété des contributions. Le démarrage normal, la recherche du propriétaire du provider, la classification de la configuration du channel et l’inventaire des plugins peuvent le lire sans importer les modules d’exécution des plugins.

Utilisez plugins registry pour inspecter si le registre persistant est présent, à jour ou périmé. Utilisez --refresh pour le reconstruire à partir de l’index de plugin persistant, de la stratégie de configuration et des métadonnées de manifeste/package. Il s’agit d’un chemin de réparation, et non d’un chemin d’activation à l’exécution.

openclaw doctor --fix répare également la dérive du npm géré adjacent au registre : si un package @openclaw/* orphelin ou récupéré sous un projet de plugin npm géré ou si la racine npm gérée plate héritée masque un plugin groupé, le docteur supprime ce package périmé et reconstruit le registre afin que le démarrage se valide par rapport au manifeste groupé. Le docteur relie également le package hôte openclaw aux plugins npm gérés qui déclarent peerDependencies.openclaw, afin que les importations d’exécution locales au package telles que openclaw/plugin-sdk/* se résolvent après les mises à jour ou les réparations npm.

Place de marché

openclaw plugins marketplace list <source>
openclaw plugins marketplace list <source> --json

La liste du Marketplace accepte un chemin local vers le marketplace, un chemin marketplace.json, un raccourci GitHub comme owner/repo, une URL de dépôt GitHub ou une URL git. --json affiche l’étiquette de source résolue ainsi que le manifeste du marketplace analysé et les entrées des plugins.