CLI commands

Plugins

Gateway-Plugins, Hook-Packs und kompatible Bundles verwalten.

Plugin-System

Leitfaden für Endbenutzer zum Installieren, Aktivieren und Beheben von Problemen mit Plugins.

Plugins verwalten

Kurze Beispiele für Installation, Auflistung, Aktualisierung, Deinstallation und Veröffentlichung.

Plugin-Bundles

Kompatibilitätsmodell für Bundles.

Plugin-Manifest

Manifestfelder und Konfigurationsschema.

Sicherheit

Sicherheits-Härtung für Plugin-Installationen.

Befehle

bash

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 entriesopenclaw plugins marketplace entries --offlineopenclaw plugins marketplace entries --jsonopenclaw plugins marketplace list <marketplace>openclaw plugins marketplace list <marketplace> --jsonopenclaw plugins marketplace refreshopenclaw plugins marketplace refresh --feed-profile clawhub-public --jsonopenclaw plugins marketplace refresh --feed-url https://clawhub.ai/v1/feeds/plugins --expected-sha256 <sha256>openclaw plugins init my-tool --name "My Tool"openclaw plugins init my-provider --name "My Provider" --type provideropenclaw plugins init my-provider --name "My Provider" --type provider --directory ./my-provideropenclaw plugins build --entry ./dist/index.jsopenclaw plugins build --entry ./dist/index.js --checkopenclaw plugins validate --entry ./dist/index.js

Für Untersuchungen langsamer Installationen, Inspektionen, Deinstallationen oder Registry-Aktualisierungen führen Sie den Befehl mit OPENCLAW_PLUGIN_LIFECYCLE_TRACE=1 aus. Der Trace schreibt Phasen-Timings nach stderr und hält JSON-Ausgaben parsebar. Siehe Debugging.

Autor

bash

openclaw plugins init stock-quotes --name "Stock Quotes"cd stock-quotesnpm run plugin:buildnpm run plugin:validate

plugins init erstellt standardmäßig ein minimales TypeScript-Tool-Plugin. Das erste Argument ist die Plugin-ID; übergeben Sie --name für den Anzeigenamen. OpenClaw verwendet die ID für das standardmäßige Ausgabeverzeichnis und die Paketbenennung. Tool-Gerüste verwenden defineToolPlugin. plugins build importiert den gebauten Einstiegspunkt, liest dessen statische Tool-Metadaten, schreibt openclaw.plugin.json und hält package.json openclaw.extensions synchron. plugins validate prüft, ob das generierte Manifest, die Paketmetadaten und der aktuelle Einstiegspunkt-Export weiterhin übereinstimmen. Siehe Tool-Plugins für den vollständigen Workflow zum Erstellen von Tools.

Das Gerüst schreibt TypeScript-Quellcode, generiert Metadaten aber aus dem gebauten Einstiegspunkt ./dist/index.js, sodass der Workflow auch mit der veröffentlichten CLI funktioniert. Verwenden Sie --entry <path>, wenn der Einstiegspunkt nicht der standardmäßige Paketeinstiegspunkt ist. Verwenden Sie plugins build --check in CI, damit bei veralteten generierten Metadaten ein Fehler ausgelöst wird, ohne Dateien neu zu schreiben.

Provider-Gerüst

bash

openclaw plugins init acme-models --name "Acme Models" --type providercd acme-modelsnpm installnpm run buildnpm testnpm run validate

Provider-Gerüste erstellen ein generisches Text-/Modell-Provider-Plugin mit OpenAI-kompatibler API-Schlüssel-Infrastruktur, einem integrierten npm run validate-Skript für clawhub package validate, ClawHub-Paketmetadaten und einem manuell ausgelösten GitHub-Workflow für künftige vertrauenswürdige Veröffentlichungen über GitHub Actions OIDC. Provider-Gerüste generieren keine Skills und verwenden weder openclaw plugins build noch openclaw plugins validate; diese Befehle sind für den Pfad generierter Metadaten des Tool-Gerüsts bestimmt.

