Summary

In a multi-account BlueBubbles setup (bot + personal), the gateway repeatedly logs health-monitor restarts with reason: stale-socket (roughly every 30 minutes for each account). During these windows, inbound iMessages (especially longer-running interactions / media sends) appear to be intermittently missed.

Environment

• OpenClaw: 2026.3.2 (stable)
• macOS: 26.3 (arm64)
• BlueBubbles Server: macOS 26.3.0
• Channel mode: channels.bluebubbles.accounts (defaultAccount=bot)
• bot account: Private API disabled (intentional)
• personal account: Private API enabled (read-only/restricted)

Observed behavior

• Repeating log pattern:
  • [health-monitor] [bluebubbles:bot] health-monitor: restarting (reason: stale-socket)
  • [health-monitor] [bluebubbles:personal] health-monitor: restarting (reason: stale-socket)
• Pattern recurs frequently over many hours.
• Inbound reliability degrades around these periods (user-visible symptom: can receive assistant sends, but assistant intermittently misses inbound iMessages/media).

Related config nuance

There is a migration/warning path around channels.bluebubbles.accounts.default.* and top-level channels.bluebubbles.* allowlist fields. If default allowlist fields are empty while policy is allowlist, warnings indicate possible silent drops. This can be confusing in multi-account setups where operators primarily configure accounts.bot and accounts.personal.

What would help

1. Better stale-socket diagnostics (why socket is considered stale; last activity/heartbeat timing).
2. Tunable stale-socket thresholds per provider/account.
3. Explicit guidance in docs for multi-account + top-level/default allowlist interactions.
4. Optional self-test/health probe that verifies inbound webhook -> session routing path end-to-end.

References

• Similar policy/routing reports:
  • BlueBubbles: Incoming messages rejected with 'unauthorized guid' regardless of dmPolicy #17262
  • [Bug]: BlueBubbles group chat messages stop routing after gateway restart #20467