Bug type

Regression (worked before, now fails)

Summary

All plugin HTTP routes return 404 after installing the BlueBubbles channel — the webhook registers successfully per logs but is never reachable via HTTP.

Steps to reproduce

1. Install [email protected] via npm install -g
2. Add BlueBubbles channel: openclaw channels add --channel bluebubbles --http-url http://127.0.0.1:1234 --password REDACTED
3. Start gateway: openclaw daemon restart
4. Confirm gateway is up: curl -i http://127.0.0.1:18789/healthz → 200 OK
5. Test plugin routing: curl -i http://127.0.0.1:18789/plugins/diffs/view/demo-id/demo-token → 404
6. Test BlueBubbles webhook: curl -i -X POST "http://127.0.0.1:18789/bluebubbles-webhook?password=REDACTED" -H "Content-Type: application/json" --data '{}' → 404
7. Tested with gateway.controlUi.enabled: false — same result

Expected behavior

• GET /bluebubbles-webhook → 405 Method Not Allowed
• POST /bluebubbles-webhook → 401 or 400
• GET /plugins/diffs/view/demo-id/demo-token → any non-404 response

Actual behavior

All plugin HTTP paths return 404 consistently regardless of Control UI state, password inclusion, or plugin allow list configuration.

OpenClaw version

2026.3.13 (61d171a)

Operating system

macOS (Apple Silicon)

Install method

npm install -g openclaw@latest (global)

Model

anthropic/claude-sonnet-4-5

Provider / routing chain

Anthropic API direct

Config file / key location

~/.openclaw/openclaw.json gateway.port: 18789 gateway.bind: lan gateway.mode: local agents.defaults.workspace: ~/.openclaw/workspace channels.bluebubbles.webhookPath: /bluebubbles-webhook plugins.allow: ["bluebubbles"]

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Gateway log confirms channel running:
[bluebubbles] [default] BlueBubbles webhook listening on /bluebubbles-webhook

openclaw channels status --probe output:
BlueBubbles default: enabled, configured, running, connected, works

curl -i http://127.0.0.1:18789/healthz → 200 OK
curl -i http://127.0.0.1:18789/plugins/diffs/view/demo-id/demo-token → 404
curl -i -X POST http://127.0.0.1:18789/bluebubbles-webhook → 404

Impact and severity

Blocks BlueBubbles/iMessage channel entirely. Channel shows running and connected but no inbound messages can reach the agent. Affects any user adding the BlueBubbles channel on 2026.3.13. Severity: blocks workflow. Frequency: always reproducible.

Additional information

Based on Discord community discussion, this appears to be a plugin registry mismatch: dynamic registerPluginHttpRoute() registers routes into a different registry instance than the one the HTTP dispatcher captured at startup. The /plugins/diffs/view/demo-id/demo-token test confirms all plugin HTTP routing is dead globally, not just BlueBubbles. Rollback to 2026.3.7 not viable as config written by 2026.3.13 causes version mismatch warnings.