Bug type

Behavior bug (incorrect output/state without crash)

Summary

BlueBubbles webhook appears to be listening, but POST /bluebubbles-webhook returns 404 in OpenClaw 2026.3.12

Environment

• OpenClaw: 2026.3.12
• BlueBubbles Server: 1.9.9
• macOS: 26.3.1
• Gateway: local, 127.0.0.1:18789
• BlueBubbles server URL: http://127.0.0.1:1234

Summary
BlueBubbles receives incoming iMessages correctly, but OpenClaw never processes them because webhook delivery to OpenClaw returns 404 Not Found.

What makes this confusing is that OpenClaw logs repeatedly say:

• starting provider (webhook=/bluebubbles-webhook)
• BlueBubbles webhook listening on /bluebubbles-webhook

So according to the logs, the route is registered and listening, but actual HTTP POST requests to that path still return 404.

Relevant configuration

"channels": {
"bluebubbles": {
"enabled": true,
"serverUrl": "http://127.0.0.1:1234",
"password": "REDACTED",
"webhookPath": "/bluebubbles-webhook",
"dmPolicy": "pairing",
"groupPolicy": "allowlist"
}
}

Steps to reproduce

1. Start the OpenClaw gateway
2. Start BlueBubbles Server
3. Confirm OpenClaw logs show:

• starting provider (webhook=/bluebubbles-webhook)
• BlueBubbles webhook listening on /bluebubbles-webhook

4. Send an iMessage that BlueBubbles receives
5. BlueBubbles attempts webhook delivery to:

• http://127.0.0.1:18789/bluebubbles-webhook?password=REDACTED

6. Delivery fails with 404 Not Found

Manual reproduction
This also reproduces with a direct POST request:

curl -i -X POST 'http://127.0.0.1:18789/bluebubbles-webhook?password=REDACTED' \
-H 'Content-Type: application/json' \
--data '{"type":"new-message","foo":"bar"}'

Response:

HTTP/1.1 404 Not Found

Actual behavior

• BlueBubbles Server receives inbound messages
• BlueBubbles attempts webhook delivery to OpenClaw
• OpenClaw responds with 404 Not Found
• Incoming BlueBubbles messages never reach the agent

Expected behavior
If the route is truly registered and listening, POST requests to /bluebubbles-webhook should hit the BlueBubbles plugin handler.

If the payload or authentication is invalid, I would expect a response like:

• 400 Bad Request
• 401 Unauthorized
• 403 Forbidden

But the current behavior is 404 Not Found, which suggests the route is not actually reachable even though the logs say it is listening.

BlueBubbles Server log examples
BlueBubbles logs show that inbound messages are detected and webhook delivery is attempted:

• New Message from +*********4964, "test"
• Dispatching event to webhook: http://127.0.0.1:18789/bluebubbles-webhook?password=REDACTED
• Failed to dispatch "new-message" event ...
• Error: Request failed with status code 404

OpenClaw observations

• openclaw status shows BlueBubbles as configured and enabled
• the plugin is enabled and loaded
• gateway logs repeatedly show:
• starting provider (webhook=/bluebubbles-webhook)
• BlueBubbles webhook listening on /bluebubbles-webhook
• but actual POST requests still return 404

Additional notes
There may also be a separate BlueBubbles-side limitation in this environment:

• private_api: false
• helper_connected: false

However, that appears to be secondary. The blocking issue is that the webhook route itself appears unavailable despite the logs claiming it is listening.

Suspected cause
This looks like a regression in plugin HTTP route registration or dispatch in newer OpenClaw versions, possibly related to Control UI / SPA route handling.

Steps to reproduce

Steps to reproduce

1. Start the OpenClaw gateway
2. Start BlueBubbles Server
3. Confirm OpenClaw logs show:

• starting provider (webhook=/bluebubbles-webhook)
• BlueBubbles webhook listening on /bluebubbles-webhook

4. Send an iMessage that BlueBubbles receives
5. BlueBubbles attempts webhook delivery to:

• http://127.0.0.1:18789/bluebubbles-webhook?password=REDACTED

6. Delivery fails with 404 Not Found

Expected behavior

If the route is truly registered and listening, POST requests to /bluebubbles-webhook should hit the BlueBubbles plugin handler.

If the payload or authentication is invalid, I would expect a response like:

• 400 Bad Request
• 401 Unauthorized
• 403 Forbidden

Actual behavior

But the current behavior is 404 Not Found, which suggests the route is not actually reachable even though the logs say it is listening.

OpenClaw version

2026.3.12

Operating system

macOS 26.3.1

Install method

npm Global

Model

openai-codex/gpt-5.4 · 🔑 oauth (openai-codex:default)

Provider / routing chain

BlueBubbles Server (local, http://127.0.0.1:1234) → webhook POST → OpenClaw gateway (local, http://127.0.0.1:18789/bluebubbles-webhook?password=REDACTED)

Config file / key location

No response

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response