Bug Description

BlueBubbles inbound webhook stopped working after upgrading from 2026.2.26 to 2026.3.1. The gateway returns HTTP 405 Method Not Allowed on all POST requests to the webhook endpoint (/bluebubbles-webhook). Rolling back to 2026.2.26 immediately fixes the issue.

Environment

• OpenClaw version: 2026.3.1 (broken), 2026.2.26 (working)
• OS: macOS Tahoe 26.3.0 (arm64, Mac mini)
• Node: v25.6.0
• BlueBubbles Server: v1.9.9, Private API enabled
• Gateway mode: local loopback (127.0.0.1:18789)

Config (relevant)

{
  "channels": {
    "bluebubbles": {
      "enabled": true,
      "serverUrl": "http://localhost:1234",
      "password": "...",
      "webhookPath": "/bluebubbles-webhook"
    }
  }
}

Steps to Reproduce

1. Upgrade to 2026.3.1 (npm install -g openclaw@2026.3.1)
2. Restart gateway (openclaw gateway restart)
3. Gateway logs show: BlueBubbles webhook listening on /bluebubbles-webhook (looks normal)
4. Send an iMessage to the paired number
5. Message appears in BlueBubbles but is never relayed to OpenClaw
6. Confirm with curl:

   curl -s -o /dev/null -w "%{http_code}" -X POST "http://localhost:18789/bluebubbles-webhook" \
     -H "Content-Type: application/json" -d '{"type":"new-message","data":{}}'
   # Returns: 405

7. Same curl on 2026.2.26 returns 400 (invalid payload — POST is accepted, just test data is bad)

Observed Behavior

• GET /bluebubbles-webhook → 200 (returns dashboard HTML — wrong, should not serve the dashboard on the webhook path)
• POST /bluebubbles-webhook → 405 Method Not Allowed (broken)
• Adding ?password=<pw>, Authorization: Bearer <token>, x-password headers — still 405
• No errors or warnings in gateway logs — webhook POSTs are silently rejected
• All agent runs during the broken window show messageChannel=webchat only, zero messageChannel=bluebubbles

Expected Behavior

• POST /bluebubbles-webhook should accept the request and process the webhook payload (as it does on 2026.2.26)

Likely Cause

The 2026.3.1 changelog includes:

Gateway/Container probes: add built-in HTTP liveness/readiness endpoints (/health, /healthz, /ready, /readyz) for Docker/Kubernetes health checks, with fallback routing so existing handlers on those paths are not shadowed. (#31272)

The new HTTP route handling appears to shadow or override the BlueBubbles webhook POST handler. The GET on the same path returns the dashboard (200), suggesting a catch-all GET route is registered that takes precedence over the webhook POST handler.

Workaround

Roll back to 2026.2.26:

npm install -g openclaw@2026.2.26
openclaw gateway restart

Log Evidence

Gateway startup on 2026.3.1 (looks normal but POST broken):

[INFO] gateway/channels/bluebubbles [default] starting provider (webhook=/bluebubbles-webhook)
[INFO] gateway/channels/bluebubbles [default] BlueBubbles server macOS 26.3.0
[INFO] gateway/channels/bluebubbles [default] BlueBubbles Private API enabled
[INFO] gateway/channels/bluebubbles [default] BlueBubbles webhook listening on /bluebubbles-webhook
[INFO] gateway/health-monitor started (interval: 300s, grace: 60s)  ← NEW in 2026.3.1

After rollback to 2026.2.26, first real BB message comes through immediately:

[DEBUG] embedded run start: ... messageChannel=bluebubbles  ← working
[WARN]  [bluebubbles] webhook rejected: unable to parse message payload  ← curl test: POST accepted (400, not 405)