openclaw - 💡(How to fix) Fix @openclaw/[email protected] cannot activate when installed as standalone npm package (origin: global) — lazy-load path filters by manifest.origin === 'bundled' [1 comments, 2 participants]

Summary

@openclaw/[email protected] ships as a standalone npm package. When installed via openclaw plugins install @openclaw/brave-plugin (or equivalent), the plugin reaches Status: loaded in the CLI metadata layer, but its web-search provider is never reachable at runtime. The agent's web_search tool returns "no provider available."

Root cause

OpenClaw's runtime has a lazy-load path for capability providers at capability-provider-runtime-CcUn9vAQ.js:196 (loadCapabilityProviderEntries), which delegates to bundled-capability-runtime-BlLJoDsv.js:310 (loadBundledCapabilityRuntimeRegistry).

This path filters at line 348:

if (!manifest || manifest.origin !== "bundled" || !pluginIds.has(manifest.id)) continue;

@openclaw/brave-plugin installed as a standalone npm package has manifest.origin === "global", so it is rejected at this filter before its register() is ever invoked. By contrast, exa, perplexity, and firecrawl ship with the gateway and have origin: "bundled", so they pass.

The four startup-runtime branches in resolveGatewayStartupPluginPlanFromRegistry (channel-plugin-ids-B_qWBF4F.js:421-494) also don't admit brave: it has no channels, no cliBackends, no kind: "memory", and activation.onStartup: false. Even setting onStartup: true only adds it to the startup runtime registry — it doesn't fix the lazy-load filter.

Reproduction

1. Fresh openclaw 2026.5.2 install
2. openclaw plugins install @openclaw/brave-plugin
3. openclaw config set tools.web.search.provider 'brave'
4. openclaw config set plugins.entries.brave.config.webSearch.apiKey '<valid-brave-key>'
5. Restart gateway
6. Run a web_search via the agent

Expected: web_search returns brave results. Actual: web_search is disabled or no provider is available.

Verified with a valid brave key: direct curl against https://api.search.brave.com/res/v1/web/search returns HTTP 200 with the same key, so it's not a credentials issue.

Verification that the lazy-load path works for bundled providers

Configured exa with a dummy key, restarted, ran web_search: [tools] web_search failed: Exa API error (401): {"error":"Invalid API key","tag":"INVALID_API_KEY"}

Exa is also absent from the gateway's http server listening (N plugins: ...) line, but the lazy-load path still reaches it because exa has manifest.origin === "bundled". This confirms the gate is origin === "bundled" specifically, not anything about activation/startup.

Suggested fixes (any one would resolve)

1. Relax bundled-capability-runtime-BlLJoDsv.js:348 to accept manifest.origin === "global" plugins for capability resolution.
2. Fold @openclaw/brave-plugin into the gateway's bundled extensions (parallel to exa/perplexity/firecrawl).
3. Add a loadGlobalCapabilityRuntimeRegistry for npm-installed plugins that mirrors the bundled loader.

Environment

• openclaw 2026.5.2
• macOS (Mac Mini, Apple Silicon)
• Gateway running under launchd
• @openclaw/[email protected]