clawhub:, wenn Sie die ClawHub-Auflösung wünschen.
Anforderungen
- Verwenden Sie Node 22.19+, Node 23.11+ oder Node 24+ und einen Paketmanager wie
npmoderpnpm. - Machen Sie sich mit TypeScript-ESM-Modulen vertraut.
- Klonen Sie für im Repository gebündelte Plugin-Arbeit das Repository und führen Sie
pnpm installaus. Die Plugin-Entwicklung aus einem Source-Checkout ist nur mit pnpm möglich, weil OpenClaw gebündelte Plugins aus Workspace-Paketen unterextensions/*lädt.
Plugin-Form auswählen
Kanal-Plugin
Verbinden Sie OpenClaw mit einer Messaging-Plattform.
Provider-Plugin
Fügen Sie einen Modell-, Medien-, Such-, Fetch-, Sprach- oder Echtzeit-Provider hinzu.
CLI-Backend-Plugin
Führen Sie eine lokale KI-CLI über OpenClaw-Modell-Fallback aus.
Tool-Plugin
Registrieren Sie Agent-Tools.
Schnellstart
Erstellen Sie ein minimales Tool-Plugin, indem Sie ein erforderliches Agent-Tool registrieren. Dies ist die kürzeste nützliche Plugin-Form und zeigt Paket, Manifest, Einstiegspunkt und lokalen Nachweis.Paketmetadaten erstellen
contracts.tools erscheinen, damit OpenClaw die Zuständigkeit erkennen kann, ohne
jede Plugin-Laufzeit vorab zu laden. Setzen Sie activation.onStartup
bewusst. Dieses Beispiel startet beim Gateway-Start.Host-vertrauenswürdige Plugin-Oberflächen sind ebenfalls manifestgesteuert und erfordern eine explizite
Aktivierung für installierte Plugins. Wenn ein installiertes Plugin
api.registerAgentToolResultMiddleware(...) registriert, deklarieren Sie jede Ziel-Laufzeit in
contracts.agentToolResultMiddleware. Wenn es
api.registerTrustedToolPolicy(...) registriert, deklarieren Sie jede Policy-ID in
contracts.trustedToolPolicies. Diese Deklarationen halten die Prüfung zur Installationszeit
und die Laufzeitregistrierung aufeinander abgestimmt.Alle Manifestfelder finden Sie unter Plugin-Manifest.Tool registrieren
index.ts
definePluginEntry für Nicht-Kanal-Plugins. Kanal-Plugins verwenden
defineChannelPluginEntry.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. Zum Beispiel
sollte ein Demo-Befehl einen Ausführungsnachweis wie
openclaw demo-plugin ping haben.Bei einem gebündelten Plugin in diesem Repository erkennt OpenClaw Source-Checkout-
Plugin-Pakete aus dem extensions/*-Workspace. Führen Sie den nächstliegenden gezielten
Test aus:Paketinstallation testen
Bevor Sie ein paketfertiges Plugin veröffentlichen, testen Sie dieselbe Installationsform, die Benutzer
erhalten werden. Fügen Sie zuerst einen Build-Schritt hinzu, lassen Sie Laufzeit-Einträge wie
openclaw.extensions auf gebautes JavaScript wie ./dist/index.js zeigen, und stellen Sie
sicher, dass npm pack diese dist/-Ausgabe enthält. TypeScript-Quelleinträge sind
nur für Source-Checkouts und lokale Entwicklungspfade vorgesehen.Packen Sie dann das Plugin und installieren Sie den Tarball mit npm-pack::npm-pack: verwendet OpenClaws verwaltetes npm-Projekt pro Plugin, sodass es
Laufzeit-Abhängigkeitsfehler findet, die Source-Checkout-Tests verbergen können. Es weist
die Paket- und Abhängigkeitsform nach, nicht katalogverknüpftes offizielles Vertrauen.
Laufzeit-Imports müssen in dependencies oder optionalDependencies stehen;
Abhängigkeiten, die nur in devDependencies verbleiben, werden für das
verwaltete Laufzeitprojekt nicht installiert.Verwenden Sie keine rohe Archiv-/Pfadinstallation als finalen Nachweis für offizielles oder
privilegiertes Plugin-Verhalten. Rohe Quellen sind für lokales Debugging nützlich, aber
sie weisen nicht denselben Abhängigkeitspfad wie npm- oder ClawHub-Installationen nach. Wenn
Ihr Plugin auf vertrauenswürdigen offiziellen Plugin-Status angewiesen ist, fügen Sie einen zweiten Nachweis
über eine kataloggestützte offizielle Installation oder einen veröffentlichten Paketpfad hinzu, der
offizielles Vertrauen aufzeichnet. Details zu Installations-Root und Zuständigkeit für Abhängigkeiten finden Sie unter
Plugin-Abhängigkeitsauflösung.Veröffentlichen
Validieren Sie das Paket vor der Veröffentlichung:Die kanonischen ClawHub-Snippets befinden sich in
docs/snippets/plugin-publish/.Tools registrieren
Tools können erforderlich oder optional sein. Erforderliche Tools sind immer verfügbar, wenn das Plugin aktiviert ist. Optionale Tools erfordern eine Zustimmung durch den Benutzer.api.registerTool(...) registrierte Tool muss auch im
Plugin-Manifest deklariert werden:
tools.allow zu:
parameters, werden übersprungen und
auf dieselbe Weise gemeldet. Registrierte Tools sind typisierte Funktionen, die das Modell
aufrufen kann, nachdem Policy- und Allowlist-Prüfungen bestanden wurden.
Tool-Factories erhalten ein von der Laufzeit bereitgestelltes Kontextobjekt. Verwenden Sie ctx.activeModel,
wenn ein Tool das aktive Modell für den aktuellen Turn protokollieren, anzeigen oder sich daran
anpassen muss. Das Objekt kann provider, modelId und modelRef enthalten. Behandeln Sie es als
informative Laufzeitmetadaten, nicht als Sicherheitsgrenze gegenüber dem lokalen
Operator, installiertem Plugin-Code oder einer modifizierten OpenClaw-Laufzeit. Sensible lokale
Tools sollten weiterhin eine explizite Plugin- oder Operator-Zustimmung erfordern und geschlossen fehlschlagen,
wenn aktive Modellmetadaten fehlen oder ungeeignet sind.
Das Manifest deklariert Zuständigkeit und Discovery; die Ausführung ruft weiterhin die live
registrierte Tool-Implementierung auf. Halten Sie toolMetadata.<tool>.optional: true
mit api.registerTool(..., { optional: true }) abgestimmt, damit OpenClaw vermeiden kann,
diese Plugin-Laufzeit zu laden, bis das Tool explizit in die Allowlist aufgenommen wurde.
Importkonventionen
Importieren Sie aus fokussierten SDK-Unterpfaden:api.ts und
runtime-api.ts für interne Imports. Importieren Sie Ihr eigenes Plugin nicht über einen
SDK-Pfad. Provider-spezifische Hilfsfunktionen sollten im Provider-Paket bleiben, sofern
die Schnittstelle nicht wirklich generisch ist.
Benutzerdefinierte Gateway-RPC-Methoden sind ein fortgeschrittener Einstiegspunkt. Belassen Sie sie unter einem
Plugin-spezifischen Präfix; Core-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-Map finden Sie in der Plugin-SDK-Übersicht.
Checkliste vor der Einreichung
package.json enthält korrekte
openclaw-Metadatenopenclaw.plugin.json-Manifest ist vorhanden und gültig
Der Einstiegspunkt verwendet
defineChannelPluginEntry oder definePluginEntryAlle Imports verwenden fokussierte
plugin-sdk/<subpath>-PfadeInterne Imports verwenden lokale Module, keine SDK-Selbstimports
Tests bestehen (
pnpm test -- <bundled-plugin-root>/my-plugin/)pnpm check besteht (In-Repo-Plugins)Gegen Beta-Releases testen
- Achten Sie auf GitHub-Release-Tags bei openclaw/openclaw und abonnieren Sie sie über
Watch>Releases. Beta-Tags sehen wiev2026.3.N-beta.1aus. Sie können außerdem Benachrichtigungen für das offizielle OpenClaw-X-Konto @openclaw aktivieren, um Release-Ankündigungen zu erhalten. - Testen Sie Ihr Plugin gegen das Beta-Tag, sobald es erscheint. Das Zeitfenster bis zur stabilen Version beträgt typischerweise nur wenige Stunden.
- Posten Sie nach dem Testen im Thread Ihres Plugins im Discord-Kanal
plugin-forumentwederall goododer was kaputtgegangen ist. Wenn Sie noch keinen Thread haben, erstellen Sie einen. - Wenn etwas kaputtgeht, öffnen oder aktualisieren Sie ein Issue mit dem Titel
Beta blocker: <plugin-name> - <summary>und wenden Sie das Labelbeta-blockeran. Setzen Sie den Issue-Link in Ihren Thread. - Öffnen Sie einen PR auf
mainmit dem Titelfix(<plugin-id>): beta blocker - <summary>und verlinken Sie das Issue sowohl im PR als auch in Ihrem Discord-Thread. Mitwirkende können PRs nicht labeln, daher ist der Titel das PR-seitige Signal für Maintainer und Automatisierung. Blocker mit einem PR werden gemergt; Blocker ohne PR könnten trotzdem ausgeliefert werden. Maintainer beobachten diese Threads während des Beta-Tests. - Stille bedeutet grün. Wenn Sie das Zeitfenster verpassen, landet Ihr Fix wahrscheinlich im nächsten Zyklus.
Nächste Schritte
Channel Plugins
Erstellen Sie ein Messaging-Channel-Plugin
Provider Plugins
Erstellen Sie ein Modell-Provider-Plugin
CLI Backend Plugins
Registrieren Sie ein lokales KI-CLI-Backend
SDK Overview
Import-Map und API-Referenz zur Registrierung
Runtime Helpers
TTS, Suche, Subagent über api.runtime
Testing
Testhilfen und Muster
Plugin Manifest
Vollständige Referenz zum Manifest-Schema