Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

After upgrading OpenClaw to 2026.4.2, openclaw health reports BlueBubbles as failed when channels.bluebubbles.serverUrl points to a private/LAN address (in my case http://172.31.100.1:1234).

The error is:

BlueBubbles: failed (unknown) - Blocked hostname or private/internal/special-use IP address

However, actual BlueBubbles messaging still works: inbound/outbound chat traffic continues normally through the same setup.

This looks like a regression or mismatch between the BlueBubbles health/probe path and the documented/recommended BlueBubbles LAN setup.

Steps to reproduce

1. Configure BlueBubbles with a private/LAN server URL, for example:
   ``json
   {
   "channels": {
   "bluebubbles": {
   "enabled": true,
   "serverUrl": "http://172.31.100.1:1234",
   "password": "",
   "webhookPath": "/bluebubbles-webhook"
   }
   }
   }
   `
2. Upgrade OpenClaw to 2026.4.2
3. Run:
   bash openclaw health
4. Observe that BlueBubbles health fails with:
   text BlueBubbles: failed (unknown) - Blocked hostname or private/internal/special-use IP address

Expected behavior

One of the following:

• BlueBubbles health checks should allow the configured private/LAN serverUrl, since the official BlueBubbles docs show LAN examples such as http://192.168.1.100:1234; or
• BlueBubbles should expose a documented allowPrivateNetwork-style configuration similar to Matrix if this is now intentionally restricted.

At minimum, openclaw health should not report the channel as failed if the actual BlueBubbles messaging path still works.

Actual behavior

openclaw health reports:
text BlueBubbles: failed (unknown) - Blocked hostname or private/internal/special-use IP address

But actual BlueBubbles chat delivery still works in the same deployment.

OpenClaw version

2026.4.2 (d74a122)

Operating system

macOS 15.4.1 (24E263)

Install method

npm global install / update flow (openclaw update)

Model

Not relevant to reproduction

Provider / routing chain

BlueBubbles channel on local/LAN network

Additional provider/model setup details

Current BlueBubbles config uses:

• serverUrl: http://172.31.100.1:1234
• webhook-based inbound delivery
• BlueBubbles plugin enabled

Relevant behavior:

• openclaw health fails for BlueBubbles
• actual BlueBubbles chatting still works in practice

Logs, screenshots, and evidence

Relevant openclaw health output:
`text
BlueBubbles: failed (unknown) - Blocked hostname or private/internal/special-use IP address
Agents: main (default)
Heartbeat interval: 30m (main)
Session store (main): /Users/aiassistant/.openclaw/agents/main/sessions/sessions.json (2 entries)
- agent:main:bluebubbles:direct:truthshalf@gmail.com (12m ago)
- agent:main:main (...)
`

Relevant log line:
`text
blocked URL fetch (bluebubbles-api) target=http://172.31.100.1:1234/api/v1/ping reason=Blocked hostname or private/internal/special-use IP address
`

Official docs appear to recommend LAN/private BlueBubbles server URLs, e.g.:
`json
serverUrl: "http://192.168.1.100:1234"

Impact and severity

• BlueBubbles health/status is misleading after upgrade
• Makes openclaw health` look broken even when BlueBubbles messaging is still functional
• Suggests either a regression in the probe path or missing documented/private-network exception handling for BlueBubbles

Additional information

I can still actively chat with my assistant over BlueBubbles after the upgrade, so this does not appear to be a complete channel failure. It seems limited to the health/probe path (GET /api/v1/ping) being blocked for private/internal IPs.