OpenClaw Core Concepts #8: What Are Plugins? Extending Your AI Agent With New Organs - haiai.world

You’ve made it through the full core stack. You know how the Gateway routes everything, how the Agentic Loop runs the agent, how Memory persists knowledge, how the Agent identity defines who the agent is, how Tools give the agent hands and eyes, how Skills teach it how to work well, and how Sessions hold it all together turn by turn.

Now we go deeper. Into the layer that sits beneath Skills and beside the core runtime itself.

That layer is Plugins.

If Skills are textbooks — Markdown playbooks that tell the model how to use what it already has — then Plugins are new organs. They’re compiled code modules that run in-process with the Gateway and can register entirely new things: new chat channels, new model providers, new agent tools, new speech engines, new memory backends, new lifecycle hooks. Plugins don’t teach the agent; they change what the agent fundamentally is.

This is also where the security stakes get significantly higher. A malicious Markdown file can mislead the model. A malicious plugin can do anything the Gateway process can do. That distinction is not subtle.

Let’s understand this layer properly.

Quick recap: where we are in the series

#	Topic	What it answers
#1	Gateway	What’s the central nervous system?
#2	Agentic Loop	How does the agent actually run?
#3	Memory	How does the agent remember things?
#4	Agent	What is the agent, at its core?
#5	Tools	What can the agent physically do?
#6	Skills	How does the agent know how to do it well?
#7	Sessions	How does the agent track who, where, and what?
#8	Plugins	How do you add entirely new capabilities to the core runtime?

1. What a plugin actually is (the one-sentence version)

A plugin is a small TypeScript code module that loads in-process with the Gateway and registers new capabilities via a structured API.

That one sentence has four load-bearing words worth unpacking:

TypeScript module: not Markdown, not YAML, not config — actual executable code. The Plugin SDK exposes a typed surface, but what runs is compiled JavaScript evaluated via jiti at Gateway startup.
In-process: the plugin runs inside the same Node.js process as the Gateway. It shares memory, can call Gateway internals, and has no sandbox between it and your machine. This is what makes plugins powerful — and what makes them dangerous.
Registers new capabilities: a plugin doesn’t patch or override OpenClaw’s core. It calls registration methods (registerChannel, registerTool, registerProvider, etc.) that slot new things into the existing architecture cleanly.
Via a structured API: the plugin receives an api object at activation time and everything it can do is mediated through that object. It can’t arbitrarily monkey-patch the Gateway — it works through defined extension points.

The official definition: “A plugin is just a small code module that extends OpenClaw with extra features (commands, tools, and Gateway RPC).” That captures it well, though “small code module” undersells what a plugin can actually contain.

2. Plugins vs. Skills: the definitive comparison

This confuses almost everyone coming from the Skills article. Here’s the table that settles it:

	Skills	Plugins
What they are	Markdown documents (`SKILL.md`)	TypeScript/JavaScript code modules
Where they run	Inside the model’s context window	In-process with the Gateway (Node.js)
What they can do	Tell the model how to use existing tools	Register new tools, channels, providers, hooks
Can they grant new permissions?	No — skills work within existing tool permissions	Yes — plugins can introduce entirely new tool types
Security blast radius	Model is misled; agent behaves unexpectedly	Gateway process is compromised; full machine access
Who writes them	Anyone who can write Markdown	Anyone who can write TypeScript and understands the Plugin SDK
Installation vector	ClawHub / GitHub URL / local file	npm registry / ClawHub / local path / archive
Analogy	Textbooks and training manuals	Transplanted organs

The mental model: Skills train the agent; Plugins transform it.

A skill that says “use web_search to find news” teaches the agent a workflow — but web_search has to already exist as a tool. A plugin can create a new tool that didn’t exist before, register it with the Gateway, expose it to the model’s context via a JSON schema, and make it callable just like any built-in tool.

3. The two plugin formats: native and bundle

OpenClaw recognizes two distinct plugin formats. You’ll encounter both in the wild:

3.1 Native plugins

The primary format. A native plugin is a TypeScript file (or a package directory) that exports a default entry object. Every native plugin must include an openclaw.plugin.json manifest file at its root:

{
  "id": "voice-call",
  "name": "Voice Call",
  "version": "1.4.2",
  "description": "Outbound and inbound phone calls via Twilio, Telnyx, or Plivo",
  "main": "./dist/index.js",
  "configSchema": "./dist/config.schema.json"
}

