​

Plugin-Manifest (openclaw.plugin.json)

• Codex-Bundle: .codex-plugin/plugin.json
• Claude-Bundle: .claude-plugin/plugin.json oder das standardmäßige Claude-Komponenten- Layout ohne Manifest
• Cursor-Bundle: .cursor-plugin/plugin.json

​

Was diese Datei macht

• Plugin-Identität
• Konfigurationsvalidierung
• Authentifizierungs- und Onboarding-Metadaten, die verfügbar sein sollen, ohne die Plugin- Laufzeit zu starten
• Alias- und Autoaktivierungs-Metadaten, die aufgelöst werden sollen, bevor die Plugin-Laufzeit geladen wird
• Kurzform-Metadaten zur Besitzerschaft von Modellfamilien, die das Plugin vor dem Laden der Laufzeit automatisch aktivieren sollen
• statische Snapshots der Fähigkeits-Besitzerschaft, die für gebündelte Kompatibilitätsverdrahtung und Vertragsabdeckung verwendet werden
• kanalspezifische Konfigurationsmetadaten, die in Katalog- und Validierungsoberflächen zusammengeführt werden sollen, ohne die Laufzeit zu laden
• Hinweise für die Konfigurations-UI

• die Registrierung von Laufzeitverhalten
• die Deklaration von Code-Einstiegspunkten
• npm-Installationsmetadaten

​

Minimales Beispiel

{
  "id": "voice-call",
  "configSchema": {
    "type": "object",
    "additionalProperties": false,
    "properties": {}
  }
}

​

Umfangreiches Beispiel

{
  "id": "openrouter",
  "name": "OpenRouter",
  "description": "OpenRouter provider plugin",
  "version": "1.0.0",
  "providers": ["openrouter"],
  "modelSupport": {
    "modelPrefixes": ["router-"]
  },
  "cliBackends": ["openrouter-cli"],
  "providerAuthEnvVars": {
    "openrouter": ["OPENROUTER_API_KEY"]
  },
  "providerAuthChoices": [
    {
      "provider": "openrouter",
      "method": "api-key",
      "choiceId": "openrouter-api-key",
      "choiceLabel": "OpenRouter API key",
      "groupId": "openrouter",
      "groupLabel": "OpenRouter",
      "optionKey": "openrouterApiKey",
      "cliFlag": "--openrouter-api-key",
      "cliOption": "--openrouter-api-key <key>",
      "cliDescription": "OpenRouter API key",
      "onboardingScopes": ["text-inference"]
    }
  ],
  "uiHints": {
    "apiKey": {
      "label": "API key",
      "placeholder": "sk-or-v1-...",
      "sensitive": true
    }
  },
  "configSchema": {
    "type": "object",
    "additionalProperties": false,
    "properties": {
      "apiKey": {
        "type": "string"
      }
    }
  }
}

​

Referenz der Felder auf oberster Ebene

​

Referenz zu providerAuthChoices

​

Referenz zu uiHints

{
  "uiHints": {
    "apiKey": {
      "label": "API key",
      "help": "Used for OpenRouter requests",
      "placeholder": "sk-or-v1-...",
      "sensitive": true
    }
  }
}

​

Referenz zu contracts

{
  "contracts": {
    "speechProviders": ["openai"],
    "realtimeTranscriptionProviders": ["openai"],
    "realtimeVoiceProviders": ["openai"],
    "mediaUnderstandingProviders": ["openai", "openai-codex"],
    "imageGenerationProviders": ["openai"],
    "videoGenerationProviders": ["qwen"],
    "webFetchProviders": ["firecrawl"],
    "webSearchProviders": ["gemini"],
    "tools": ["firecrawl_search", "firecrawl_scrape"]
  }
}

​

Referenz zu channelConfigs

{
  "channelConfigs": {
    "matrix": {
      "schema": {
        "type": "object",
        "additionalProperties": false,
        "properties": {
          "homeserverUrl": { "type": "string" }
        }
      },
      "uiHints": {
        "homeserverUrl": {
          "label": "Homeserver URL",
          "placeholder": "https://matrix.example.com"
        }
      },
      "label": "Matrix",
      "description": "Matrix homeserver connection",
      "preferOver": ["matrix-legacy"]
    }
  }
}

​

Referenz zu modelSupport

