Plugins in OpenClaw nutzen

Kennst du das? Du hast dein System perfekt aufgesetzt, aber es fehlt genau diese eine Integration, die deinen Workflow komplett machen würde. Oder dein Tool ist so vollgestopft mit Features, dass die Performance leidet, obwohl du die Hälfte davon gar nicht brauchst.

Plugins lösen dieses Problem. Sie halten dein OpenClaw-Setup sauber und modular. Du installierst nur das, was du wirklich für deine Agenten oder Kanäle benötigst, und hältst den Core schlank.

Voraussetzungen

• Eine installierte OpenClaw-Instanz.
• Für Microsoft Teams: Version 2026.1.15 oder höher.
• OpenAI oder ElevenLabs API-Keys (für Telephony TTS).

Schnellstart

Plugins sind kleine Code-Module, die OpenClaw um Commands, Tools oder Gateway RPC erweitern. In fünf Minuten ist dein erstes Plugin startklar:

1. Installierte Plugins prüfen: Schau nach, was bereits auf deinem System läuft:

   openclaw plugins list

2. Ein offizielles Plugin installieren: Nehmen wir Voice Call als Beispiel:

   openclaw plugins install @openclaw/voice-call

3. Aktivieren: Starte das Gateway neu und trage deine Einstellungen unter plugins.entries.<id>.config ein.

Plugins im Detail

Ich empfehle dir, Plugins immer dann zu nutzen, wenn ein Feature nicht im Core enthalten ist oder du optionale Funktionen von deiner Hauptinstallation trennen willst. OpenClaw lädt diese TypeScript-Module zur Laufzeit via jiti.

Ein wichtiger technischer Punkt: Die Validierung deiner Konfiguration führt keinen Plugin-Code aus. Stattdessen werden das Plugin-Manifest und JSON Schema genutzt. Plugins laufen in-process mit dem Gateway – betrachte sie also als vertrauenswürdigen Code.

Was Plugins registrieren können:

• Gateway RPC-Methoden und HTTP-Handler.
• Agent-Tools und CLI-Commands.
• Hintergrund-Dienste und Skills (über das skills-Verzeichnis im Manifest).
• Auto-reply Commands, die ohne den AI-Agent ausgeführt werden.

Runtime Helpers

Deine Plugins können auf Core-Helper über api.runtime zugreifen. Hier siehst du, wie du Telephony TTS einbindest:

const result = await api.runtime.tts.textToSpeechTelephony({
  text: "Hello from OpenClaw",
  cfg: api.config,
});

Fehlerbehebung

• Edge TTS funktioniert nicht: Edge TTS wird für Telefonie nicht unterstützt. Du musst OpenAI oder ElevenLabs in der messages.tts Konfiguration hinterlegen.
• Teams-Integration fehlt: Seit Version 2026.1.15 ist Microsoft Teams kein Core-Feature mehr. Installiere @openclaw/msteams manuell.
• Plugin-Code wird bei Config-Fehlern nicht geprüft: Die Validierung nutzt nur das Manifest. Wenn dein Plugin nicht lädt, prüfe das Plugin manifest.
• Audio-Format Probleme: Der textToSpeechTelephony Helper liefert PCM Audio-Buffer. Du musst das Resampling oder Encoding für deinen Provider selbst im Plugin übernehmen.

Du hast Fragen zur Installation? Frag den AI Setup Assistant.

Nächste Schritte

• Voice Call Beispiel
• Plugin manifest Details
• Eigene Agent Tools schreiben
• Zalo Personal Plugin

Kennst du das? Du baust ein Plugin, änderst den Code, aber in der App passiert absolut gar nichts. Meistens liegt das daran, dass eine andere Version deines Plugins priorisiert wird und du im falschen Verzeichnis arbeitest. Wenn man nicht genau weiß, wo das System nach Code sucht, verbringt man mehr Zeit mit Debugging als mit dem eigentlichen Feature.

Damit dir das bei OpenClaw nicht passiert, schauen wir uns an, wie die Discovery-Logik funktioniert und in welcher Reihenfolge das System deine Erweiterungen scannt.

Voraussetzungen

