OpenClaw plugins: how to find, assess, and verify them

OpenClaw plugins are easiest to evaluate when discovery answers two different questions: what capability do you need, and which package should you trust to provide it? In v2026.9.4, the Plugins page brings installed plugins and ClawHub listings into one browsing surface. That removes a common bit of friction, but it does not replace source review or a runtime check after installation.

The useful workflow is short: search by the job you want done, distinguish an available listing from something already installed, review the package source and permissions, then verify the running capability. This matters most for agents that touch messaging, calendars, browsers, local files, or credentials.

What changed in OpenClaw plugin discovery

OpenClaw v2026.9.4 combines installed-plugin administration and ClawHub discovery in the Control UI. The release work adds category browsing, a unified search surface, and chat cards that can show an official listing and whether it is already installed. The card can lead to the existing installation review rather than silently adding a package.

That is a better starting point than treating a capability request as a package name. Someone asking for WhatsApp support, for example, needs to know whether a matching official plugin exists, whether it is installed, and whether channel setup remains after installation. Those are separate states.

State	What it tells you	What it does not prove
A catalog listing appears	A package matches the capability query	That it is installed or appropriate for your Gateway
The card says Installed	OpenClaw has recorded that plugin or skill as installed	That the running Gateway loaded the expected code
The plugin is enabled	The configured policy permits it to load	That its hook, channel, or tool works in your real workflow
A real test succeeds	The capability worked with the current configuration	That every future provider or channel condition will behave the same way

This distinction also fits the site’s explanation of how OpenClaw works: an agent request, a Gateway policy decision, and a tool execution are different layers. A discovery screen should make those layers visible rather than blur them.

A practical workflow for OpenClaw plugins discovery

1. Search by capability, not by guessed package name

Start with the user job. The CLI can search ClawHub directly:

openclaw plugins search "calendar"

In the v2026.9.4 Control UI, the same discovery path can search installed and available plugins together. Use the result to inspect the publisher, source, description, and current install state. If the result is only a near match, refine the capability query instead of installing the first similarly named package.

This is especially important when a capability is split across a plugin, an account connection, and a channel configuration. Plugin installation alone does not create a connected calendar or send a WhatsApp message.

2. Pick an explicit source when reproducibility matters

OpenClaw supports ClawHub, npm, git, local paths, and compatible marketplaces. The source prefix is part of the decision:

openclaw plugins install clawhub:<package>
openclaw plugins install npm:<package>
openclaw plugins install git:github.com/<owner>/<repo>@<ref>

The official plugin documentation recommends ClawHub for OpenClaw-native discovery, scans, version metadata, and install hints. A git source can be appropriate when you need a reviewed commit or tag. A local path is useful when developing a plugin on the same machine.

For production installs, pin versions or refs where possible. A generic package name may be convenient during exploration, but it makes incident review and repeatable deployment harder later. The self-hosted agent security guide covers why tool boundaries deserve the same attention as model selection.

3. Review policy before you install

A plugin can add tools, hooks, Gateway methods, channels, or provider integrations. Treat it as executable code.

OpenClaw’s plugin documentation distinguishes trusted catalog sources from arbitrary npm packages, git repositories, local paths, archives, and marketplace sources. Noninteractive installation of a new arbitrary source can require an explicit force flag after review. An operator can also use security.installPolicy to allow, warn, or block an install based on staged metadata and source content.

A sensible review asks:

1. Does this plugin need a capability you can name and justify?
2. Is the publisher and source the one you intended to install?
3. Does the plugin need credentials, filesystem access, browser access, or a channel connection?
4. Is there an existing installed plugin that already covers the job?
5. Can you pin the version or git ref used by the Gateway?

If your configuration uses plugins.allow, the plugin ID must be present for it to load. plugins.deny wins over the allowlist and per-plugin enablement. That makes the policy review operational, not decorative.

Install, configure, and verify the runtime

After review, install and enable the selected plugin. Plugin-specific settings live under plugins.entries.<id>.config:

openclaw plugins enable <plugin-id>
openclaw plugins inspect <plugin-id> --runtime --json

The second command is useful, but it has a narrow meaning. --runtime loads the plugin inside the inspecting CLI process and reports registered tools, hooks, services, Gateway methods, and plugin-owned CLI commands. It does not prove that an already-running Gateway loaded the same code.

Verify the actual workflow next. Send a harmless test message through a channel plugin, make a read-only calendar query, or trigger the tool you expect the agent to use. If the Gateway is stopped, start it to load saved changes. If it is running, plugin-management commands can apply changes without a full restart, although a plugin’s own restart policy may still require one.

For a broader install checklist, see why OpenClaw and the guide to provider plugins and leaner self-hosted installs. The common theme is simple: discovery is an input to a controlled change, not proof that the change is safe or working.

When chat recommendations are useful

The v2026.9.4 chat integration can surface an official ClawHub listing when an agent receives a capability question. The model supplies the query; the Gateway joins the result with the catalog identity and current installed state. That boundary is important because it avoids letting a text model invent a package identity or claim an installation status it has not checked.

Use chat recommendations to shorten the search step. Keep the final decision in the review and verification steps. A card that says Installed can save time, while the policy, configuration, and real capability test still protect the run.

FAQ

Does finding a plugin install it automatically?

No. Discovery tells you what is available or already installed. Installation, approval, configuration, enablement, and runtime verification are separate steps.

Is an Installed badge enough to trust a plugin?

No. It confirms OpenClaw has recorded an installation. Check the source, configured policy, runtime registrations, and a real capability test before relying on it in production.

Should I use ClawHub, npm, or git?

Use ClawHub when you want OpenClaw-native discovery and package metadata. Use npm for direct registry workflows, git when you need a reviewed repository reference, and a local path for development. Prefer an explicit source and pinned version when the install must be reproducible.

Why does a plugin appear installed but not work?

It may be disabled, excluded by plugins.allow, blocked by plugins.deny, missing configuration or credentials, or not loaded by the active Gateway. Inspect the runtime and test the capability that matters.

The point of plugin discovery is a safer next step

OpenClaw plugin discovery is useful because it puts the catalog and the current installation state in the same place. The operator still owns the decision: choose the intended source, review the access it needs, configure it explicitly, and test the running path.

That sequence is slower than clicking every promising card. It is much faster than debugging an agent that gained the wrong capability, loaded an unexpected package, or never reached the running Gateway.

Sources: OpenClaw v2026.9.4 release notes · OpenClaw plugins documentation · Unified plugin discovery and installation PR #142782 · OpenClaw plugin management reference