openclaw - 💡(How to fix) Fix BlueBubbles: catchup polling uses iMessage;-; GUID prefix but macOS Tahoe creates any;-; chats

Bug Report

OpenClaw version: 2026.4.24 (cbcfdf6) macOS version: 26.4.1 (Tahoe) BlueBubbles version: 1.9.9, Private API enabled

Symptom

Continuous 404 errors in BlueBubbles server logs, firing every ~15 seconds per configured phone number:

[2026-05-17 21:32:01][debug] Request to /api/v1/chat/iMessage%3B-%3B%2B13179650799/message
[2026-05-17 21:32:01][debug] API Error: [404] The requested resource was not found -> Chat does not exist!

Root Cause

OpenClaw's BB catchup polling constructs chat GUIDs as iMessage;-;+<number> from the allowFrom phone numbers. However, on macOS Tahoe (26.x), Messages.app creates DM chats with an any;-; GUID prefix rather than iMessage;-;. BlueBubbles correctly reflects what's in chat.db, so the lookup fails every time.

-- What actually exists in chat.db on macOS Tahoe:
-- guid                      | service_name
-- any;-;+13179650799        | iMessage   ✅ exists
-- iMessage;-;+13179650799   |            ❌ does not exist

-- What OpenClaw requests from BB:
GET /api/v1/chat/iMessage%3B-%3B%2B13179650799/message  → 404

The service_name column in chat.db correctly shows iMessage — these are iMessage conversations — but the GUID prefix is any;-; because macOS Tahoe creates chats that allow SMS fallback by default.

Suggested Fix

Rather than constructing the GUID from the phone number, query BB for the actual chat GUID by participant address first:

POST /api/v1/chat/query  { participants: ['+13179650799'] }
→ returns { guid: 'any;-;+13179650799', ... }

Then use the returned GUID for subsequent message polling. This would work correctly regardless of whether the prefix is iMessage;-;, any;-;, or anything else.

Workaround

None currently — the chats cannot be recreated with iMessage;-; GUIDs because Messages.app reuses the existing any;-; chat when a new message is sent to the same number.