{
  "modelSupport": {
    "modelPrefixes": ["gpt-", "o1", "o3", "o4"],
    "modelPatterns": ["^computer-use-preview"]
  }
}

• explizite Referenzen im Format provider/model verwenden die Manifest-Metadaten der besitzenden providers
• modelPatterns haben Vorrang vor modelPrefixes
• wenn sowohl ein nicht gebündeltes Plugin als auch ein gebündeltes Plugin übereinstimmen, gewinnt das nicht gebündelte Plugin
• verbleibende Mehrdeutigkeit wird ignoriert, bis der Benutzer oder die Konfiguration einen Provider angibt

​

Manifest im Vergleich zu package.json

• wenn OpenClaw es vor dem Laden von Plugin-Code kennen muss, gehört es in openclaw.plugin.json
• wenn es um Paketierung, Einstiegsdateien oder das npm-Installationsverhalten geht, gehört es in package.json

​

package.json-Felder, die Discovery beeinflussen

​

JSON-Schema-Anforderungen

• Jedes Plugin muss ein JSON-Schema mitliefern, auch wenn es keine Konfiguration akzeptiert.
• Ein leeres Schema ist zulässig (zum Beispiel { "type": "object", "additionalProperties": false }).
• Schemata werden beim Lesen/Schreiben der Konfiguration validiert, nicht zur Laufzeit.

​

Validierungsverhalten

• Unbekannte channels.*-Schlüssel sind Fehler, es sei denn, die Kanal-ID wird durch ein Plugin-Manifest deklariert.
• plugins.entries.<id>, plugins.allow, plugins.deny und plugins.slots.* müssen auf auffindbare Plugin-IDs verweisen. Unbekannte IDs sind Fehler.
• Wenn ein Plugin installiert ist, aber ein defektes oder fehlendes Manifest oder Schema hat, schlägt die Validierung fehl und Doctor meldet den Plugin-Fehler.
• Wenn eine Plugin-Konfiguration existiert, das Plugin aber deaktiviert ist, wird die Konfiguration beibehalten und eine Warnung in Doctor + Protokollen ausgegeben.

​

Hinweise

• Das Manifest ist für native OpenClaw-Plugins erforderlich, einschließlich lokaler Dateisystem-Ladevorgänge.
• Zur Laufzeit wird das Plugin-Modul weiterhin separat geladen; das Manifest dient nur der Discovery + Validierung.
• Native Manifeste werden mit JSON5 geparst, daher sind Kommentare, nachgestellte Kommata und nicht in Anführungszeichen gesetzte Schlüssel zulässig, solange der endgültige Wert weiterhin ein Objekt ist.
• Nur dokumentierte Manifestfelder werden vom Manifest-Loader gelesen. Vermeiden Sie es, hier benutzerdefinierte Schlüssel auf oberster Ebene hinzuzufügen.
• providerAuthEnvVars ist der leichtgewichtige Metadatenpfad für Authentifizierungsprüfungen, Validierung von Umgebungsmarkern und ähnliche Provider-Auth-Oberflächen, die die Plugin-Laufzeit nicht starten sollten, nur um Umgebungsnamen zu prüfen.
• providerAuthChoices ist der leichtgewichtige Metadatenpfad für Auswahlen von Authentifizierungsoptionen, die Auflösung von --auth-choice, Zuordnung bevorzugter Provider und einfache Registrierung von CLI-Flags im Onboarding, bevor die Provider-Laufzeit geladen wird. Für Laufzeit- Wizard-Metadaten, die Provider-Code erfordern, siehe Provider-Laufzeit-Hooks.
• Exklusive Plugin-Arten werden über plugins.slots.* ausgewählt.
  • kind: "memory" wird über plugins.slots.memory ausgewählt.
  • kind: "context-engine" wird über plugins.slots.contextEngine ausgewählt (Standard: eingebautes legacy).
• channels, providers, cliBackends und skills können weggelassen werden, wenn ein Plugin sie nicht benötigt.
• Wenn Ihr Plugin von nativen Modulen abhängt, dokumentieren Sie die Build-Schritte und alle Anforderungen an die Paketmanager-Allowlist (zum Beispiel pnpm allow-build-scripts
  • pnpm rebuild <package>).

​

Verwandt

• Plugins erstellen — Erste Schritte mit Plugins
• Plugin-Architektur — interne Architektur
• SDK-Überblick — Referenz zum Plugin SDK