The entry point exports a registration function that OpenClaw calls during plugin activation:

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

export default definePluginEntry({
  id: "voice-call",
  name: "Voice Call",
  register(api) {
    api.registerChannel({ /* channel definition */ });
    api.registerTool({ /* tool definition */ });
    api.registerHook("before:run", async (ctx) => { /* hook logic */ });
  },
});

register(api) is the current contract. Older plugins may use activate(api) — the loader still falls back to this for backwards compatibility — but all new plugins should use register. Config validation happens via the JSON Schema in the manifest; no plugin code is executed during config validation, which is an important security property.

3.2 Bundle plugins

A compatibility format that maps external tool ecosystem layouts to OpenClaw features. Current runtime support includes:

Bundle skills from compatible Codex, Claude, and Cursor plugin directories
Claude settings.json defaults and .lsp.json manifest-declared LSP server entries
Cursor command-skills
Compatible Codex hook directories

Bundle plugins participate in the same plugin list / inspect / enable / disable flow as native plugins. openclaw plugins inspect <id> reports detected bundle capabilities and flags any unsupported MCP or LSP server entries. If you’re coming from a Claude or Cursor plugin ecosystem, this is the bridge that gets your existing tooling into OpenClaw without a full rewrite.

4. What plugins can actually register

This is the heart of it. The Plugin SDK’s api object exposes registration methods for every major extension point in the Gateway:

Registration method	What it creates	Typical use case
`registerProvider`	A new LLM model provider	Connecting a local Ollama instance, adding a new API provider
`registerChannel`	A new chat channel	Adding Matrix, Nostr, Microsoft Teams, Zalo, custom Slack app
`registerTool`	A new agent tool	Any capability that doesn’t exist in the 26 built-in tools
`registerHook` / `on(...)`	A lifecycle hook	Run logic before prompt build, after tool call, on session reset
`registerSpeechProvider`	Text-to-speech / STT backend	Custom voice synthesis via ElevenLabs, Azure TTS, etc.
`registerRealtimeTranscriptionProvider`	Streaming speech-to-text	Live transcription during voice sessions
`registerRealtimeVoiceProvider`	Duplex realtime voice	Full two-way voice conversation interfaces
`registerMediaUnderstandingProvider`	Image / audio analysis	Custom vision models, local CLIP embeddings
`registerImageGenerationProvider`	Image generation	DALL-E, Stable Diffusion, custom image APIs
`registerMusicGenerationProvider`	Music generation	Custom music synthesis backends
`registerVideoGenerationProvider`	Video generation	xAI grok-imagine-video, Runway, Wan, and others
`registerWebFetchProvider`	Custom web fetch backend	Custom proxied fetch, authenticated scraping

Reading this list makes the depth of the plugin system clear. Skills can only shape how the model uses group:ui or group:fs tools. Plugins can add a brand new registerVideoGenerationProvider that didn’t exist anywhere in the built-in layer.

One registration method deserves special attention: registerHook. Lifecycle hooks let a plugin intercept and react to Gateway events at key points in the Agentic Loop:

// Run logic before the system prompt is assembled
api.registerHook("before:context-assembly", async (ctx) => {
  ctx.extraContext = await fetchDynamicContextFromExternalSystem();
});

// Run logic after every tool call completes
api.registerHook("after:tool-call", async (ctx) => {
  await auditLog.record(ctx.toolCall, ctx.result);
});

// Run logic on /new command (session reset)
api.registerHook("command:new", async (ctx) => {
  await notifyExternalSystem(`Session reset for ${ctx.sessionKey}`);
});

Plugin-managed hooks show up in openclaw hooks list with a plugin:<id> prefix. You can’t enable or disable them independently — enable or disable the plugin instead.

5. Bundled plugins: what ships with OpenClaw

Many plugins are bundled — they ship with OpenClaw’s core installation rather than requiring a separate npm install. Bundled plugins must still be explicitly enabled (they don’t activate by default just because they exist), but they don’t require a network download.

Key bundled plugins you should know:

Memory plugins (slot-managed):

