#5.7 poisoned custom plugin with openrouter collision

1 messages · Page 1 of 1 (latest)

muted berry
#

Running 2026.5.7 on Windows 11. Custom local before_dispatch plugin (id router-plugin) worked fine on 4.27 but stopped loading after upgrading. Plugin lives at ~/.openclaw/extensions/router-plugin/.

Root cause: plugins/installs.json has the router-plugin key resolving to two entries — first to the bundled openrouter provider (node_modules/openclaw/dist/extensions/openrouter/), then to my plugin. The bundled one wins and mine is dropped.

Evidence: When inspecting installs.json, the router-plugin key showed two pluginId fields in the same record — first "pluginId": "openrouter" pointing to dist/extensions/openrouter/ (bundled provider), then "pluginId": "router-plugin" pointing to my custom plugin. The bundled entry wins on every restart because the registry is regenerated and the collision reintroduces itself. No config change survives a restart.

One clean boot occurred immediately after openclaw plugins install --dangerously-force-unsafe-install --force — gateway showed 2 plugins: router-plugin, telegram and loaded correctly. Every subsequent restart dropped back to 1 plugin. The install writes the correct registry entry, but restart regenerates the registry and the collision reintroduces itself.

Things I've tried: plugins registry --refresh, renaming manifest id to carson-router (new duplicate collision), plugins install --force, plugins.load.paths pointing at my directory, plugins.entries.openrouter.enabled: false. Nothing survives a restart.

Is there a way to exclude the bundled openrouter from discovery, or force my local plugin to take precedence? Happy to share the full installs.json if useful. @foggy violet

unborn cosmosBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> âś… Mark Solution

muted berry
#

@foggy violet can you take a look and let me know on the comment above?

foggy violetBOT
#

I checked the current plugin docs/source against this. My read: this looks like a real 2026.5.7 plugin-index/discovery bug, not something you should be expected to fix in config.

What should happen: duplicate precedence is plugins.load.paths / config-selected plugin first, then explicit installed plugin, then bundled, then workspace. Bundled ids are “reserved” only unless you explicitly override/select a source. So a local plugin added via plugins.load.paths or openclaw plugins install --link <path> should beat a bundled duplicate.

There isn’t a clean supported “exclude bundled openrouter from discovery” switch. plugins.entries.openrouter.enabled: false / plugins.deny: ["openrouter"] can block activation, but they don’t remove bundled openrouter from the cold registry/index scan. plugins.bundledDiscovery is about runtime provider discovery with allowlists, not removing a bundled plugin from the generated index.

Best workaround to try, if you haven’t done this exact shape yet:

openclaw plugins uninstall router-plugin --keep-files
openclaw plugins install --link C:\\Users\\<you>\\.openclaw\\extensions\\router-plugin
openclaw gateway restart
openclaw plugins inspect router-plugin --runtime --json

And for a hook plugin, make sure the config has the conversation-hook permission if it reads/mutates the conversation/model routing: