CLI commands
Plugins
Gateway-Plugins, Hook-Pakete und kompatible Bundles verwalten.
Endbenutzerleitfaden zum Installieren, Aktivieren und Beheben von Problemen mit Plugins.
Kurzbeispiele für Installation, Auflisten, Aktualisierung, Deinstallation und Veröffentlichung.
Bundle-Kompatibilitätsmodell.
Manifestfelder und Konfigurationsschema.
Sicherheitshärtung für Plugin-Installationen.
Befehle
openclaw plugins listopenclaw plugins list --enabledopenclaw plugins list --verboseopenclaw plugins list --jsonopenclaw plugins search <query>openclaw plugins search <query> --limit 20openclaw plugins search <query> --jsonopenclaw plugins install <path-or-spec>openclaw plugins inspect <id>openclaw plugins inspect <id> --runtimeopenclaw plugins inspect <id> --jsonopenclaw plugins inspect --allopenclaw plugins info <id>openclaw plugins enable <id>openclaw plugins disable <id>openclaw plugins registryopenclaw plugins registry --refreshopenclaw plugins uninstall <id>openclaw plugins doctoropenclaw plugins update <id-or-npm-spec>openclaw plugins update --allopenclaw plugins marketplace list <marketplace>openclaw plugins marketplace list <marketplace> --jsonFühren Sie zur Untersuchung langsamer Installations-, Prüf-, Deinstallations- oder Registry-Aktualisierungsvorgänge den
Befehl mit OPENCLAW_PLUGIN_LIFECYCLE_TRACE=1 aus. Der Trace schreibt Phasenzeiten
nach stderr und sorgt dafür, dass JSON-Ausgaben weiterhin parsebar bleiben. Siehe Debugging.
Installation
openclaw plugins search "calendar" # search ClawHub pluginsopenclaw plugins install <package> # npm by defaultopenclaw plugins install clawhub:<package> # ClawHub onlyopenclaw plugins install npm:<package> # npm onlyopenclaw plugins install npm-pack:<path.tgz> # local npm pack through npm install semanticsopenclaw plugins install git:github.com/<owner>/<repo> # git repoopenclaw plugins install git:github.com/<owner>/<repo>@<ref>openclaw plugins install <package> --force # overwrite existing installopenclaw plugins install <package> --pin # pin versionopenclaw plugins install <package> --dangerously-force-unsafe-installopenclaw plugins install <path> # local pathopenclaw plugins install <plugin>@<marketplace> # marketplaceopenclaw plugins install <plugin> --marketplace <name> # marketplace (explicit)openclaw plugins install <plugin> --marketplace https://github.com/<owner>/<repo>Maintainer, die Installationen zur Einrichtungszeit testen, können automatische Plugin-Installationsquellen mit geschützten Umgebungsvariablen überschreiben. Siehe Überschreibungen für Plugin-Installationen.
plugins search fragt ClawHub nach installierbaren Plugin-Paketen ab und gibt
installationsbereite Paketnamen aus. Es durchsucht Code-Plugin- und Bundle-Plugin-Pakete,
nicht Skills. Verwenden Sie openclaw skills search für ClawHub-Skills.
Config-Includes und Reparatur ungültiger Konfiguration
Wenn Ihr Abschnitt plugins durch ein einzeiliges $include abgesichert ist, schreiben plugins install/update/enable/disable/uninstall in diese eingebundene Datei durch und lassen openclaw.json unverändert. Root-Includes, Include-Arrays und Includes mit benachbarten Überschreibungen schlagen geschlossen fehl, statt zusammengeführt zu werden. Siehe Config-Includes für die unterstützten Formen.
Wenn die Konfiguration während der Installation ungültig ist, schlägt plugins install normalerweise geschlossen fehl und weist Sie an, zuerst openclaw doctor --fix auszuführen. Beim Gateway-Start und Hot Reload schlägt ungültige Plugin-Konfiguration wie jede andere ungültige Konfiguration geschlossen fehl; openclaw doctor --fix kann den ungültigen Plugin-Eintrag isolieren. Die einzige dokumentierte Ausnahme zur Installationszeit ist ein enger Wiederherstellungspfad für gebündelte Plugins, die sich explizit für openclaw.install.allowInvalidConfigRecovery entscheiden.
--force und Neuinstallation gegenüber Aktualisierung
--force verwendet das vorhandene Installationsziel wieder und überschreibt ein bereits installiertes Plugin oder Hook-Paket direkt. Verwenden Sie es, wenn Sie bewusst dieselbe ID aus einem neuen lokalen Pfad, Archiv, ClawHub-Paket oder npm-Artefakt neu installieren. Für routinemäßige Upgrades eines bereits verfolgten npm-Plugins bevorzugen Sie openclaw plugins update <id-or-npm-spec>.
Wenn Sie plugins install für eine bereits installierte Plugin-ID ausführen, stoppt OpenClaw und verweist Sie für ein normales Upgrade auf plugins update <id-or-npm-spec> oder auf plugins install <package> --force, wenn Sie die aktuelle Installation wirklich aus einer anderen Quelle überschreiben möchten.
Geltungsbereich von --pin
--pin gilt nur für npm-Installationen. Es wird mit git:-Installationen nicht unterstützt; verwenden Sie eine explizite Git-Referenz wie git:github.com/acme/plugin@v1.2.3, wenn Sie eine angeheftete Quelle möchten. Es wird mit --marketplace nicht unterstützt, weil Marketplace-Installationen Marketplace-Quellenmetadaten statt einer npm-Spezifikation speichern.
--dangerously-force-unsafe-install
--dangerously-force-unsafe-install ist eine Notfalloption für False Positives im integrierten Scanner für gefährlichen Code. Sie ermöglicht, dass die Installation fortgesetzt wird, auch wenn der integrierte Scanner critical-Funde meldet, umgeht aber keine Policy-Blockierungen durch Plugin-before_install-Hooks und umgeht keine Scan-Fehler.
Dieses CLI-Flag gilt für Plugin-Installations- und Aktualisierungsabläufe. Gateway-gestützte Skill-Abhängigkeitsinstallationen verwenden die entsprechende Anforderungsüberschreibung dangerouslyForceUnsafeInstall, während openclaw skills install ein separater ClawHub-Download-/Installationsablauf für Skills bleibt.
Wenn ein von Ihnen auf ClawHub veröffentlichtes Plugin durch einen Registry-Scan blockiert wird, verwenden Sie die Publisher-Schritte in ClawHub.
Hook-Pakete und npm-Spezifikationen
plugins install ist auch die Installationsfläche für Hook-Pakete, die openclaw.hooks in package.json bereitstellen. Verwenden Sie openclaw hooks für gefilterte Hook-Sichtbarkeit und Aktivierung pro Hook, nicht für Paketinstallation.
Npm-Spezifikationen sind nur Registry (Paketname plus optionale exakte Version oder dist-tag). Git-/URL-/Dateispezifikationen und Semver-Bereiche werden abgelehnt. Abhängigkeitsinstallationen laufen projektnah mit --ignore-scripts zur Sicherheit, auch wenn Ihre Shell globale npm-Installationseinstellungen hat. Verwaltete Plugin-npm-Roots erben die npm-overrides auf Paketebene von OpenClaw, sodass Host-Sicherheitspins auch auf gehoistete Plugin-Abhängigkeiten angewendet werden.
Verwenden Sie npm:<package>, wenn Sie die npm-Auflösung explizit machen möchten. Bloße Paketspezifikationen installieren während der Launch-Umstellung ebenfalls direkt aus npm.
Bloße Spezifikationen und @latest bleiben auf dem stabilen Track. OpenClaw-Korrekturversionen mit Datumsstempel wie 2026.5.3-1 sind für diese Prüfung stabile Releases. Wenn npm eine davon zu einem Prerelease auflöst, stoppt OpenClaw und fordert Sie auf, sich explizit mit einem Prerelease-Tag wie @beta/@rc oder einer exakten Prerelease-Version wie @1.2.3-beta.4 anzumelden.
Wenn eine bloße Installationsspezifikation einer offiziellen Plugin-ID entspricht (zum Beispiel diffs), installiert OpenClaw den Katalogeintrag direkt. Um ein npm-Paket mit demselben Namen zu installieren, verwenden Sie eine explizite scoped-Spezifikation (zum Beispiel @scope/diffs).
Git-Repositorys
Verwenden Sie git:<repo>, um direkt aus einem Git-Repository zu installieren. Unterstützte Formen umfassen git:github.com/owner/repo, git:owner/repo, vollständige https://-, ssh://-, git://-, file://- und git@host:owner/repo.git-Clone-URLs. Fügen Sie @<ref> oder #<ref> hinzu, um vor der Installation einen Branch, ein Tag oder einen Commit auszuchecken.
Git-Installationen klonen in ein temporäres Verzeichnis, checken die angeforderte Referenz aus, wenn vorhanden, und verwenden dann den normalen Plugin-Verzeichnisinstaller. Das bedeutet, dass Manifestvalidierung, Scannen auf gefährlichen Code, Paketmanager-Installationsarbeit und Installationsdatensätze sich wie bei npm-Installationen verhalten. Aufgezeichnete Git-Installationen enthalten die Quell-URL/-Referenz sowie den aufgelösten Commit, damit openclaw plugins update die Quelle später erneut auflösen kann.
Verwenden Sie nach der Installation aus Git openclaw plugins inspect <id> --runtime --json, um Runtime-Registrierungen wie Gateway-Methoden und CLI-Befehle zu überprüfen. Wenn das Plugin mit api.registerCli eine CLI-Root registriert hat, führen Sie diesen Befehl direkt über die OpenClaw-Root-CLI aus, zum Beispiel openclaw demo-plugin ping.
Archive
Unterstützte Archive: .zip, .tgz, .tar.gz, .tar. Native OpenClaw-Plugin-Archive müssen ein gültiges openclaw.plugin.json im extrahierten Plugin-Root enthalten; Archive, die nur package.json enthalten, werden abgelehnt, bevor OpenClaw Installationsdatensätze schreibt.
Verwenden Sie npm-pack:<path.tgz>, wenn die Datei ein npm-pack-Tarball ist und Sie
denselben verwalteten npm-Root-Installationspfad testen möchten, der von Registry-Installationen verwendet wird,
einschließlich package-lock.json-Verifizierung, Scannen gehoisteter Abhängigkeiten und
npm-Installationsdatensätzen. Einfache Archivpfade werden weiterhin als lokale Archive
unter dem Plugin-Extensions-Root installiert.
Claude-Marketplace-Installationen werden ebenfalls unterstützt.
ClawHub-Installationen verwenden einen expliziten clawhub:<package>-Locator:
openclaw plugins install clawhub:openclaw-codex-app-serveropenclaw plugins install clawhub:openclaw-codex-app-server@1.2.3Bloße npm-sichere Plugin-Spezifikationen installieren während der Launch-Umstellung standardmäßig aus npm:
openclaw plugins install openclaw-codex-app-serverVerwenden Sie npm:, um eine reine npm-Auflösung explizit zu machen:
openclaw plugins install npm:openclaw-codex-app-serveropenclaw plugins install npm:@scope/plugin-name@1.0.1OpenClaw prüft die beworbene Plugin-API / Mindestkompatibilität mit dem Gateway vor der Installation. Wenn die ausgewählte ClawHub-Version ein ClawPack-Artefakt veröffentlicht, lädt OpenClaw das versionierte npm-pack-.tgz herunter, verifiziert den ClawHub-Digest-Header und den Artefakt-Digest und installiert es anschließend über den normalen Archivpfad. Ältere ClawHub-Versionen ohne ClawPack-Metadaten werden weiterhin über den Legacy-Verifizierungspfad für Paketarchive installiert. Aufgezeichnete Installationen behalten ihre ClawHub-Quellmetadaten, Artefaktart, npm-Integrität, npm-Shasum, Tarball-Namen und ClawPack-Digest-Fakten für spätere Updates.
Unversionierte ClawHub-Installationen behalten eine unversionierte aufgezeichnete Spezifikation, damit openclaw plugins update neueren ClawHub-Releases folgen kann; explizite Versions- oder Tag-Selektoren wie clawhub:pkg@1.2.3 und clawhub:pkg@beta bleiben an diesen Selektor gepinnt.
Marketplace-Kurzschreibweise
Verwenden Sie die Kurzschreibweise plugin@marketplace, wenn der Marketplace-Name in Claudes lokalem Registry-Cache unter ~/.claude/plugins/known_marketplaces.json vorhanden ist:
openclaw plugins marketplace list <marketplace-name>openclaw plugins install <plugin-name>@<marketplace-name>Verwenden Sie --marketplace, wenn Sie die Marketplace-Quelle explizit übergeben möchten:
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-marketplaceMarketplace-Quellen
- ein Claude-Name für bekannte Marketplaces aus
~/.claude/plugins/known_marketplaces.json - ein lokales Marketplace-Stammverzeichnis oder ein
marketplace.json-Pfad - eine GitHub-Repo-Kurzschreibweise wie
owner/repo - eine GitHub-Repo-URL wie
https://github.com/owner/repo - eine Git-URL
Regeln für Remote-Marketplaces
Bei Remote-Marketplaces, die von GitHub oder Git geladen werden, müssen Plugin-Einträge innerhalb des geklonten Marketplace-Repositorys bleiben. OpenClaw akzeptiert relative Pfadquellen aus diesem Repository und lehnt HTTP(S)-, absolute Pfad-, Git-, GitHub- und andere Nicht-Pfad-Plugin-Quellen aus Remote-Manifesten ab.
Für lokale Pfade und Archive erkennt OpenClaw automatisch:
- native OpenClaw-Plugins (
openclaw.plugin.json) - Codex-kompatible Bundles (
.codex-plugin/plugin.json) - Claude-kompatible Bundles (
.claude-plugin/plugin.jsonoder das standardmäßige Claude-Komponentenlayout) - Cursor-kompatible Bundles (
.cursor-plugin/plugin.json)
Auflisten
openclaw plugins listopenclaw plugins list --enabledopenclaw plugins list --verboseopenclaw plugins list --jsonopenclaw plugins search <query>openclaw plugins search <query> --limit 20openclaw plugins search <query> --json--enabledbooleanNur aktivierte Plugins anzeigen.
--verbosebooleanVon der Tabellenansicht zu Detailzeilen pro Plugin mit Quell-/Ursprungs-/Versions-/Aktivierungsmetadaten wechseln.
--jsonbooleanMaschinenlesbares Inventar plus Registry-Diagnosen und Installationsstatus von Paketabhängigkeiten.
plugins search ist eine Remote-ClawHub-Katalogsuche. Sie prüft keinen lokalen
Zustand, ändert keine Konfiguration, installiert keine Pakete und lädt keinen
Plugin-Runtime-Code. Suchergebnisse enthalten den ClawHub-Paketnamen, Familie,
Kanal, Version, Zusammenfassung und einen Installationshinweis wie
openclaw plugins install clawhub:<package>.
Für Arbeiten an gebündelten Plugins innerhalb eines paketierten Docker-Images hängen Sie das
Plugin-Quellverzeichnis per Bind-Mount über den passenden paketierten Quellpfad ein, z. B.
/app/extensions/synology-chat. OpenClaw erkennt dieses eingehängte Quell-Overlay
vor /app/dist/extensions/synology-chat; ein einfach kopiertes Quellverzeichnis
bleibt inaktiv, sodass normale paketierte Installationen weiterhin die kompilierte Dist verwenden.
Für das Debugging von Runtime-Hooks:
openclaw plugins inspect <id> --runtime --jsonzeigt registrierte Hooks und Diagnosen aus einem Inspektionsdurchlauf mit geladenem Modul. Die Runtime-Inspektion installiert niemals Abhängigkeiten; verwenden Sieopenclaw doctor --fix, um Legacy-Abhängigkeitszustände zu bereinigen oder fehlende herunterladbare Plugins wiederherzustellen, auf die in der Konfiguration verwiesen wird.openclaw gateway status --deep --require-rpcbestätigt das erreichbare Gateway, Dienst-/Prozesshinweise, den Konfigurationspfad und die RPC-Gesundheit.- Nicht gebündelte Konversations-Hooks (
llm_input,llm_output,before_model_resolve,before_agent_reply,before_agent_run,before_agent_finalize,agent_end) erfordernplugins.entries.<id>.hooks.allowConversationAccess=true.
Verwenden Sie --link, um das Kopieren eines lokalen Verzeichnisses zu vermeiden (fügt es zu plugins.load.paths hinzu):
openclaw plugins install -l ./my-pluginPlugin-Index
Plugin-Installationsmetadaten sind maschinenverwalteter Zustand, keine Benutzerkonfiguration. Installationen und Updates schreiben sie in plugins/installs.json im aktiven OpenClaw-Zustandsverzeichnis. Die oberste installRecords-Map ist die dauerhafte Quelle für Installationsmetadaten, einschließlich Datensätzen für defekte oder fehlende Plugin-Manifeste. Das plugins-Array ist der aus Manifesten abgeleitete Kalt-Registry-Cache. Die Datei enthält eine Nicht-bearbeiten-Warnung und wird von openclaw plugins update, Deinstallation, Diagnosen und der Kalt-Plugin-Registry verwendet.
Wenn OpenClaw ausgelieferte Legacy-plugins.installs-Datensätze in der Konfiguration sieht, behandeln Runtime-Lesevorgänge sie als Kompatibilitätseingabe, ohne openclaw.json neu zu schreiben. Explizite Plugin-Schreibvorgänge und openclaw doctor --fix verschieben diese Datensätze in den Plugin-Index und entfernen den Konfigurationsschlüssel, wenn Konfigurationsschreibvorgänge erlaubt sind; wenn einer der Schreibvorgänge fehlschlägt, bleiben die Konfigurationsdatensätze erhalten, damit die Installationsmetadaten nicht verloren gehen.
Deinstallieren
openclaw plugins uninstall <id>openclaw plugins uninstall <id> --dry-runopenclaw plugins uninstall <id> --keep-filesuninstall entfernt Plugin-Datensätze aus plugins.entries, dem persistierten Plugin-Index, Plugin-Zulassungs-/Sperrlisteneinträgen und gegebenenfalls verknüpften plugins.load.paths-Einträgen. Sofern --keep-files nicht gesetzt ist, entfernt die Deinstallation außerdem das verfolgte verwaltete Installationsverzeichnis, wenn es sich im Plugin-Erweiterungsstamm von OpenClaw befindet. Bei Active-Memory-Plugins wird der Speicher-Slot auf memory-core zurückgesetzt.
Aktualisieren
openclaw plugins update <id-or-npm-spec>openclaw plugins update --allopenclaw plugins update <id-or-npm-spec> --dry-runopenclaw plugins update @openclaw/voice-callopenclaw plugins update openclaw-codex-app-server --dangerously-force-unsafe-installUpdates gelten für verfolgte Plugin-Installationen im verwalteten Plugin-Index und verfolgte Hook-Pack-Installationen in hooks.internal.installs.
Plugin-ID im Vergleich zu npm-Spezifikation auflösen
Wenn Sie eine Plugin-ID übergeben, verwendet OpenClaw die aufgezeichnete Installationsspezifikation für dieses Plugin wieder. Das bedeutet, dass zuvor gespeicherte Dist-Tags wie @beta und exakt gepinnte Versionen auch bei späteren update <id>-Läufen weiter verwendet werden.
Für npm-Installationen können Sie auch eine explizite npm-Paketspezifikation mit einem Dist-Tag oder einer exakten Version übergeben. OpenClaw löst diesen Paketnamen auf den verfolgten Plugin-Datensatz zurück, aktualisiert dieses installierte Plugin und zeichnet die neue npm-Spezifikation für künftige ID-basierte Updates auf.
Wenn Sie den npm-Paketnamen ohne Version oder Tag übergeben, wird er ebenfalls auf den verfolgten Plugin-Datensatz zurückaufgelöst. Verwenden Sie dies, wenn ein Plugin auf eine exakte Version gepinnt war und Sie es wieder auf die Standard-Release-Linie der Registry verschieben möchten.
Updates des Beta-Kanals
openclaw plugins update verwendet die verfolgte Plugin-Spezifikation wieder, sofern Sie keine neue Spezifikation übergeben. openclaw update kennt zusätzlich den aktiven OpenClaw-Update-Kanal: Im Beta-Kanal versuchen npm- und ClawHub-Plugin-Datensätze der Standardlinie zuerst @beta und fallen dann auf die aufgezeichnete Standard-/Latest-Spezifikation zurück, wenn kein Plugin-Beta-Release existiert. Dieser Fallback wird als Warnung gemeldet und lässt das Core-Update nicht fehlschlagen. Exakte Versionen und explizite Tags bleiben an diesen Selektor gepinnt.
Versionsprüfungen und Integritätsabweichung
Vor einem Live-npm-Update prüft OpenClaw die installierte Paketversion gegen die npm-Registry-Metadaten. Wenn die installierte Version und die aufgezeichnete Artefaktidentität bereits dem aufgelösten Ziel entsprechen, wird das Update übersprungen, ohne herunterzuladen, neu zu installieren oder openclaw.json neu zu schreiben.
Wenn ein gespeicherter Integritäts-Hash vorhanden ist und sich der Hash des abgerufenen Artefakts ändert, behandelt OpenClaw dies als npm-Artefaktabweichung. Der interaktive Befehl openclaw plugins update gibt die erwarteten und tatsächlichen Hashes aus und fragt nach einer Bestätigung, bevor er fortfährt. Nicht-interaktive Update-Helfer schlagen geschlossen fehl, sofern der Aufrufer keine explizite Fortsetzungsrichtlinie bereitstellt.
--dangerously-force-unsafe-install bei update
--dangerously-force-unsafe-install ist auch bei plugins update als Break-Glass-Override für falsch positive Treffer des eingebauten Scans auf gefährlichen Code während Plugin-Updates verfügbar. Es umgeht weiterhin keine Richtlinienblockaden von Plugin-before_install oder Blockaden durch Scan-Fehler und gilt nur für Plugin-Updates, nicht für Hook-Pack-Updates.
Inspizieren
openclaw plugins inspect <id>openclaw plugins inspect <id> --runtimeopenclaw plugins inspect <id> --jsonInspect zeigt Identität, Ladestatus, Quelle, Manifestfähigkeiten, Richtlinienflags, Diagnosen, Installationsmetadaten, Bundle-Fähigkeiten und erkannte MCP- oder LSP-Server-Unterstützung, ohne standardmäßig Plugin-Runtime zu importieren. Fügen Sie --runtime hinzu, um das Plugin-Modul zu laden und registrierte Hooks, Tools, Befehle, Dienste, Gateway-Methoden und HTTP-Routen einzubeziehen. Die Runtime-Inspektion meldet fehlende Plugin-Abhängigkeiten direkt; Installationen und Reparaturen bleiben in openclaw plugins install, openclaw plugins update und openclaw doctor --fix.
Plugin-eigene CLI-Befehle werden normalerweise als Root-openclaw-Befehlsgruppen installiert, aber Plugins können auch verschachtelte Befehle unter einem Core-Elternbefehl wie openclaw nodes registrieren. Nachdem inspect --runtime einen Befehl unter cliCommands anzeigt, führen Sie ihn unter dem aufgeführten Pfad aus; beispielsweise kann ein Plugin, das demo-git registriert, mit openclaw demo-git ping verifiziert werden.
Jedes Plugin wird danach klassifiziert, was es tatsächlich zur Runtime registriert:
- plain-capability — ein Fähigkeitstyp (z. B. ein reines Provider-Plugin)
- hybrid-capability — mehrere Fähigkeitstypen (z. B. Text + Sprache + Bilder)
- hook-only — nur Hooks, keine Fähigkeiten oder Oberflächen
- non-capability — Tools/Befehle/Dienste, aber keine Fähigkeiten
Weitere Informationen zum Fähigkeitsmodell finden Sie unter Plugin-Formen.
Diagnose
openclaw plugins doctordoctor meldet Plugin-Ladefehler, Manifest-/Discovery-Diagnosen und Kompatibilitätshinweise. Wenn alles sauber ist, gibt es No plugin issues detected. aus.
Wenn ein konfiguriertes Plugin auf dem Datenträger vorhanden ist, aber durch die Pfadsicherheitsprüfungen des Loaders blockiert wird, behält die Konfigurationsvalidierung den Plugin-Eintrag bei und meldet ihn als present but blocked. Beheben Sie die vorherige Diagnose zum blockierten Plugin, etwa Pfadbesitz oder global schreibbare Berechtigungen, statt die Konfiguration plugins.entries.<id> oder plugins.allow zu entfernen.
Bei Modulform-Fehlern wie fehlenden register-/activate-Exporten führen Sie den Befehl erneut mit OPENCLAW_PLUGIN_LOAD_DEBUG=1 aus, um eine kompakte Zusammenfassung der Exportform in die Diagnoseausgabe aufzunehmen.
Registry
openclaw plugins registryopenclaw plugins registry --refreshopenclaw plugins registry --jsonDie lokale Plugin-Registry ist das persistierte Cold-Read-Modell von OpenClaw für installierte Plugin-Identität, Aktivierungsstatus, Quellmetadaten und Beitragsverantwortung. Normaler Start, Provider-Owner-Lookup, Klassifizierung der Channel-Einrichtung und Plugin-Inventar können sie lesen, ohne Plugin-Runtime-Module zu importieren.
Verwenden Sie plugins registry, um zu prüfen, ob die persistierte Registry vorhanden, aktuell oder veraltet ist. Verwenden Sie --refresh, um sie aus dem persistierten Plugin-Index, der Konfigurationsrichtlinie und Manifest-/Paketmetadaten neu aufzubauen. Dies ist ein Reparaturpfad, kein Runtime-Aktivierungspfad.
openclaw doctor --fix repariert außerdem Registry-nahe Drift bei verwaltetem npm: Wenn ein verwaistes oder wiederhergestelltes @openclaw/*-Paket unter dem verwalteten Plugin-npm-Root ein gebündeltes Plugin überschattet, entfernt Doctor dieses veraltete Paket und baut die Registry neu auf, damit der Start gegen das gebündelte Manifest validiert. Doctor verlinkt außerdem das Host-Paket openclaw erneut in verwaltete npm-Plugins, die peerDependencies.openclaw deklarieren, sodass paketlokale Runtime-Importe wie openclaw/plugin-sdk/* nach Updates oder npm-Reparaturen aufgelöst werden.
Marketplace
openclaw plugins marketplace list <source>openclaw plugins marketplace list <source> --jsonMarketplace list akzeptiert einen lokalen Marketplace-Pfad, einen marketplace.json-Pfad, eine GitHub-Kurzform wie owner/repo, eine GitHub-Repo-URL oder eine Git-URL. --json gibt die aufgelöste Quellenbezeichnung sowie das geparste Marketplace-Manifest und die Plugin-Einträge aus.