memory-core — the default bundled memory search backend. Active by default via plugins.slots.memory = "memory-core".
memory-lancedb — the install-on-demand long-term memory plugin with auto-recall and auto-capture. Switch to it with plugins.slots.memory = "memory-lancedb". This is the plugin that makes Memory feel genuinely intelligent rather than just archival.

Channel plugins (bundled, some enabled by default):

browser — the bundled Chromium browser plugin. Powers group:ui tools including browser and canvas. Enabled by default.
copilot-proxy — VS Code Copilot Proxy bridge. Bundled but disabled by default.

Model providers (bundled): A large list ships bundled, covering all the major providers: anthropic, openai, google, minimax, mistral, qwen, moonshot, openrouter, volcengine, huggingface, together, venice, and many more. These are enabled based on which API keys you configure — you don’t need to install them separately.

The plugins.slots mechanism is worth understanding: certain capabilities have “slot” positions — a specific slot that only one plugin can fill at a time. Memory is the clearest example: plugins.slots.memory takes a single plugin ID. Only one memory backend is active at once. Slots prevent conflicts where two plugins both try to handle the same capability.

{
  "plugins": {
    "slots": {
      "memory": "memory-lancedb",
      "contextEngine": "legacy"
    }
  }
}

6. Installing and managing plugins

6.1 The four install paths

OpenClaw resolves plugin installs through a priority order, and you can install from four different sources:

Bash

# From npm (ClawHub first, then npm fallback)
openclaw plugins install @openclaw/voice-call

# Pin exact resolved version for reproducible installs
openclaw plugins install @openclaw/voice-call --pin

# From a local directory (copies into ~/.openclaw/extensions/<id>)
openclaw plugins install ./my-plugin

# Link a local directory (no copy — dev workflow)
openclaw plugins install -l ./my-plugin

# From a tarball or zip archive
openclaw plugins install ./my-plugin.tgz

# From a marketplace (GitHub shorthand, URL, or known marketplace name)
openclaw plugins install my-plugin --marketplace owner/repo

Important: npm specs are registry-only (package name + optional version/tag). Git URLs and raw file URLs are rejected by design. If you need to install from GitHub, use the --marketplace flag with the owner/repo shorthand — this uses a controlled clone path with defined trust boundaries, not an arbitrary URL fetch.

6.2 Chat-native install (if you prefer staying in the conversation)

Enable commands.plugins: true in your config and you can manage plugins directly from chat:

/plugin install clawhub:@openclaw/voice-call
/plugin show voice-call
/plugin enable voice-call
/plugin disable voice-call

The chat install path uses the same resolver as the CLI — clawhub:<pkg> for explicit ClawHub installs, bare package name for ClawHub-first with npm fallback. Same security rules apply.

6.3 The plugin discovery order (first match wins)

OpenClaw scans for plugins in this order, and the first match for a given ID wins:

Paths listed in plugins.load.paths (explicit local overrides)
<workspace>/.openclaw/*.ts and <workspace>/.openclaw/*/index.ts
~/.openclaw/*.ts and ~/.openclaw/*/index.ts
Managed installs (~/.openclaw/extensions/)
Bundled plugins (shipped with OpenClaw)

This mirrors the three-tier priority system in Skills: workspace-level overrides win, bundled is the fallback. If two plugins resolve to the same ID, only the first-discovered one loads. Remove duplicates if you see unexpected behavior.

6.4 Configuration: allow, deny, entries

Plugin permissions follow the same allow/deny pattern used for Tools:

JSON

{
  "plugins": {
    "enabled": true,
    "allow": ["voice-call", "memory-lancedb"],
    "deny": ["untrusted-plugin"],
    "load": {
      "paths": ["~/Projects/my-plugin"]
    },
    "entries": {
      "voice-call": {
        "enabled": true,
        "config": {
          "provider": "twilio",
          "accountSid": "ACxxxxxxxx",
          "authToken": "{{env.TWILIO_AUTH_TOKEN}}"
        }
      }
    }
  }
}

deny entries are hard-blocked regardless of what appears in allow. This is the same deny-wins logic that governs tool permissions — and for the same reason: you want an absolute ceiling on what can load, not a negotiation.

Config changes require a Gateway restart. If the Gateway is running with config watch and in-process restart enabled (the default openclaw gateway startup path), that restart happens automatically a moment after the config write lands.

6.5 Plugin states

When you run openclaw plugins list --verbose, each plugin has one of four states:

State	Meaning
Active	Loaded and running
Disabled	Exists but turned off by enablement rules; config is preserved
Missing	Config references an ID that plugin discovery didn’t find
Invalid	Plugin exists but its config doesn’t match the declared JSON Schema

Invalid is the state that bites people most often during initial setup. Run openclaw doctor --fix when you hit it — the doctor knows the common fix paths and applies them non-destructively.

7. The plugin manifest: the contract between a plugin and the Gateway

Every native plugin must include an openclaw.plugin.json manifest in its root directory. The manifest is what OpenClaw reads during config validation — no plugin code executes at validation time, only the manifest and JSON Schema. This is a deliberate security property: you can validate a config that references a plugin without running any of that plugin’s code.

A complete manifest:

JSON

{
  "id": "my-analytics-plugin",
  "name": "Analytics Plugin",
  "version": "1.0.0",
  "description": "Sends usage events to an internal analytics endpoint",
  "main": "./dist/index.js",
  "configSchema": "./dist/config.schema.json",
  "openclaw": {
    "capabilities": ["tool", "hook"],
    "requiredEnv": ["ANALYTICS_API_KEY"],
    "eligibility": {
      "os": ["linux", "darwin", "win32"]
    }
  }
}

The capabilities array declares what the plugin registers. OpenClaw uses this for manifest-declared activation — narrowing CLI, provider, and channel loading to only what the plugin actually needs. This prevents startup from loading unrelated plugin runtime for plugins that, for example, only need to register a hook and nothing else. Precise capability declarations make startup leaner and trust boundaries clearer.

The requiredEnv array gates plugin eligibility: if a required environment variable isn’t set, the plugin loads in a degraded state or doesn’t activate, rather than crashing mid-run. Same principle as the requires.env block in a SKILL.md file — declare your dependencies honestly so the system can fail gracefully rather than mysteriously.

8. Building your own plugin: the minimal path

If you need a capability that doesn’t exist yet — a custom tool, a new channel, an integration with an internal API — building a plugin is more approachable than it looks. The SDK is well-typed and the registration surface is consistent.

Minimal plugin structure

text

my-plugin/
  openclaw.plugin.json    ← manifest (required)
  index.ts                ← entry point
  config.schema.json      ← JSON Schema for your config (if any)
  package.json            ← npm package descriptor
  node_modules/           ← your dependencies (npm install here)

The entry point

TypeScript

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

export default definePluginEntry({
  id: "my-analytics-plugin",
  name: "Analytics Plugin",

  register(api) {

    // Register a new agent tool
    api.registerTool({
      name: "analytics_track",
      description: "Track a custom event to the internal analytics system",
      parameters: {
        type: "object",
        properties: {
          event: { type: "string", description: "Event name" },
          properties: { type: "object", description: "Event properties" }
        },
        required: ["event"]
      },
      async execute(params, ctx) {
        const apiKey = ctx.config.plugins.entries["my-analytics-plugin"].config.apiKey;
        await fetch("https://analytics.internal/track", {
          method: "POST",
          headers: { Authorization: `Bearer ${apiKey}` },
          body: JSON.stringify({ event: params.event, props: params.properties })
        });
        return { success: true };
      }
    });

    // Register a lifecycle hook
    api.registerHook("after:run", async (ctx) => {
      // Called after every agent run completes
      await logRunMetrics(ctx.tokenUsage, ctx.sessionKey);
    });

  }
});

Development workflow

For active development, use --link to avoid repeated copy installs:

Bash

# Link your local plugin directory (no copy)
openclaw plugins install -l ./my-plugin

# Check it loaded
openclaw plugins list --enabled

# Inspect its status
openclaw plugins inspect my-analytics-plugin

# Run diagnostics
openclaw plugins doctor

# Restart Gateway to pick up code changes
openclaw gateway restart

Each time you change the plugin code, restart the Gateway. With config watch enabled, openclaw.json changes trigger an automatic restart — but code changes in your TypeScript files require a manual restart.

9. Security: the part you absolutely cannot skip

Let’s be direct: plugins are the most powerful and most dangerous extension point in OpenClaw. Skills can mislead the model. Plugins can own the machine.

This isn’t hypothetical. A plugin that registers a registerHook("before:run") handler has unrestricted access to run arbitrary Node.js code in the Gateway process, on every single agent turn, before any tool permission checks, before any model inference. It can read files, make network calls, exfiltrate environment variables, or silently modify the context the model sees.