Ersetzen Sie vor der Veröffentlichung die Platzhalter für API-Basis-URL, Modellkatalog, Docs- Route, Anmeldedatentext und README-Text durch echte Provider-Details. Verwenden Sie die generierte README für die erste ClawHub-Veröffentlichung und die Einrichtung als vertrauenswürdiger Publisher.

Installation

bash

openclaw plugins search "calendar"                   # search ClawHub pluginsopenclaw plugins install <package>                      # source auto-detectionopenclaw 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 clawhub:<package> --acknowledge-clawhub-riskopenclaw 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 abgesicherten 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 Single-File-$include gestützt wird, 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 flach 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 quarantänisieren. Die einzige dokumentierte Ausnahme zur Installationszeit ist ein enger Wiederherstellungspfad für gebündelte Plugins, die explizit openclaw.install.allowInvalidConfigRecovery aktivieren.

--force und Neuinstallation vs. Aktualisierung

--force verwendet das vorhandene Installationsziel wieder und überschreibt ein bereits installiertes Plugin oder einen Hook-Pack an Ort und Stelle. Verwenden Sie es, wenn Sie absichtlich dieselbe ID aus einem neuen lokalen Pfad, Archiv, ClawHub-Paket oder npm-Artefakt neu installieren. Für routinemäßige Upgrades eines bereits nachverfolgten npm-Plugins bevorzugen Sie openclaw plugins update <id-or-npm-spec>.

Wenn Sie plugins install für eine bereits installierte Plugin-ID ausführen, hält OpenClaw an 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-Ref wie git:github.com/acme/plugin@v1.2.3, wenn Sie eine gepinnte Quelle wünschen. Es wird mit --marketplace nicht unterstützt, weil Marketplace-Installationen Marketplace-Quellenmetadaten statt einer npm-Spezifikation dauerhaft speichern.

--dangerously-force-unsafe-install

--dangerously-force-unsafe-install ist veraltet und jetzt wirkungslos. OpenClaw führt keine integrierte Blockierung gefährlichen Codes zur Installationszeit für Plugin-Installationen mehr aus.

Verwenden Sie die gemeinsame, betreiberverwaltete Oberfläche security.installPolicy, wenn hostspezifische Installationsrichtlinien erforderlich sind. Plugin-before_install-Hooks sind Lebenszyklus-Hooks der Plugin-Runtime und nicht die primäre Richtliniengrenze für CLI-Installationen.

Wenn ein von Ihnen auf ClawHub veröffentlichtes Plugin durch einen Registry-Scan ausgeblendet oder blockiert wird, verwenden Sie die Publisher-Schritte unter ClawHub-Veröffentlichung. --dangerously-force-unsafe-install fordert ClawHub nicht auf, das Plugin erneut zu scannen oder eine blockierte Veröffentlichung öffentlich zu machen.

--acknowledge-clawhub-risk

Community-ClawHub-Installationen prüfen den Vertrauensdatensatz der ausgewählten Veröffentlichung, bevor das Paket heruntergeladen wird. Wenn ClawHub den Download für die Veröffentlichung deaktiviert, bösartige Scan-Funde meldet oder die Veröffentlichung in einen blockierenden Moderationszustand wie Quarantäne versetzt, verweigert OpenClaw die Veröffentlichung. Bei nicht blockierenden riskanten Scan-Status, riskanten Moderationszuständen oder Registry-Gründen zeigt OpenClaw die Vertrauensdetails an und fragt vor dem Fortfahren nach Bestätigung.

Verwenden Sie --acknowledge-clawhub-risk nur, nachdem Sie die ClawHub-Warnung geprüft und entschieden haben, ohne interaktive Eingabeaufforderung fortzufahren. Ausstehende oder veraltete saubere Vertrauensdatensätze warnen, erfordern aber keine Bestätigung. Offizielle ClawHub-Pakete und gebündelte OpenClaw-Plugin-Quellen umgehen diese Vertrauensabfrage für Veröffentlichungen.

Hook-Packs und npm-Spezifikationen

plugins install ist auch die Installationsfläche für Hook-Packs, die openclaw.hooks in package.json bereitstellen. Verwenden Sie openclaw hooks für gefilterte Hook-Sichtbarkeit und Aktivierung pro Hook, nicht für die Paketinstallation.

