OpenClaw Plugin Inventory Explained

The OpenClaw plugin inventory is the map that prevents plugin work from turning into guesswork. The docs define which plugins ship in the core npm package, which official plugins install externally, and which repo-local plugins are source-checkout only.

30-second answer

Check the inventory before installing anything. A core plugin is already available in the openclaw npm package. An official external package is OpenClaw-maintained but omitted from core and installed on demand through ClawHub or npm. A source checkout only plugin is repo-local and not advertised as an installable package.

Why the inventory matters

Plugin distribution affects production reliability. If a plugin is in core, your runbook should focus on config and enablement. If it is external, your runbook needs install, Gateway restart, runtime inspection, and upgrade tracking. If it is source-only, do not promise it as a customer-ready install path.

The inventory page is generated from extensions/*/package.json, openclaw.plugin.json, and npm package file exclusions. The documented regeneration command is pnpm plugins:inventory:gen, which is maintainer-facing rather than an operator's everyday setup step.

Install pattern

openclaw plugins install @openclaw/discord
openclaw gateway restart
openclaw plugins inspect discord --runtime --json

The docs use Discord as an official external package example. Bare package specs try ClawHub first, then npm fallback. Operators who need to force a source can use clawhub: or npm: package prefixes. After install, always follow the plugin's setup doc for credentials and channel config.

Local checkout behavior

Source checkouts behave differently from npm installs. After pnpm install, bundled plugins load from extensions/<id>, so local edits and package-local workspace dependencies are available. That is useful for maintainers, but it is not the same promise as a published plugin package.

Buyer-intent angle

If you are evaluating OpenClaw for a business workflow, inventory status tells you how risky the integration path is. Included core plugins are lower-friction. Official external plugins are still supported but need deployment discipline. Source-only experiments should stay out of revenue-critical automation until they have a packaged path and setup proof.

Operator checklist

Before planning a new automation, answer four questions: is the plugin included, external, or source-only; what setup document owns credentials; what command proves runtime registration; and what restart or reload is required. Then write those answers into the runbook before handing the workflow to an agent.

The OpenClaw Playbook turns that inventory habit into an operating pattern: verify the extension boundary first, then automate the business process only after the plugin has a boring, repeatable install and recovery path.

Rollout plan

Treat OpenClaw Plugin Inventory Explained as a workflow you roll out in stages, not a switch you flip once. Start with the smallest harmless proof: a status check, dry run, local-only call, private session, or read-only inspection. Confirm the documented behavior matches your installed OpenClaw version, then write the exact commands and expected output into the workspace so the next agent does not rely on memory or vibes.

For a production runbook, document decision owner, source document, acceptance check, upgrade risk, and where future agents should look before changing the behavior. Also write down what the agent may do alone, what requires approval, and what must stop immediately. That boundary is the difference between useful autonomy and a workflow that surprises the operator at the worst possible time.

Keep one rollback note beside the guide. It can be as simple as the command to disable a plugin, the channel to pause, the config key to revert, or the owner who must approve the next run. Include the proof that tells you rollback worked, and keep it visible near the production checklist for future maintainers. Agents are most useful when recovery is obvious.

After the first live run, review the transcript or logs while the details are fresh. Look for missing prerequisites, stale assumptions, broad prompts, confusing errors, and any external side effect that should have been gated. Tighten the guide, then repeat with one wider scope. The OpenClaw Playbook is built around this operating rhythm: cautious first proof, written runbook, verified automation, then gradual autonomy once the evidence is boring.