You cannot audit this risk away completely. You can only manage it — by being deliberate about every plugin you load.

The threat model

Supply chain attacks via npm: plugins install via npm, and npm packages can have nested dependencies. A plugin that looks benign may depend on a package that was recently compromised. Unlike skill Markdown files where you read the content directly, a plugin’s full dependency tree can be opaque.

Dependency confusion: a plugin that imports "internal-package" could be resolving to a malicious npm package if your npm config is misconfigured. Use --pin to lock to exact resolved versions for production installs.

Lifecycle hook abuse: a plugin registering before:run hooks with overly broad logic is effectively intercepting every agent turn. Evaluate what each hook does and why it needs to.

Config exfiltration: plugins receive a ctx object that contains config. A plugin could read API keys, auth tokens, and other secrets from that context and send them to a remote server. This is why the requiredEnv declaration matters — it signals what the plugin legitimately needs access to.

OpenClaw’s built-in defenses

--ignore-scripts on install: openclaw plugins install runs npm install --ignore-scripts internally, blocking postinstall scripts from executing during the install phase. This prevents the most common npm supply chain attack vector — malicious postinstall hooks.

Dangerous-code scanner: the install flow includes a built-in scan for dangerous code patterns. If critical findings are detected, install fails closed. The --dangerously-force-unsafe-install flag bypasses scanner findings (it’s a break-glass for false positives) but it does not bypass before_install policy blocks or scan-failure blocking. Use it only when you understand exactly what the scanner flagged and why it’s a false positive.

Manifest-declared activation: plugins narrow their runtime footprint to declared capabilities. A plugin that only declares ["hook"] in its capabilities won’t load channel or provider runtime at startup. Less attack surface at startup means less risk from partially-loaded compromised plugins.

Config validation without code execution: the manifest + JSON Schema validation path never runs plugin code. This is a hard separation: OpenClaw can validate a config referencing a plugin without trusting or running that plugin.

Your non-negotiable pre-install checklist

Read the source. Every plugin installed from a local path, you read before you install. For npm packages, review the source on GitHub before running openclaw plugins install. The npm tarball and the GitHub source should match — if they don’t, that’s a red flag.
Check the full dependency tree. Run npm pack --dry-run on the plugin source, or inspect the resolved dependency tree with npm ls. A plugin that needs 47 transitive dependencies to register a simple tool is suspicious.
Use --pin for production. Pin exact resolved versions (openclaw plugins install @openclaw/voice-call --pin) so future update runs don’t silently pull in a compromised version.
Apply explicit deny for plugins you don’t want. Don’t rely on “I just won’t install it.” Explicitly deny plugin IDs you want to block so that even if they somehow end up in a plugins.load.paths directory, they won’t activate.
Prefer bundled plugins where they exist. The bundled memory, browser, and model provider plugins are maintained by the OpenClaw core team, ship with the main repo, and go through the same review process as the core runtime. Use them over community alternatives unless you have a specific reason.
Sandbox aggressively in development. When evaluating a community plugin, run it in an isolated workspace with a minimal tool profile and no production credentials. Watch what it does in openclaw plugins inspect before you trust it with a real environment.
Never use --dangerously-force-unsafe-install on code you didn’t write. If the scanner found something, understand what it found. The flag name is not subtle: it is dangerous.

10. Notable official and community plugins

Here’s a cross-section of plugins worth knowing, from official to community:

Official `@openclaw/` plugins

Package	What it does
`@openclaw/voice-call`	Outbound and inbound phone calls via Twilio, Telnyx, or Plivo. The reference example for plugin development.
`@openclaw/msteams`	Microsoft Teams channel. Teams is plugin-only as of 2026-01-15 — no built-in support.
`@openclaw/matrix`	Matrix protocol channel
`@openclaw/nostr`	Nostr protocol channel
`@openclaw/zalo`	Zalo group messaging
`@openclaw/zalouser`	Zalo personal (QR login via native zca-js)

Community highlights