Npm-Spezifikationen sind nur Registry-basiert (Paketname + optional exakte Version oder dist-tag). Git-/URL-/Datei-Spezifikationen und Semver-Bereiche werden abgelehnt. Dependency-Installationen laufen aus Sicherheitsgründen in einem verwalteten npm-Projekt pro Plugin mit --ignore-scripts, selbst wenn Ihre Shell globale npm-Installationseinstellungen hat. Verwaltete Plugin-npm-Projekte erben OpenClaws npm-overrides auf Paketebene, sodass Security-Pins des Hosts auch für hoisted Plugin-Dependencies gelten.

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, sofern sie nicht einer offiziellen Plugin-ID entsprechen.

Rohe @openclaw/*-Paketspezifikationen, die gebündelten Plugins entsprechen, werden vor dem npm-Fallback auf die image-eigene gebündelte Kopie aufgelöst. Zum Beispiel verwendet openclaw plugins install @openclaw/discord@2026.5.20 --pin das gebündelte Discord-Plugin aus dem aktuellen OpenClaw-Build, statt einen verwalteten npm-Override zu erstellen. Um das externe npm-Paket zu erzwingen, verwenden Sie openclaw plugins install npm:@openclaw/discord@2026.5.20 --pin.

Bloße Spezifikationen und @latest bleiben auf dem Stable-Track. Datumsbasierte OpenClaw-Korrekturversionen 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 dafür zu entscheiden.

Bei npm-Installationen ohne exakte Version (npm:<package> oder npm:<package>@latest) prüft OpenClaw die aufgelösten Paketmetadaten vor der Installation. Wenn das neueste stabile Paket eine neuere OpenClaw-Plugin-API oder Mindest-Hostversion erfordert, prüft OpenClaw ältere stabile Versionen und installiert stattdessen das neueste kompatible Release. Exakte Versionen und explizite dist-tags wie @beta bleiben strikt: Wenn das ausgewählte Paket inkompatibel ist, schlägt der Befehl fehl und fordert Sie auf, OpenClaw zu aktualisieren oder eine kompatible Version zu wählen.

Wenn eine bloße Installationsspezifikation einer offiziellen Plugin-ID entspricht (zum Beispiel diffs), installiert OpenClaw den Katalogeintrag direkt. Um ein gleichnamiges npm-Paket zu installieren, verwenden Sie eine explizite scoped Spezifikation (zum Beispiel @scope/diffs).

Git repositories

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, Tag oder Commit auszuchecken.

Git-Installationen klonen in ein temporäres Verzeichnis, checken die angeforderte Ref aus, falls vorhanden, und verwenden dann den normalen Installer für Plugin-Verzeichnisse. Das bedeutet, dass Manifestvalidierung, Operator-Installationsrichtlinie, Installationsarbeit des Paketmanagers und Installationsdatensätze sich wie bei npm-Installationen verhalten. Aufgezeichnete Git-Installationen enthalten die Quell-URL/Ref plus den aufgelösten Commit, sodass openclaw plugins update die Quelle später erneut auflösen kann.

Nach der Installation aus Git verwenden Sie openclaw plugins inspect <id> --runtime --json, um Runtime-Registrierungen wie Gateway-Methoden und CLI-Befehle zu verifizieren. 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.

Marketplace-Kurzschreibweise

Verwenden Sie die plugin@marketplace-Kurzschreibweise, wenn der Marketplace-Name in Claudes lokalem Registry-Cache unter ~/.claude/plugins/known_marketplaces.json vorhanden ist:

bash

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:

bash

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

Marketplace sources

ein Claude-Name für einen bekannten Marketplace aus ~/.claude/plugins/known_marketplaces.json
ein lokaler Marketplace-Root oder marketplace.json-Pfad
eine GitHub-Repository-Kurzschreibweise wie owner/repo
eine GitHub-Repository-URL wie https://github.com/owner/repo
eine Git-URL

Remote marketplace rules

Für Remote-Marketplaces, die aus 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.json oder das Standardlayout für Claude-Komponenten)
Cursor-kompatible Bundles (.cursor-plugin/plugin.json)

Verwaltete lokale Installationen müssen Plugin-Verzeichnisse oder Archive sein. Eigenständige .js-, .mjs-, .cjs- und .ts-Plugin-Dateien werden von plugins install nicht in den verwalteten Plugin- Root kopiert; listen Sie sie stattdessen explizit in plugins.load.paths auf.

Auflisten

bash

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

--enabledboolean

Nur aktivierte Plugins anzeigen.

--verboseboolean

Von der Tabellenansicht zu Detailzeilen pro Plugin mit Quell-/Ursprungs-/Versions-/Aktivierungsmetadaten wechseln.

--jsonboolean

Maschinenlesbares Inventar plus Registry-Diagnosen und Installationsstatus von Paket-Dependencies.

Note

plugins list liest zuerst die persistierte lokale Plugin-Registry, mit einem nur aus Manifesten abgeleiteten Fallback, wenn die Registry fehlt oder ungültig ist. Das ist nützlich, um zu prüfen, ob ein Plugin installiert, aktiviert und für die Planung eines Kaltstarts sichtbar ist, aber es ist keine Live-Runtime-Prüfung eines bereits laufenden Gateway-Prozesses. Nach Änderungen an Plugin-Code, Aktivierung, Hook-Richtlinie oder plugins.load.paths starten Sie das Gateway neu, das den Kanal bedient, bevor Sie erwarten, dass neuer register(api)-Code oder Hooks ausgeführt werden. Verifizieren Sie bei Remote-/Container-Deployments, dass Sie den tatsächlichen openclaw gateway run-Child neu starten, nicht nur einen Wrapper-Prozess.

plugins list --json enthält den dependencyStatus jedes Plugins aus package.json dependencies und optionalDependencies. OpenClaw prüft, ob diese Paket- namen entlang des normalen Node-node_modules-Lookup-Pfads des Plugins vorhanden sind; es importiert keinen Plugin-Runtime-Code, führt keinen Paketmanager aus und repariert keine fehlenden Dependencies.

Wenn Startup plugins.allow is empty; discovered non-bundled plugins may auto-load: ... protokolliert, führen Sie openclaw plugins list --enabled --verbose oder openclaw plugins inspect <id> mit einer gelisteten Plugin-ID aus, um die Plugin- IDs zu bestätigen, und kopieren Sie vertrauenswürdige IDs in plugins.allow in openclaw.json. Wenn die Warnung jedes entdeckte Plugin listen kann, gibt sie ein direkt einfügbares plugins.allow-Snippet aus, das diese IDs bereits enthält. Wenn ein Plugin ohne Installations-/Load-Path-Provenienz lädt, prüfen Sie diese Plugin-ID und pinnen Sie dann entweder die vertrauenswürdige ID in plugins.allow oder installieren Sie das Plugin aus einer vertrauenswürdigen Quelle neu, damit OpenClaw die Installationsprovenienz aufzeichnet.

plugins search ist eine Remote-ClawHub-Katalogsuche. Sie prüft keinen lokalen Status, ändert keine Konfiguration, installiert keine Pakete und lädt keinen Plugin-Runtime-Code. Such- ergebnisse enthalten den ClawHub-Paketnamen, die Familie, den Kanal, die Version, die Zusammenfassung und einen Installationshinweis wie openclaw plugins install clawhub:<package>.

Für gebündelte Plugin-Arbeit innerhalb eines paketierten Docker-Images binden Sie das Plugin- Quellverzeichnis über den passenden paketierten Quellpfad, wie /app/extensions/synology-chat. OpenClaw entdeckt dieses gemountete Quell- Overlay vor /app/dist/extensions/synology-chat; ein einfach kopiertes Quell- verzeichnis bleibt inaktiv, sodass normale paketierte Installationen weiterhin die kompilierte Distribution verwenden.

Für Runtime-Hook-Debugging:

openclaw plugins inspect <id> --runtime --json zeigt registrierte Hooks und Diagnosen aus einem modulgeladenen Inspektionsdurchlauf. Runtime-Inspektion installiert niemals Dependencies; verwenden Sie openclaw doctor --fix, um Legacy-Dependency-Status zu bereinigen oder fehlende herunterladbare Plugins wiederherzustellen, die von der Konfiguration referenziert werden.
openclaw gateway status --deep --require-rpc bestätigt die erreichbare Gateway-URL/das Profil, Service-/Prozesshinweise, den Konfigurationspfad und die RPC-Integrität.
Nicht gebündelte Conversation-Hooks (llm_input, llm_output, before_model_resolve, before_agent_reply, before_agent_run, before_agent_finalize, agent_end) erfordern plugins.entries.<id>.hooks.allowConversationAccess=true.

Verwenden Sie --link, um das Kopieren eines lokalen Plugin-Verzeichnisses zu vermeiden (fügt zu plugins.load.paths hinzu):

bash

openclaw plugins install -l ./my-plugin

Eigenständige Plugin-Dateien müssen in plugins.load.paths aufgeführt werden, statt mit plugins install installiert oder direkt in ~/.openclaw/extensions oder <workspace>/.openclaw/extensions abgelegt zu werden. Diese automatisch entdeckten Roots laden Plugin- Paket- oder Bundle-Verzeichnisse, während Skriptdateien auf oberster Ebene als lokale Hilfsdateien behandelt und übersprungen werden.

Note

Workspace-Ursprungs-Plugins, die aus einem Workspace-Erweiterungsstamm erkannt werden, werden erst importiert oder ausgeführt, wenn sie ausdrücklich aktiviert sind. Führen Sie für die lokale Entwicklung openclaw plugins enable <plugin-id> aus oder setzen Sie plugins.entries.<plugin-id>.enabled: true; wenn Ihre Konfiguration plugins.allow verwendet, nehmen Sie dieselbe Plugin-ID dort ebenfalls auf. Diese Fail-Closed-Regel gilt auch, wenn die Kanaleinrichtung ausdrücklich ein Workspace-Ursprungs-Plugin für reines Setup-Laden auswählt; lokaler Kanal-Plugin-Setup-Code wird daher nicht ausgeführt, solange dieses Workspace-Plugin deaktiviert bleibt oder von der Allowlist ausgeschlossen ist. Verknüpfte Installationen und explizite plugins.load.paths-Einträge folgen der normalen Richtlinie für ihren aufgelösten Plugin-Ursprung. Siehe Plugin-Richtlinie konfigurieren und Konfigurationsreferenz.

--force wird mit --link nicht unterstützt, weil verknüpfte Installationen den Quellpfad wiederverwenden, statt ein verwaltetes Installationsziel zu überschreiben.

Verwenden Sie --pin bei npm-Installationen, um die aufgelöste exakte Spezifikation (name@version) im verwalteten Plugin-Index zu speichern, während das Standardverhalten ungepinnt bleibt.

Plugin-Index

Plugin-Installationsmetadaten sind maschinenverwalteter Zustand, keine Benutzerkonfiguration. Installationen und Updates schreiben sie in die gemeinsame SQLite-Zustandsdatenbank unter dem aktiven OpenClaw-Zustandsverzeichnis. Die Zeile installed_plugin_index speichert dauerhafte installRecords-Metadaten, einschließlich Einträgen für beschädigte oder fehlende Plugin-Manifeste, sowie einen aus dem Manifest abgeleiteten kalten Registry-Cache, der von openclaw plugins update, Deinstallation, Diagnose und der kalten Plugin-Registry verwendet wird.

Wenn OpenClaw ausgelieferte Legacy-plugins.installs-Einträge in der Konfiguration sieht, behandelt die Laufzeit sie beim Lesen als Kompatibilitätseingabe, ohne openclaw.json neu zu schreiben. Explizite Plugin-Schreibvorgänge und openclaw doctor --fix verschieben diese Einträge in den Plugin-Index und entfernen den Konfigurationsschlüssel, wenn Konfigurationsschreibvorgänge erlaubt sind; schlägt einer der Schreibvorgänge fehl, bleiben die Konfigurationseinträge erhalten, damit die Installationsmetadaten nicht verloren gehen.

Deinstallieren

bash

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

uninstall entfernt Plugin-Einträge aus plugins.entries, dem persistierten Plugin-Index, Plugin-Allow-/Denylist-Einträgen und, falls zutreffend, verknüpften plugins.load.paths-Einträgen. Sofern --keep-files nicht gesetzt ist, entfernt die Deinstallation außerdem das nachverfolgte 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

bash

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 --acknowledge-clawhub-riskopenclaw plugins update openclaw-codex-app-server --dangerously-force-unsafe-install

Updates gelten für nachverfolgte Plugin-Installationen im verwalteten Plugin-Index und nachverfolgte Hook-Pack-Installationen in hooks.internal.installs.

Resolving plugin id vs npm spec

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.

Während update <id> --dry-run bleiben exakt gepinnte npm-Installationen gepinnt. Wenn OpenClaw außerdem die Standardlinie der Package-Registry auflösen kann und diese Standardlinie neuer ist als die installierte gepinnte Version, meldet der Trockenlauf den Pin und gibt den expliziten @latest-Package-Update-Befehl aus, um der Standardlinie der Registry zu folgen.

Diese Regel für gezielte Updates unterscheidet sich vom Wartungspfad für das gebündelte openclaw plugins update --all. Gebündelte Updates respektieren weiterhin gewöhnliche nachverfolgte Installationsspezifikationen, aber vertrauenswürdige offizielle OpenClaw-Plugin-Einträge können mit dem aktuellen Ziel des offiziellen Katalogs synchronisiert werden, statt auf einem veralteten exakten offiziellen Package zu bleiben. Verwenden Sie gezielt update <id>, wenn Sie eine exakte oder getaggte offizielle Spezifikation absichtlich unverändert lassen möchten.

Für npm-Installationen können Sie auch eine explizite npm-Package-Spezifikation mit Dist-Tag oder exakter Version übergeben. OpenClaw löst diesen Package-Namen zurück auf den nachverfolgten Plugin-Eintrag auf, aktualisiert dieses installierte Plugin und zeichnet die neue npm-Spezifikation für künftige ID-basierte Updates auf.

Wenn Sie den npm-Package-Namen ohne Version oder Tag übergeben, wird er ebenfalls zurück auf den nachverfolgten Plugin-Eintrag aufgelöst. Verwenden Sie dies, wenn ein Plugin auf eine exakte Version gepinnt war und Sie es zurück auf die Standard-Release-Linie der Registry verschieben möchten.

Beta channel updates

Gezieltes openclaw plugins update <id-or-npm-spec> verwendet die nachverfolgte Plugin-Spezifikation wieder, sofern Sie keine neue Spezifikation übergeben. Gebündeltes openclaw plugins update --all verwendet den konfigurierten update.channel, wenn es vertrauenswürdige offizielle Plugin-Einträge mit dem offiziellen Katalogziel synchronisiert, sodass Beta-Kanal-Installationen auf der Beta-Release-Linie bleiben können, statt stillschweigend auf Stable/Latest normalisiert zu werden.

openclaw update kennt auch den aktiven OpenClaw-Update-Kanal: Auf dem Beta-Kanal versuchen npm-Standardlinien- und ClawHub-Plugin-Einträge zuerst @beta. Sie fallen auf die aufgezeichnete Standard-/Latest-Spezifikation zurück, wenn keine Plugin-Beta-Release existiert; npm-Plugins fallen auch zurück, wenn das Beta-Package existiert, aber die Installationsvalidierung fehlschlägt. Dieser Fallback wird als Warnung gemeldet und lässt das Kern-Update nicht fehlschlagen. Exakte Versionen und explizite Tags bleiben für gezielte Updates auf diesen Selektor gepinnt.

Version checks and integrity drift

Vor einem Live-npm-Update prüft OpenClaw die installierte Package-Version 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-Artefakt-Drift. Der interaktive Befehl openclaw plugins update gibt die erwarteten und tatsächlichen Hashes aus und fragt vor dem Fortfahren nach Bestätigung. Nicht interaktive Update-Helfer schlagen geschlossen fehl, sofern der Aufrufer keine explizite Fortsetzungsrichtlinie bereitstellt.

--dangerously-force-unsafe-install on update

--dangerously-force-unsafe-install wird aus Kompatibilitätsgründen auch bei plugins update akzeptiert, ist jedoch veraltet und ändert das Verhalten von Plugin-Updates nicht mehr. Die Betreiberoption security.installPolicy kann Updates weiterhin blockieren; Plugin-before_install-Hooks gelten nur in Prozessen, in denen Plugin-Hooks geladen sind.

--acknowledge-clawhub-risk on update

Community-Plugin-Updates, die von ClawHub gestützt werden, führen vor dem Herunterladen des Ersatz-Packages dieselbe Vertrauensprüfung für exakte Releases aus wie Installationen. Verwenden Sie --acknowledge-clawhub-risk für geprüfte Automatisierung, die fortfahren soll, wenn die ausgewählte ClawHub-Release eine riskante Vertrauenswarnung hat. Offizielle ClawHub-Packages und gebündelte OpenClaw-Plugin-Quellen umgehen diese Release-Vertrauensabfrage.

Inspizieren

bash

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

Inspect zeigt Identität, Ladestatus, Quelle, Manifest-Fähigkeiten, Richtlinien-Flags, Diagnose, Installationsmetadaten, Bundle-Fähigkeiten und jede erkannte MCP- oder LSP-Serverunterstützung, ohne standardmäßig die Plugin-Laufzeit zu importieren. Die JSON-Ausgabe enthält die Plugin-Manifestverträge, etwa contracts.agentToolResultMiddleware und contracts.trustedToolPolicies, damit Betreiber Trusted-Surface-Deklarationen prüfen können, bevor sie ein Plugin aktivieren oder neu starten. Fügen Sie --runtime hinzu, um das Plugin-Modul zu laden und registrierte Hooks, Tools, Befehle, Dienste, Gateway-Methoden und HTTP-Routen einzubeziehen. Die Laufzeitinspektion 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-Befehlsgruppen von openclaw installiert, Plugins können aber auch verschachtelte Befehle unter einem Kern-Elternbefehl wie openclaw nodes registrieren. Nachdem inspect --runtime einen Befehl unter cliCommands angezeigt hat, führen Sie ihn am aufgelisteten Pfad aus; ein Plugin, das demo-git registriert, kann zum Beispiel mit openclaw demo-git ping verifiziert werden.

Jedes Plugin wird danach klassifiziert, was es zur Laufzeit tatsächlich 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.

Doctor

bash

openclaw plugins doctor

doctor meldet Plugin-Ladefehler, Manifest-/Discovery-Diagnosen, Kompatibilitätshinweise und veraltete Plugin-Konfigurationsreferenzen wie fehlende Plugin-Slots. Wenn der Installationsbaum und die Plugin-Konfiguration sauber sind, gibt er No plugin issues detected. aus. Wenn veraltete Konfiguration verbleibt, der Installationsbaum aber ansonsten fehlerfrei ist, sagt die Zusammenfassung dies, statt vollständige Plugin-Gesundheit zu implizieren.

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 Pfadeigentümerschaft oder weltbeschreibbare Berechtigungen, statt die Konfiguration plugins.entries.<id> oder plugins.allow zu entfernen.

Bei Modulform-Fehlern wie fehlenden register-/activate-Exports führen Sie den Befehl erneut mit OPENCLAW_PLUGIN_LOAD_DEBUG=1 aus, um eine kompakte Exportform-Zusammenfassung in die Diagnoseausgabe aufzunehmen.

Registry

bash

openclaw plugins registryopenclaw plugins registry --refreshopenclaw plugins registry --json

Die lokale Plugin-Registry ist das persistierte kalte Lesemodell von OpenClaw für installierte Plugin-Identität, Aktivierung, Quellmetadaten und Eigentümerschaft von Beiträgen. Normaler Start, Provider-Owner-Lookup, Klassifizierung der Kanaleinrichtung und Plugin-Inventar können sie lesen, ohne Plugin-Laufzeitmodule 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-/Package-Metadaten neu aufzubauen. Dies ist ein Reparaturpfad, kein Laufzeitaktivierungspfad.

openclaw doctor --fix repariert außerdem verwalteten npm-Drift neben der Registry: Wenn ein verwaistes oder wiederhergestelltes @openclaw/*-Package unter einem verwalteten Plugin-npm-Projekt oder dem alten flachen verwalteten npm-Stamm ein gebündeltes Plugin überschattet, entfernt Doctor dieses veraltete Package und baut die Registry neu auf, damit der Start gegen das gebündelte Manifest validiert. Doctor verknüpft außerdem das Host-openclaw-Package erneut in verwaltete npm-Plugins, die peerDependencies.openclaw deklarieren, sodass package-lokale Laufzeitimporte wie openclaw/plugin-sdk/* nach Updates oder npm-Reparaturen aufgelöst werden.

Marketplace

bash

openclaw plugins marketplace entriesopenclaw plugins marketplace entries --offlineopenclaw plugins marketplace entries --jsonopenclaw plugins marketplace entries --feed-profile <name>openclaw plugins marketplace entries --feed-url <url>openclaw plugins marketplace list <source>openclaw plugins marketplace list <source> --jsonopenclaw plugins marketplace refreshopenclaw plugins marketplace refresh --feed-profile <name>openclaw plugins marketplace refresh --feed-url <url>openclaw plugins marketplace refresh --expected-sha256 <sha256> --json

plugins marketplace entries listet Einträge aus dem konfigurierten OpenClaw-Marktplatz-Feed auf. Standardmäßig versucht es den gehosteten Feed und fällt auf den neuesten akzeptierten Snapshot oder gebündelte Daten zurück. Verwenden Sie --feed-profile <name>, um ein bestimmtes konfiguriertes Profil zu lesen, --feed-url <url>, um eine explizite gehostete Feed-URL zu lesen, und --offline, um den neuesten akzeptierten Snapshot zu lesen, ohne den Feed abzurufen.

plugins marketplace refresh aktualisiert den konfigurierten gehosteten Feed-Snapshot und meldet, ob OpenClaw gehostete Daten, einen gehosteten Snapshot oder gebündelte Fallback-Daten akzeptiert hat. Verwenden Sie --expected-sha256, wenn ein Aufrufer benötigt, dass der Befehl fehlschlägt, sofern eine frische gehostete Payload nicht mit einer festgelegten Prüfsumme übereinstimmt.

Marketplace list akzeptiert einen lokalen Marketplace-Pfad, einen marketplace.json-Pfad, eine GitHub-Kurzschreibweise wie owner/repo, eine GitHub-Repository-URL oder eine Git-URL. --json gibt die aufgelöste Quellbezeichnung sowie das geparste Marketplace-Manifest und die Plugin-Einträge aus.

Marketplace-Aktualisierung lädt einen gehosteten OpenClaw-Marketplace-Feed und speichert die validierte Antwort als lokalen Snapshot des gehosteten Feeds. Ohne Optionen verwendet sie das konfigurierte Standard-Feed-Profil. Verwenden Sie --feed-profile <name>, um ein bestimmtes konfiguriertes Profil zu aktualisieren, --feed-url <url>, um eine explizite URL eines gehosteten Feeds zu aktualisieren, --expected-sha256 <sha256>, um eine passende Payload-Prüfsumme (sha256:<hex> oder einen einfachen 64-stelligen Hex-Digest) zu verlangen, und --json für maschinenlesbare Ausgabe. Explizite URLs gehosteter Feeds dürfen keine Anmeldedaten, Query-Strings oder Fragmente enthalten. Nicht gepinnte Aktualisierungen können ein gehostetes Snapshot- oder gebündeltes Fallback-Ergebnis melden, ohne dass der Befehl fehlschlägt. Gepinnte Aktualisierungen schlagen fehl, sofern sie keine frische gehostete Payload akzeptieren, und erfolgreiche gehostete Aktualisierungen schlagen fehl, wenn OpenClaw den validierten Snapshot nicht speichern kann.

Verwandt

Was this useful?

Plugins

Befehle

Autor

Provider-Gerüst

Installation

Marketplace-Kurzschreibweise

Marketplace sources

Remote marketplace rules

Auflisten

Plugin-Index

Deinstallieren

Aktualisieren

Inspizieren

Doctor

Registry

Marketplace

Verwandt

On this page

Molty