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
OmeniaClaw plugins listOmeniaClaw plugins list --enabledOmeniaClaw plugins list --verboseOmeniaClaw plugins list --jsonOmeniaClaw plugins search <query>OmeniaClaw plugins search <query> --limit 20OmeniaClaw plugins search <query> --jsonOmeniaClaw plugins install <path-or-spec>OmeniaClaw plugins inspect <id>OmeniaClaw plugins inspect <id> --runtimeOmeniaClaw plugins inspect <id> --jsonOmeniaClaw plugins inspect --allOmeniaClaw plugins info <id>OmeniaClaw plugins enable <id>OmeniaClaw plugins disable <id>OmeniaClaw plugins registryOmeniaClaw plugins registry --refreshOmeniaClaw plugins uninstall <id>OmeniaClaw plugins doctorOmeniaClaw plugins update <id-or-npm-spec>OmeniaClaw plugins update --allOmeniaClaw plugins marketplace list <marketplace>OmeniaClaw plugins marketplace list <marketplace> --jsonFühren Sie zur Untersuchung langsamer Installations-, Prüf-, Deinstallations- oder Registry-Aktualisierungsvorgänge den
Befehl mit OmeniaClaw_PLUGIN_LIFECYCLE_TRACE=1 aus. Der Trace schreibt Phasenzeiten
nach stderr und sorgt dafür, dass JSON-Ausgaben weiterhin parsebar bleiben. Siehe Debugging.
Installation
OmeniaClaw plugins search "calendar" # search ClawHub pluginsOmeniaClaw plugins install <package> # npm by defaultOmeniaClaw plugins install clawhub:<package> # ClawHub onlyOmeniaClaw plugins install npm:<package> # npm onlyOmeniaClaw plugins install npm-pack:<path.tgz> # local npm pack through npm install semanticsOmeniaClaw plugins install git:github.com/<owner>/<repo> # git repoOmeniaClaw plugins install git:github.com/<owner>/<repo>@<ref>OmeniaClaw plugins install <package> --force # overwrite existing installOmeniaClaw plugins install <package> --pin # pin versionOmeniaClaw plugins install <package> --dangerously-force-unsafe-installOmeniaClaw plugins install <path> # local pathOmeniaClaw plugins install <plugin>@<marketplace> # marketplaceOmeniaClaw plugins install <plugin> --marketplace <name> # marketplace (explicit)OmeniaClaw 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 OmeniaClaw 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 OmeniaClaw.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 OmeniaClaw doctor --fix auszuführen. Beim Gateway-Start und Hot Reload schlägt ungültige Plugin-Konfiguration wie jede andere ungültige Konfiguration geschlossen fehl; OmeniaClaw 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 OmeniaClaw.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 OmeniaClaw plugins update <id-or-npm-spec>.
Wenn Sie plugins install für eine bereits installierte Plugin-ID ausführen, stoppt OmeniaClaw 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/[email protected], 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 OmeniaClaw 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 OmeniaClaw.hooks in package.json bereitstellen. Verwenden Sie OmeniaClaw 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 OmeniaClaw, 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. OmeniaClaw-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 OmeniaClaw 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 OmeniaClaw 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 OmeniaClaw plugins update die Quelle später erneut auflösen kann.
Verwenden Sie nach der Installation aus Git OmeniaClaw 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 OmeniaClaw-Root-CLI aus, zum Beispiel OmeniaClaw demo-plugin ping.
Archive
Unterstützte Archive: .zip, .tgz, .tar.gz, .tar. Native OmeniaClaw-Plugin-Archive müssen ein gültiges OmeniaClaw.plugin.json im extrahierten Plugin-Root enthalten; Archive, die nur package.json enthalten, werden abgelehnt, bevor OmeniaClaw 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:
OmeniaClaw plugins install clawhub:OmeniaClaw-codex-app-serverOmeniaClaw plugins install clawhub:[email protected]Bloße npm-sichere Plugin-Spezifikationen installieren während der Launch-Umstellung standardmäßig aus npm:
OmeniaClaw plugins install OmeniaClaw-codex-app-serverVerwenden Sie npm:, um eine reine npm-Auflösung explizit zu machen:
OmeniaClaw plugins install npm:OmeniaClaw-codex-app-serverOmeniaClaw plugins install npm:@scope/[email protected]OmeniaClaw 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 OmeniaClaw 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 OmeniaClaw plugins update neueren ClawHub-Releases folgen kann; explizite Versions- oder Tag-Selektoren wie clawhub:[email protected] 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:
OmeniaClaw plugins marketplace list <marketplace-name>OmeniaClaw plugins install <plugin-name>@<marketplace-name>Verwenden Sie --marketplace, wenn Sie die Marketplace-Quelle explizit übergeben möchten:
OmeniaClaw plugins install <plugin-name> --marketplace <marketplace-name>OmeniaClaw plugins install <plugin-name> --marketplace <owner/repo>OmeniaClaw plugins install <plugin-name> --marketplace https://github.com/<owner>/<repo>OmeniaClaw 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. OmeniaClaw 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 OmeniaClaw automatisch:
- native OmeniaClaw-Plugins (
OmeniaClaw.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
OmeniaClaw plugins listOmeniaClaw plugins list --enabledOmeniaClaw plugins list --verboseOmeniaClaw plugins list --jsonOmeniaClaw plugins search <query>OmeniaClaw plugins search <query> --limit 20OmeniaClaw 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
OmeniaClaw 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. OmeniaClaw 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:
OmeniaClaw plugins inspect <id> --runtime --jsonzeigt registrierte Hooks und Diagnosen aus einem Inspektionsdurchlauf mit geladenem Modul. Die Runtime-Inspektion installiert niemals Abhängigkeiten; verwenden SieOmeniaClaw doctor --fix, um Legacy-Abhängigkeitszustände zu bereinigen oder fehlende herunterladbare Plugins wiederherzustellen, auf die in der Konfiguration verwiesen wird.OmeniaClaw 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):
OmeniaClaw plugins install -l ./my-pluginPlugin-Index
Plugin-Installationsmetadaten sind maschinenverwalteter Zustand, keine Benutzerkonfiguration. Installationen und Updates schreiben sie in plugins/installs.json im aktiven OmeniaClaw-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 OmeniaClaw plugins update, Deinstallation, Diagnosen und der Kalt-Plugin-Registry verwendet.
Wenn OmeniaClaw ausgelieferte Legacy-plugins.installs-Datensätze in der Konfiguration sieht, behandeln Runtime-Lesevorgänge sie als Kompatibilitätseingabe, ohne OmeniaClaw.json neu zu schreiben. Explizite Plugin-Schreibvorgänge und OmeniaClaw 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
OmeniaClaw plugins uninstall <id>OmeniaClaw plugins uninstall <id> --dry-runOmeniaClaw 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 OmeniaClaw befindet. Bei Active-Memory-Plugins wird der Speicher-Slot auf memory-core zurückgesetzt.
Aktualisieren
OmeniaClaw plugins update <id-or-npm-spec>OmeniaClaw plugins update --allOmeniaClaw plugins update <id-or-npm-spec> --dry-runOmeniaClaw plugins update @OmeniaClaw/voice-callOmeniaClaw plugins update OmeniaClaw-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 OmeniaClaw 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. OmeniaClaw 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
OmeniaClaw plugins update verwendet die verfolgte Plugin-Spezifikation wieder, sofern Sie keine neue Spezifikation übergeben. OmeniaClaw update kennt zusätzlich den aktiven OmeniaClaw-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 OmeniaClaw 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 OmeniaClaw.json neu zu schreiben.
Wenn ein gespeicherter Integritäts-Hash vorhanden ist und sich der Hash des abgerufenen Artefakts ändert, behandelt OmeniaClaw dies als npm-Artefaktabweichung. Der interaktive Befehl OmeniaClaw 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
OmeniaClaw plugins inspect <id>OmeniaClaw plugins inspect <id> --runtimeOmeniaClaw 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 OmeniaClaw plugins install, OmeniaClaw plugins update und OmeniaClaw doctor --fix.
Plugin-eigene CLI-Befehle werden normalerweise als Root-OmeniaClaw-Befehlsgruppen installiert, aber Plugins können auch verschachtelte Befehle unter einem Core-Elternbefehl wie OmeniaClaw 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 OmeniaClaw 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
OmeniaClaw 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 OmeniaClaw_PLUGIN_LOAD_DEBUG=1 aus, um eine kompakte Zusammenfassung der Exportform in die Diagnoseausgabe aufzunehmen.
Registry
OmeniaClaw plugins registryOmeniaClaw plugins registry --refreshOmeniaClaw plugins registry --jsonDie lokale Plugin-Registry ist das persistierte Cold-Read-Modell von OmeniaClaw 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.
OmeniaClaw doctor --fix repariert außerdem Registry-nahe Drift bei verwaltetem npm: Wenn ein verwaistes oder wiederhergestelltes @OmeniaClaw/*-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 OmeniaClaw erneut in verwaltete npm-Plugins, die peerDependencies.OmeniaClaw deklarieren, sodass paketlokale Runtime-Importe wie OmeniaClaw/plugin-sdk/* nach Updates oder npm-Reparaturen aufgelöst werden.
Marketplace
OmeniaClaw plugins marketplace list <source>OmeniaClaw 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.
