Skip to main content
Plugins erweitern OpenClaw, ohne den Kern zu verändern. Ein Plugin kann einen Messaging-Kanal, Modell-Provider, ein lokales CLI-Backend, Agenten-Tool, einen Hook, Medien-Provider oder eine andere Plugin-eigene Funktion hinzufügen. Sie müssen dem OpenClaw-Repository kein externes Plugin hinzufügen. Veröffentlichen Sie das Paket auf ClawHub; Benutzer installieren es mit:
Reine Paketspezifikationen werden während der Einführungsumstellung weiterhin von npm installiert. Verwenden Sie das Präfix clawhub:, wenn Sie die Auflösung über ClawHub wünschen.

Anforderungen

  • Node 22.22.3+, Node 24.15+ oder Node 25.9+ sowie npm oder pnpm.
  • TypeScript-ESM-Module.
  • Klonen Sie für die Arbeit an gebündelten Plugins im Repository das Repository und führen Sie pnpm install aus. Die Plugin-Entwicklung im Quellcode-Checkout erfolgt ausschließlich mit pnpm, da OpenClaw gebündelte Plugins aus extensions/*-Workspace-Paketen erkennt.

Plugin-Struktur auswählen

Kanal-Plugin

Verbinden Sie OpenClaw mit einer Messaging-Plattform.

Provider-Plugin

Fügen Sie einen Modell-, Medien-, Such-, Abruf-, Sprach- oder Echtzeit-Provider hinzu.

CLI-Backend-Plugin

Führen Sie eine lokale KI-CLI über den Modell-Fallback von OpenClaw aus.

Tool-Plugin

Registrieren Sie Agenten-Tools.

Schnellstart

Erstellen Sie ein minimales Tool-Plugin, indem Sie ein erforderliches Agenten-Tool registrieren. Dies ist die kürzeste nützliche Plugin-Struktur und deckt Paket, Manifest, Einstiegspunkt und lokalen Nachweis ab.
1

Paketmetadaten erstellen

Veröffentlichte externe Plugins sollten Laufzeiteinträge auf erstellte JavaScript- Dateien verweisen lassen. Den vollständigen Einstiegspunktvertrag finden Sie unter SDK-Einstiegspunkte.Jedes Plugin benötigt ein Manifest, auch ohne Konfiguration. Laufzeit-Tools müssen in contracts.tools aufgeführt sein, damit OpenClaw die Zuständigkeit erkennen kann, ohne jede Plugin-Laufzeit vorzeitig zu laden. Legen Sie activation.onStartup bewusst fest; dieses Beispiel wird beim Start des Gateway geladen.Auch vom Host als vertrauenswürdig eingestufte Plugin-Oberflächen sind durch das Manifest beschränkt und erfordern für installierte Plugins eine ausdrückliche Deklaration: Für api.registerAgentToolResultMiddleware(...) muss jede Ziellaufzeit in contracts.agentToolResultMiddleware aufgeführt sein, und für api.registerTrustedToolPolicy(...) muss jede Richtlinien-ID in contracts.trustedToolPolicies aufgeführt sein. Diese Deklarationen stimmen die Prüfung bei der Installation mit der Laufzeitregistrierung ab.Informationen zu allen Manifestfeldern finden Sie unter Plugin-Manifest.
2

Tool registrieren

index.ts
Verwenden Sie definePluginEntry für Plugins, die keine Kanal-Plugins sind. Kanal-Plugins verwenden stattdessen defineChannelPluginEntry aus openclaw/plugin-sdk/core.
3

Laufzeit testen

Prüfen Sie bei einem installierten oder externen Plugin die geladene Laufzeit:
Wenn das Plugin einen CLI-Befehl registriert, führen Sie auch diesen Befehl aus und überprüfen Sie die Ausgabe, beispielsweise openclaw demo-plugin ping.Bei einem gebündelten Plugin in diesem Repository erkennt OpenClaw Plugin-Pakete aus dem Quellcode-Checkout im Workspace extensions/*. Führen Sie den am besten passenden gezielten Test aus:
4

Paketinstallation testen

Testen Sie vor der Veröffentlichung eines paketfertigen Plugins dieselbe Installationsform, die Benutzer erhalten werden. Fügen Sie zunächst einen Build-Schritt hinzu, lassen Sie Laufzeiteinträge wie openclaw.extensions auf erstelltes JavaScript wie ./dist/index.js verweisen und stellen Sie sicher, dass npm pack diese dist/-Ausgabe enthält. TypeScript-Quellcodeeinträge sind ausschließlich für Quellcode-Checkouts und lokale Entwicklungspfade vorgesehen.Packen Sie dann das Plugin und installieren Sie das Tarball mit npm-pack::
npm-pack: verwendet das von OpenClaw verwaltete npm-Projekt pro Plugin und erkennt daher Fehler bei Laufzeitabhängigkeiten, die Tests im Quellcode-Checkout verbergen können. Dies weist die Paket- und Abhängigkeitsstruktur nach, nicht jedoch den mit einem Katalog verknüpften offiziellen Vertrauensstatus. Laufzeitimporte müssen in dependencies oder optionalDependencies enthalten sein; Abhängigkeiten, die nur in devDependencies verbleiben, werden für das verwaltete Laufzeitprojekt nicht installiert.Verwenden Sie eine direkte Archiv-/Pfadinstallation nicht als abschließenden Nachweis für offizielles oder privilegiertes Plugin-Verhalten. Direkte Quellen sind für die lokale Fehlersuche nützlich, weisen jedoch nicht denselben Abhängigkeitspfad wie Installationen über npm oder ClawHub nach. Wenn Ihr Plugin auf dem Vertrauensstatus eines offiziellen Plugins beruht, ergänzen Sie einen zweiten Nachweis über eine kataloggestützte offizielle Installation oder einen veröffentlichten Paketpfad, der den offiziellen Vertrauensstatus aufzeichnet. Einzelheiten zu Installationsstamm und Zuständigkeit für Abhängigkeiten finden Sie unter Auflösung von Plugin-Abhängigkeiten.
5

Veröffentlichen

Validieren Sie das Paket vor der Veröffentlichung:
Kanonische ClawHub-Paketausschnitte befinden sich in docs/snippets/plugin-publish/.
6

Installieren

Installieren Sie das veröffentlichte Paket über ClawHub:

Tools registrieren

Tools können erforderlich oder optional sein. Erforderliche Tools sind immer verfügbar, wenn das Plugin aktiviert ist. Optionale Tools erfordern die ausdrückliche Zustimmung des Benutzers, bevor OpenClaw die zugehörige Plugin-Laufzeit lädt. Tool-Factories erhalten einen vertrauenswürdigen Laufzeitkontext, einschließlich deliveryContext, nativeChannelId für die aktive Plattformkonversation, sofern verfügbar, und requesterSenderId.
outputSchema ist optional. Es beschreibt den strukturierten details-Wert, der von Code Mode und Tool-Suche verwendet wird. Katalog- Aufrufe lehnen ungültige Schemas vor der Ausführung ab und validieren den endgültigen Wert nach Tool-Hooks. Lassen Sie es bei Tools ohne stabiles JSON-Ergebnis weg. Den vollständigen Vertrag finden Sie unter Tool-Plugins. Jedes mit api.registerTool(...) registrierte Tool muss außerdem im Plugin-Manifest deklariert werden:
Benutzer stimmen mit tools.allow zu:
Optionale Tools steuern, ob ein Tool dem Modell bereitgestellt wird. Verwenden Sie Plugin-Berechtigungsanfragen, wenn ein Tool oder Hook nach der Auswahl durch das Modell und vor der Ausführung der Aktion eine Genehmigung anfordern soll. Verwenden Sie optionale Tools für Nebeneffekte, ungewöhnliche Binärdateien oder Funktionen, die standardmäßig nicht bereitgestellt werden sollten. Tool-Namen dürfen nicht mit Namen von Kern-Tools kollidieren; Konflikte werden übersprungen und in der Plugin-Diagnose gemeldet. Fehlerhafte Registrierungen werden übersprungen und auf dieselbe Weise gemeldet: ein fehlendes, nicht leeres name, ein execute, das keine Funktion ist, oder ein Tool-Deskriptor ohne ein parameters- Objekt. Tool-Factories erhalten ein von der Laufzeit bereitgestelltes Kontextobjekt. Verwenden Sie ctx.activeModel, wenn ein Tool das aktive Modell für den aktuellen Durchlauf protokollieren, anzeigen oder sich daran anpassen muss; es kann provider, modelId und modelRef enthalten. Behandeln Sie es als informative Laufzeitmetadaten und nicht als Sicherheitsgrenze gegenüber dem lokalen Betreiber, installiertem Plugin-Code oder einer modifizierten OpenClaw-Laufzeit. Sensible lokale Tools sollten weiterhin eine ausdrückliche Zustimmung für das Plugin oder durch den Betreiber erfordern und geschlossen fehlschlagen, wenn Metadaten zum aktiven Modell fehlen oder ungeeignet sind. Das Manifest deklariert Zuständigkeit und Erkennung; die Ausführung ruft weiterhin die aktive registrierte Tool-Implementierung auf. Halten Sie toolMetadata.<tool>.optional: true mit api.registerTool(..., { optional: true }) konsistent, damit OpenClaw das Laden dieser Plugin-Laufzeit vermeiden kann, bis das Tool ausdrücklich in die Zulassungsliste aufgenommen wird.

Importkonventionen

Importieren Sie aus spezifischen SDK-Unterpfaden:
Verwenden Sie innerhalb Ihres Plugin-Pakets lokale Barrel-Dateien wie api.ts und runtime-api.ts für interne Importe. Importieren Sie Ihr eigenes Plugin nicht über einen SDK-Pfad. Provider-spezifische Hilfsfunktionen sollten im Provider-Paket verbleiben, sofern die Schnittstelle nicht wirklich generisch ist. Benutzerdefinierte Gateway-RPC-Methoden sind ein erweiterter Einstiegspunkt. Verwenden Sie dafür ein Plugin-spezifisches Präfix; zentrale Admin-Namespaces wie config.*, exec.approvals.*, operator.admin.*, wizard.* und update.* bleiben reserviert und werden zu operator.admin aufgelöst. Die openclaw/plugin-sdk/gateway-method-runtime-Bridge ist für Plugin-HTTP- Routen reserviert, die contracts.gatewayMethodDispatch: ["authenticated-request"] deklarieren. Die vollständige Importübersicht finden Sie unter Plugin-SDK-Übersicht. Die OpenClaw-SDK-Kompatibilitätsfelder enthalten TypeScript-@deprecated-Annotationen, die Editoren als Migrationswarnungen anzeigen. Um sie während des Builds durchzusetzen, aktivieren Sie eine typbewusste Regel wie @typescript-eslint/no-deprecated. Oxlint ist nicht typbewusst und kann diese Annotationen daher nicht durchsetzen.

Checkliste vor der Einreichung

package.json enthält korrekte openclaw-Metadaten
Das openclaw.plugin.json-Manifest ist vorhanden und gültig
Der Einstiegspunkt verwendet defineChannelPluginEntry oder definePluginEntry
Alle Importe verwenden spezifische plugin-sdk/<subpath>-Pfade
Interne Importe verwenden lokale Module, keine SDK-Selbstimporte
Tests sind erfolgreich (pnpm test <bundled-plugin-root>/my-plugin/)
pnpm check ist erfolgreich (repo-interne Plugins)

Gegen Beta-Releases testen

  1. Beobachten Sie die Releases von openclaw/openclaw (Watch > Releases). Beta-Tags sehen wie v2026.3.N-beta.1 aus. Sie können außerdem @openclaw auf X folgen, um Release-Ankündigungen zu erhalten.
  2. Testen Sie Ihr Plugin gegen den Beta-Tag, sobald er erscheint. Das Zeitfenster vor dem stabilen Release beträgt in der Regel nur wenige Stunden.
  3. Veröffentlichen Sie nach dem Testen im Thread Ihres Plugins im Discord-Kanal plugin-forum (discord.gg/clawd) entweder all good oder eine Beschreibung dessen, was nicht funktioniert hat. Erstellen Sie einen Thread, falls Sie noch keinen haben.
  4. Wenn etwas nicht funktioniert, öffnen oder aktualisieren Sie ein Issue mit dem Titel Beta blocker: <plugin-name> - <summary> und weisen Sie ihm das Label beta-blocker zu. Verlinken Sie das Issue in Ihrem Thread.
  5. Öffnen Sie einen PR für main mit dem Titel fix(<plugin-id>): beta blocker - <summary> und verlinken Sie das Issue sowohl im PR als auch in Ihrem Discord-Thread. Mitwirkende können PRs keine Labels zuweisen, daher dient der Titel als PR-seitiges Signal für Maintainer und Automatisierung. Blocker mit einem PR werden zusammengeführt; Blocker ohne PR werden möglicherweise trotzdem ausgeliefert.
  6. Keine Rückmeldung bedeutet grünes Licht. Wenn Sie das Zeitfenster verpassen, wird Ihre Fehlerbehebung normalerweise erst im nächsten Zyklus aufgenommen.

Nächste Schritte

Kanal-Plugins

Ein Plugin für einen Nachrichtenkanal entwickeln

Provider-Plugins

Ein Plugin für einen Modell-Provider entwickeln

CLI-Backend-Plugins

Ein lokales KI-CLI-Backend registrieren

SDK-Übersicht

Referenz für Importzuordnung und Registrierungs-API

Runtime-Hilfsfunktionen

TTS, Suche und Subagent über api.runtime

Tests

Testhilfsprogramme und -muster

Plugin-Manifest

Vollständige Referenz zum Manifestschema

Verwandte Themen