Composio (@composio/openclaw): connects OpenClaw to 850+ SaaS apps via a managed MCP server — Gmail, GitHub, Notion, Salesforce, and more — handling all OAuth logic automatically. Instead of installing individual skills per app, this single plugin covers the whole SaaS surface.
MemOS Cloud (@memtensor/memos-cloud-openclaw-plugin): replaces the default memory backend with a cloud-hosted hierarchical knowledge graph. Full multi-agent support: each agent gets isolated memory scoped by agent_id.
SecureClaw (@adversa/secureclaw): OWASP-aligned security auditing and runtime hardening. Maps agent actions to the OWASP Top 10 for AI Agents, provides real-time prompt injection detection, and generates security audit reports. High value for production deployments.
OpenClaw Foundry (@getfoundry/foundry): a meta-extension that observes your workflows, reads the OpenClaw docs, and writes new skills, hooks, and tools directly into your setup. Validates generated code in a sandbox before deploying it. The self-modifying agent concept made concrete.

11. End-to-end example: a plugin doing real work

Let’s trace exactly what happens when the Voice Call plugin is installed and the agent makes a phone call.

Setup:

Bash

openclaw plugins install @openclaw/voice-call
# Gateway restarts automatically (config watch enabled)

JSON

{
  "plugins": {
    "entries": {
      "voice-call": {
        "enabled": true,
        "config": {
          "provider": "twilio",
          "accountSid": "ACxxxxxxxx",
          "authToken": "{{env.TWILIO_AUTH_TOKEN}}",
          "fromNumber": "+15550001234"
        }
      }
    }
  }
}

What happened at startup:

Gateway scanned ~/.openclaw/extensions/voice-call/
Read openclaw.plugin.json manifest → ID voice-call, capabilities ["channel", "tool"]
Called register(api) → plugin registered a voicecall tool and a /voicecall top-level CLI command
Tool schema injected into model context — voicecall now appears alongside web_search, fs:read, etc.

You type: "Call Alice at +1-555-987-6543 and let her know the meeting is moved to 3pm"

Gateway receives message → Session key resolved → context assembled
Model inference → model sees voicecall tool in schema → decides to call it
Tool execution → plugin’s execute handler fires → Twilio API call initiated
Call placed → Twilio dials Alice → plugin handles the voice session → call completes
Result returned → { success: true, callSid: "CA...", duration: 42 } → model formats reply
Session transcript updated → Memory notes call completed if the agent is configured to persist task outcomes

Without the plugin: voicecall doesn’t exist in the tool schema. The model would write “I don’t have the ability to make phone calls.” With the plugin: it just makes the call. That’s the delta plugins create.

The three-sentence summary

A Plugin is a TypeScript code module that runs in-process with the Gateway and registers new capabilities — channels, tools, model providers, speech backends, lifecycle hooks — via a structured SDK API, extending OpenClaw at the runtime layer rather than the prompt layer. Plugins are more powerful than Skills, more dangerous than Tools, and must be treated as fully trusted code: they run in the Gateway process with no sandbox between them and your machine. Install only from sources you’ve read and understood, use --pin for production, apply explicit deny for anything you don’t want, and prefer official bundled plugins over community alternatives wherever they cover your use case.

What’s next

We’ve now covered the complete eight-concept stack. In #9, we’ll explore MCP — Model Context Protocol: the open standard that lets OpenClaw act as a host connecting to external tool servers, the community of MCP servers already available, and how MCP fits into the plugins/tools/skills hierarchy you now understand fully. If Plugins are organs transplanted directly into the Gateway, MCP is the standard connector port that lets OpenClaw plug into the broader AI tooling ecosystem without a custom plugin for every integration.

References

OpenClaw Official Docs — Plugins https://docs.openclaw.ai/tools/plugin
OpenClaw Official Docs — Building Plugins https://docs.openclaw.ai/tools/building-plugins
OpenClaw Official Docs — Plugin Manifest https://docs.openclaw.ai/tools/plugin-manifest
OpenClaw Official Docs — Plugin Agent Tools https://docs.openclaw.ai/tools/plugin-agent-tools
OpenClaw Official Docs — Community Plugins https://docs.openclaw.ai/tools/community-plugins
openclaw-ai.com — Plugins | OpenClaw Docs https://openclaw-ai.com/en/docs/tools/plugin
openclawlab.com — Plugins | OpenClaw Docs https://openclawlab.com/en/docs/tools/plugin/
openclawcn.com — Plugins | OpenClaw Docs https://openclawcn.com/en/docs/tools/plugin/