Summary

After installing a managed npm plugin (openclaw plugins install npm:@openclaw/[email protected]) and enabling it, the gateway stops resolving every workspace plugin configured via plugins.load.paths. Each one is reported at startup as:

plugins.entries.<id>: plugin not found: <id> (stale config entry ignored; remove it from plugins config)
plugins.allow: plugin not found: <id> (stale config entry ignored; remove it from plugins config)

and the gateway comes up without them (in our case 19 plugins → 16: the npm plugin loaded, four workspace plugins dropped). The plugin files are present and unchanged on disk, and the same config loads all of them fine once the npm plugin is disabled again.

Environment

• OpenClaw 2026.6.10 (aa69b12), global npm install, macOS (Apple Silicon), gateway run as a LaunchAgent
• Four local workspace plugins under ~/.openclaw/workspace/plugins/<name>/ (each with openclaw.plugin.json + index.js), registered via plugins.load.paths and allowlisted in plugins.allow
• Managed plugin installed to ~/.openclaw/npm/projects/openclaw-llama-cpp-provider-<hash>/

Steps to reproduce

1. Working 2026.6.10 install with ≥1 workspace plugin registered via plugins.load.paths, enabled in plugins.entries, listed in plugins.allow. Confirm gateway startup line lists it.
2. openclaw plugins install npm:@openclaw/[email protected]
3. Add llama-cpp to plugins.allow, openclaw plugins enable llama-cpp
4. Restart the gateway.

Expected: previous plugins + llama-cpp.
Actual: llama-cpp loads; every plugins.load.paths plugin is dropped with the "stale config entry" warning above.

Additional observations

• The same "plugin not found" warnings appear in CLI context (openclaw plugins list, openclaw memory ...) with the npm plugin merely installed-but-disabled — so discovery in some contexts already stops seeing load.paths plugins once an npm plugin project exists on disk. The gateway only regresses once the npm plugin is enabled/restarted.
• Reverting the config (disable llama-cpp, remove from allow) and restarting fully restores the workspace plugins. Deterministic both directions.
• Searched existing issues; closest are [Bug]: Runtime-loaded workspace plugins — HTTP routes return 404, registerService callbacks never fire (cold-boot deferred-load path missing pinActivePluginHttpRouteRegistry + startPluginServices) #94572 (workspace plugin deferred-load) and [Bug]: openclaw doctor --fix automatically injects plugins.load.paths entry pointing at bundled plugin dir, causing circular warning #85334 (doctor --fix mangling load.paths) — neither matches this install-triggered resolution failure.

Happy to provide sanitized config excerpts or debug logs (OPENCLAW_DEBUG=1 startup) on request.