• Eine laufende OpenClaw-Instanz
• Eine openclaw.plugin.json Datei im Root-Verzeichnis deines Plugins
• Optional: Node.js für NPM-Dependencies

Quick Start: Wo kommen die Plugins hin?

OpenClaw scannt Verzeichnisse in einer festen Reihenfolge. Sobald eine Plugin-ID gefunden wird, ignorieren spätere Treffer diese ID einfach. Hier ist die Suchreihenfolge:

1. Config-Pfade: Alles, was du explizit in plugins.load.paths (Datei oder Verzeichnis) angibst.
2. Workspace-Extensions:
   • <workspace>/.openclaw/extensions/*.ts
   • <workspace>/.openclaw/extensions/*/index.ts
3. Globale Extensions:
   • ~/.openclaw/extensions/*.ts
   • ~/.openclaw/extensions/*/index.ts
4. Bundled Extensions (mitgeliefert, aber standardmäßig deaktiviert):
   • <openclaw>/extensions/*

Aktivierung und Manifest

Jedes Plugin braucht zwingend eine openclaw.plugin.json in seinem Root-Verzeichnis. Wenn ein Pfad direkt auf eine Datei zeigt, muss die Manifest-Datei im selben Verzeichnis wie diese Datei liegen.

Bundled Plugins musst du explizit aktivieren:

• Per Config: plugins.entries.<id>.enabled
• Per CLI: openclaw plugins enable <id>

Installierte Plugins sind automatisch aktiv, können aber über denselben Weg deaktiviert werden.

Package Packs und Dependencies

Du kannst mehrere Erweiterungen in einem Verzeichnis bündeln. Nutze dafür die package.json mit dem Feld openclaw.extensions:

{
  "name": "my-pack",
  "openclaw": {
    "extensions": ["./src/safety.ts", "./src/tools.ts"]
  }
}

In diesem Fall wird die Plugin-ID nach dem Schema name/<fileBase> generiert. Falls dein Plugin externe NPM-Pakete benötigt, installiere sie direkt im Plugin-Verzeichnis via npm install oder pnpm install, damit der node_modules-Ordner dort verfügbar ist.

Channel Catalog Metadaten

Channel-Plugins können Onboarding-Informationen und Installations-Hinweise bereitstellen. Das hält den Core schlank. Hier ist ein Beispiel für die Konfiguration:

{
  "name": "@openclaw/nextcloud-talk",
  "openclaw": {
    "extensions": ["./index.ts"],
    "channel": {
      "id": "nextcloud-talk",
      "label": "Nextcloud Talk",
      "selectionLabel": "Nextcloud Talk (self-hosted)",
      "docsPath": "/channels/nextcloud-talk",
      "docsLabel": "nextcloud-talk",
      "blurb": "Self-hosted chat via Nextcloud Talk webhook bots.",
      "order": 65,
      "aliases": ["nc-talk", "nc"]
    },
    "install": {
      "npmSpec": "@openclaw/nextcloud-talk",
      "localPath": "extensions/nextcloud-talk",
      "defaultChoice": "npm"
    }
  }
}

Externe Kataloge

Du kannst auch externe Kataloge (z. B. MPM Registry Exports) einbinden. Lege dafür eine JSON-Datei an einem dieser Orte ab:

• ~/.openclaw/mpm/plugins.json
• ~/.openclaw/mpm/catalog.json
• ~/.openclaw/plugins/catalog.json

Alternativ nutzt du die Umgebungsvariablen OPENCLAW_PLUGIN_CATALOG_PATHS oder OPENCLAW_MPM_CATALOG_PATHS. Mehrere Pfade trennst du durch Komma oder Semikolon. Das Format der Datei muss so aussehen:

{
  "entries": [
    {
      "name": "@scope/pkg",
      "openclaw": {
        "channel": { "...": "..." },
        "install": { "...": "..." }
      }
    }
  ]
}

Fehlerbehebung

• Plugin wird nicht geladen: Überprüfe, ob die openclaw.plugin.json im Root des Plugins liegt. Ohne diese Datei wird das Verzeichnis ignoriert.
• Falsche Plugin-Version: Wenn du ein Plugin an mehreren Orten hast (z. B. Global und im Workspace), gewinnt immer der Ort, der in der Discovery-Liste weiter oben steht. Workspace-Extensions überschreiben also globale Extensions.
• Bundled Plugin fehlt: Denke daran, dass mitgelieferte Plugins mit openclaw plugins enable <id> erst aktiviert werden müssen.

Hast du Fragen zur Einrichtung? Nutze den AI Setup Assistant.

Nächste Schritte

• Plugin Manifest Referenz
• CLI Command Guide

Kennst du das? Du willst dein Tool erweitern, aber die Plugin-Verwaltung ist ein einziges Rätselraten. IDs überschneiden sich, die Konfiguration ist unklar und am Ende weißt du nicht, warum eine Extension nicht lädt oder wo die Einstellungen eigentlich hingehören.

OpenClaw löst dieses Problem mit einem klaren System für Plugin IDs und einer strikten Konfiguration. So behältst du den Überblick, egal ob du eigene Plugins entwickelst oder fertige Extensions installierst.

Voraussetzungen

• Eine package.json für dein Plugin oder eine Standalone-Datei (z. B. .ts).
• Zugriff auf deine OpenClaw Konfigurationsdatei.
• Das OpenClaw CLI für Installationen und Fehlersuche.

Schnellstart

In 5 Minuten zum laufenden Plugin:

1. Plugin installieren: Nutze das CLI, um ein lokales Verzeichnis hinzuzufügen: openclaw plugins install ./extensions/voice-call
2. ID prüfen: OpenClaw nutzt den Namen aus der package.json oder den Dateinamen (z. B. voice-call).
3. In Config aktivieren: Füge das Plugin in deine Konfiguration ein:

   {
     plugins: {
       enabled: true,
       allow: ["voice-call"],
       entries: {
         "voice-call": { enabled: true, config: { provider: "twilio" } },
       },
     },
   }

4. Gateway neu starten: Änderungen an der Config werden erst nach einem Neustart aktiv.

Plugin IDs

OpenClaw ermittelt Plugin IDs automatisch:

• Package-Bundles: Es wird das name Feld aus der package.json verwendet.
• Standalone-Dateien: Es wird der Basisname der Datei verwendet (~/.../voice-call.ts wird zu voice-call).

Falls ein Plugin explizit eine id exportiert, verwendet OpenClaw diese. Wenn die exportierte ID jedoch nicht mit der konfigurierten ID übereinstimmt, gibt das System eine Warnung aus.

Config

Hier ist ein Beispiel für eine vollständige Plugin-Konfiguration:

{
  plugins: {
    enabled: true,
    allow: ["voice-call"],
    deny: ["untrusted-plugin"],
    load: { paths: ["~/Projects/oss/voice-call-extension"] },
    entries: {
      "voice-call": { enabled: true, config: { provider: "twilio" } },
    },
  },
}

Die Felder im Detail:

• enabled: Der Hauptschalter (Standard: true).
• allow: Eine optionale Allowlist.
• deny: Eine Denylist (Deny hat Vorrang vor Allow).
• load.paths: Zusätzliche Pfade für Plugin-Dateien oder Verzeichnisse.
• entries.<id>: Spezifische Einstellungen und Konfigurationen pro Plugin.

Validierungsregeln

OpenClaw ist hier sehr strikt:

• Unbekannte Plugin IDs in entries, allow, deny oder slots führen zu einem Error.
• Unbekannte Keys in channels.<id> sind Errors, außer ein Plugin-Manifest deklariert diese Channel ID.
• Die Plugin-Konfiguration wird gegen das JSON Schema in der openclaw.plugin.json (configSchema) validiert.
• Ist ein Plugin deaktiviert, bleibt die Konfiguration erhalten, aber es wird eine Warnung ausgegeben.

Plugin Slots

Manche Plugin-Kategorien sind exklusiv. Das bedeutet, dass nur ein Plugin gleichzeitig aktiv sein kann. Mit plugins.slots steuerst du, welches Plugin den Slot belegt:

{
  plugins: {
    slots: {
      memory: "memory-core", // oder "none" um Memory-Plugins zu deaktivieren
    },
  },
}

Wenn mehrere Plugins den Typ kind: "memory" beanspruchen, wird nur das in den Slots gewählte Plugin geladen. Die anderen werden mit einem Diagnosehinweis deaktiviert.

Control UI (Schema und Labels)

Die Control UI nutzt config.schema (JSON Schema + uiHints), um Formulare zu generieren. OpenClaw erweitert diese uiHints zur Laufzeit:

• Es fügt Labels für plugins.entries.<id>, .enabled und .config hinzu.
• Es führt optionale Hints des Plugins unter plugins.entries.<id>.config.<field> zusammen.

Damit deine Plugin-Einstellungen gute Labels und Placeholder haben (und Secrets maskiert werden), solltest du uiHints in deinem Plugin-Manifest definieren:

{
  "id": "my-plugin",
  "configSchema": {
    "type": "object",
    "additionalProperties": false,
    "properties": {
      "apiKey": { "type": "string" },
      "region": { "type": "string" }
    }
  },
  "uiHints": {
    "apiKey": { "label": "API Key", "sensitive": true },
    "region": { "label": "Region", "placeholder": "us-east-1" }
  }
}

CLI

Mit dem CLI verwaltest du den gesamten Lebenszyklus deiner Plugins:

openclaw plugins list
openclaw plugins info <id>
openclaw plugins install <path>                 # Kopiert lokale Datei/Ordner nach ~/.openclaw/extensions/<id>
openclaw plugins install ./extensions/voice-call # Relativer Pfad
openclaw plugins install ./plugin.tgz           # Installation aus lokalem Tarball
openclaw plugins install ./plugin.zip           # Installation aus lokalem Zip
openclaw plugins install -l ./extensions/voice-call # Link (keine Kopie) für die Entwicklung
openclaw plugins install @openclaw/voice-call # Installation via npm
openclaw plugins update <id>
openclaw plugins update --all
openclaw plugins enable <id>
openclaw plugins disable <id>
openclaw plugins doctor

Der Befehl plugins update funktioniert nur für npm-Installationen, die unter plugins.installs getrackt werden. Plugins können zudem eigene Top-Level-Commands registrieren (z. B. openclaw voicecall).

Plugin API und Hooks

Plugins exportieren entweder eine Funktion oder ein Objekt:

• Funktion: (api) => { ... }
• Objekt: { id, name, configSchema, register(api) { ... } }

Plugin Hooks

Plugins können Hooks mitliefern und zur Laufzeit registrieren. So bündelst du Automatisierungen direkt im Plugin:

import { registerPluginHooksFromDir } from "openclaw/plugin-sdk";

export default function register(api) {
  registerPluginHooksFromDir(api, "./hooks");
}

Wichtige Punkte zu Hooks:

• Hook-Verzeichnisse benötigen die Struktur HOOK.md + handler.ts.
• Plugin-Hooks erscheinen in openclaw hooks list mit dem Präfix plugin:<id>.
• Diese Hooks können nicht einzeln über openclaw hooks deaktiviert werden; du musst das gesamte Plugin deaktivieren.

Fehlerbehebung

• ID-Fehler: Wenn du eine ID in allow oder entries nutzt, die OpenClaw nicht finden kann, bricht der Start mit einem Error ab. Prüfe die ID mit openclaw plugins list.
• Config wird nicht übernommen: Hast du das Gateway neu gestartet? Plugin-Konfigurationen sind nicht hot-reloadable.
• Warnungen bei deaktivierten Plugins: Wenn ein Plugin in der Config steht, aber auf enabled: false gesetzt ist, warnt OpenClaw dich, dass die Config zwar geladen, aber nicht angewendet wird.

Fragen zum Setup? Nutze den AI Setup Assistant.

Nächste Schritte

• Schau dir an, wie du npm-Installationen in plugins.installs verwaltest.
• Erfahre mehr über das Erstellen eigener JSON Schemas für die configSchema.

Du kennst das sicher: Du willst ein neues KI-Modell ausprobieren, aber die Authentifizierung ist ein absoluter Albtraum. Ständig musst du zwischen externen Skripten, Browser-Tabs und deiner Konfiguration hin- und herwechseln, nur um einen API-Key oder ein OAuth-Token zu hinterlegen. Wenn du dann noch versuchst, einen eigenen Messaging-Dienst anzubinden, der nicht zum Standard gehört, stößt du oft an die Grenzen starrer Systeme. Das hält dich unnötig auf.

Hier kommen Plugins ins Spiel. Sie erlauben dir, die Authentifizierung und die Kommunikation direkt in OpenClaw zu integrieren, damit alles an einem Ort bleibt.

Voraussetzungen

• Zugriff auf die OpenClaw API (api)
• Ein registrierter Provider-Account (für Auth-Flows)
• Eine Vorstellung von der Konfigurationsstruktur deiner Channels

Quick Start: Model Auth

Plugins können Model Provider Auth Flows registrieren. Damit können Nutzer den OAuth- oder API-Key-Setup direkt in OpenClaw erledigen, ohne externe Skripte zu bemühen.

Du registrierst einen Provider über api.registerProvider(...). Jeder Provider bietet eine oder mehrere Auth-Methoden an (OAuth, API-Key, Device Code usw.). Diese Methoden steuern den folgenden Befehl:

• openclaw models auth login --provider <id> [--method <id>]

Hier ist ein minimales Beispiel für einen AcmeAI-Provider:

api.registerProvider({
  id: "acme",
  label: "AcmeAI",
  auth: [
    {
      id: "oauth",
      label: "OAuth",
      kind: "oauth",
      run: async (ctx) => {
        // OAuth-Flow ausführen und Auth-Profile zurückgeben.
        return {
          profiles: [
            {
              profileId: "acme:default",
              credential: {
                type: "oauth",
                provider: "acme",
                access: "...",
                refresh: "...",
                expires: Date.now() + 3600 * 1000,
              },
            },
          ],
          defaultModel: "acme/opus-1",
        };
      },
    },
  ],
});

Wichtige Details:

• run erhält einen ProviderAuthContext mit Hilfsmitteln wie prompter, runtime, openUrl und oauth.createVpsAwareHandlers.
• Gib configPatch zurück, wenn du Standardmodelle oder eine Provider-Konfiguration hinzufügen möchtest.
• Gib defaultModel zurück, damit --set-default die Agent-Defaults aktualisieren kann.

Messaging-Channels registrieren

Du kannst Channel-Plugins erstellen, die sich wie die eingebauten Channels (WhatsApp, Telegram etc.) verhalten. Die Konfiguration landet unter channels.<id> und wird durch deinen Plugin-Code validiert.

const myChannel = {
  id: "acmechat",
  meta: {
    id: "acmechat",
    label: "AcmeChat",
    selectionLabel: "AcmeChat (API)",
    docsPath: "/channels/acmechat",
    blurb: "demo channel plugin.",
    aliases: ["acme"],
  },
  capabilities: { chatTypes: ["direct"] },
  config: {
    listAccountIds: (cfg) => Object.keys(cfg.channels?.acmechat?.accounts ?? {}),
    resolveAccount: (cfg, accountId) =>
      cfg.channels?.acmechat?.accounts?.[accountId ?? "default"] ?? {
        accountId,
      },
  },
  outbound: {
    deliveryMode: "direct",
    sendText: async () => ({ ok: true }),
  },
};

export default function (api) {
  api.registerChannel({ plugin: myChannel });
}

Hinweise zur Konfiguration:

• Speichere die Konfiguration unter channels.<id>, nicht unter plugins.entries.
• meta.label wird für Anzeigen in der CLI oder UI verwendet.
• meta.aliases ermöglicht alternative IDs für die CLI-Eingabe.
• meta.preferOver definiert, welche Channels übersprungen werden sollen, wenn beide konfiguriert sind.

Einen neuen Messaging-Channel schreiben (Step‑by‑Step)

Nutze diesen Pfad, wenn du eine neue Chat-Oberfläche (“Messaging Channel”) bauen willst, keinen Model-Provider.

1. ID und Config-Struktur wählen: Alle Channel-Configs liegen unter channels.<id>. Nutze channels.<id>.accounts.<accountId> für Setups mit mehreren Accounts.
2. Metadaten definieren: meta.label, meta.selectionLabel, meta.docsPath und meta.blurb steuern die Darstellung. meta.docsPath sollte auf eine Seite wie /channels/<id> verweisen.
3. Adapter implementieren: Du brauchst zwingend config.listAccountIds, config.resolveAccount, capabilities sowie outbound.deliveryMode und outbound.sendText.
4. Optionale Adapter: Du kannst setup (Wizard), security (DM-Policy), status (Health-Checks), gateway (Start/Stop), streaming oder commands hinzufügen.
5. Registrierung: Nutze api.registerChannel({ plugin }).

Ein minimales Config-Beispiel sieht so aus:

{
  channels: {
    acmechat: {
      accounts: {
        default: { token: "ACME_TOKEN", enabled: true },
      },
    },
  },
}

Gateway RPC und CLI Commands

Du kannst eigene Gateway-Methoden registrieren, um Funktionen über RPC bereitzustellen:

export default function (api) {
  api.registerGatewayMethod("myplugin.status", ({ respond }) => {
    respond(true, { ok: true });
  });
}

Für die CLI kannst du den program-Befehl erweitern:

export default function (api) {
  api.registerCli(
    ({ program }) => {
      program.command("mycmd").action(() => {
        console.log("Hello");
      });
    },
    { commands: ["mycmd"] },
  );
}

Auto-reply Commands

Manchmal möchtest du Slash-Commands ausführen, ohne den KI-Agenten zu involvieren. Das ist perfekt für Status-Checks oder schnelle Aktionen.

export default function (api) {
  api.registerCommand({
    name: "mystatus",
    description: "Show plugin status",
    handler: (ctx) => ({
      text: `Plugin is running! Channel: ${ctx.channel}`,
    }),
  });
}

Der handler bekommt einen Kontext (ctx) mit:

• senderId: ID des Absenders.
• channel: Der aktuelle Channel.
• isAuthorizedSender: Boolean für Autorisierung.
• args: Argumente nach dem Befehl (wenn acceptsArgs: true).
• config: Die aktuelle OpenClaw Konfiguration.

Optionen für Commands:

• requireAuth: Standardmäßig true. Erfordert einen autorisierten Nutzer.
• acceptsArgs: Wenn false (Standard) und Argumente gesendet werden, wird der Command ignoriert.

Background Services

Wenn dein Plugin im Hintergrund laufen muss, registriere einen Service:

export default function (api) {
  api.registerService({
    id: "my-service",
    start: () => api.logger.info("ready"),
    stop: () => api.logger.info("bye"),
  });
}

Fehlerbehebung

• Doppelte Commands: Wenn zwei Plugins denselben Command-Namen registrieren, schlägt die Registrierung mit einem Fehler fehl.
• Reservierte Namen: Du kannst Befehle wie help, status oder reset nicht überschreiben.
• Command-Format: Namen müssen mit einem Buchstaben beginnen und dürfen nur Buchstaben, Zahlen, Bindestriche und Unterstriche enthalten.
• Groß-/Kleinschreibung: Command-Namen sind Case-Insensitive (/MyStatus ist gleich /mystatus).

AI Setup Assistant

Nächste Schritte

• Plugin agent tools
• Model provider docs

Kennst du das? Du arbeitest an einem Projekt und jeder benennt Funktionen, CLI-Befehle oder API-Endpunkte nach eigenem Ermessen. Am Ende verbringst du mehr Zeit damit, die richtige Schreibweise zu raten, als echten Code zu schreiben. Inkonsistente Benennungen führen schnell zu Frust im Team und machen die Integration neuer Features unnötig kompliziert.

Damit dein Plugin nahtlos in das Gateway passt, gibt es in OpenClaw klare Regeln. In diesem Guide zeige ich dir, wie du deine Plugins strukturierst, benennst und veröffentlichst, damit alles auf Anhieb funktioniert.

Voraussetzungen

• Ein Plugin-Projekt (lokal oder als npm-Paket)
• Zugriff auf die package.json deines Plugins
• OpenClaw CLI für die Installation

Schnellstart

In 5 Minuten zu einem konsistenten Plugin:

1. Namenswahl: Nutze snake_case für Tools und pluginId.action für Gateway-Methoden.
2. Skill-Check: Lege eine SKILL.md unter skills/<name>/ ab, falls dein Plugin einen Skill mitliefert.
3. Distribution: Füge openclaw.extensions zu deiner package.json hinzu.
4. Installation: Nutze openclaw plugins install <npm-spec> zum Testen.

Namenskonventionen

Damit die Kommunikation zwischen Gateway, Tools und CLI reibungslos läuft, halte dich an diese Formate:

• Gateway-Methoden: Verwende das Muster pluginId.action (Beispiel: voicecall.status).
• Tools: Hier ist snake_case der Standard (Beispiel: voice_call).
• CLI-Commands: Nutze kebab-case oder camelCase. Achte darauf, dass deine Befehle nicht mit den Core-Commands von OpenClaw kollidieren.

Skills und Konfiguration

Plugins können Skills direkt im Repo mitliefern. Diese findest du unter skills/<name>/SKILL.md. Damit ein Skill aktiv wird, musst du ihn in der Konfiguration freischalten:

Setze plugins.entries.<id>.enabled auf true. Stelle sicher, dass der Skill in deinem Workspace oder an den verwalteten Skill-Speicherorten vorhanden ist.

Distribution über npm

Für die Veröffentlichung empfehlen wir dieses Setup:

• Das Hauptpaket ist openclaw.
• Plugins werden als separate npm-Pakete unter dem Scope @openclaw/* veröffentlicht (Beispiel: @openclaw/voice-call).

Der Publishing-Contract

Damit OpenClaw dein Plugin erkennt, muss die package.json das Feld openclaw.extensions mit einer oder mehreren Entry-Files enthalten. Diese Dateien können auf .js oder .ts enden, da jiti TypeScript-Dateien direkt zur Laufzeit lädt.

Wenn du openclaw plugins install <npm-spec> ausführst, passiert folgendes:

• Das Tool nutzt npm pack.
• Der Inhalt wird nach ~/.openclaw/extensions/<id>/ extrahiert.
• Das Plugin wird in der Config aktiviert.

Wichtig: Bei Scoped-Packages wird die Config-ID normalisiert. Aus @openclaw/plugin-name wird in plugins.entries.* einfach der unscoped Name.

Beispiel: Voice Call Plugin

Das OpenClaw-Repo enthält ein voice-call Plugin, das entweder Twilio nutzt oder Logs ausgibt:

• Source: extensions/voice-call
• Skill: skills/voice-call
• CLI: openclaw voicecall start|status
• Tool: voice_call
• RPC: voicecall.start und voicecall.status

Konfiguration

Für Twilio nutzt du:

• provider: "twilio"
• twilio.accountSid, twilio.authToken, twilio.from
• Optional: statusCallbackUrl, twimlUrl

Für die lokale Entwicklung:

• provider: "log" (kein Netzwerkzugriff nötig)

Weitere Details findest du unter /plugins/voice-call oder in der extensions/voice-call/README.md.

Sicherheitshinweise

Plugins laufen im gleichen Prozess wie das Gateway. Du solltest sie als vertrauenswürdigen Code behandeln:

• Installiere nur Plugins, denen du vertraust.
• Nutze plugins.allow Allowlists für mehr Kontrolle.
• Starte das Gateway nach jeder Konfigurationsänderung neu.

Testing

Plugins sollten immer eigene Tests mitbringen:

• In-Repo Plugins: Diese nutzen Vitest-Tests unter src/** (Beispiel: src/plugins/voice-call.plugin.test.ts).
• Externe Plugins: Führe eine eigene CI für Linting, Build und Tests aus. Prüfe dabei, ob openclaw.extensions in der package.json korrekt auf den Build-Entrypoint zeigt (z. B. dist/index.js).

Fehlerbehebung

• Plugin wird nicht erkannt: Prüfe, ob das Feld openclaw.extensions in deiner package.json existiert und auf die richtige Datei zeigt.
• Konfiguration wird ignoriert: Denke daran, dass Scoped-Packages (wie @myorg/plugin) in der Config ohne den Scope-Teil registriert werden.

AI Setup Assistant

Nächste Schritte

• Plugin API Reference
• CLI Command Overview