BlueBubble binding

[ornate flame]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[half urchin]

I checked the current docs/source. The key bit: accountId is not the channel selector. If Simon passes accountId: "bluebubbles" while the run is Discord-bound, OpenClaw still resolves the delivery channel from the current Discord context, which explains deliveryContext.channel = discord, accountId = bluebubbles.

Use an explicit channel + target:

{
  "action": "send",
  "channel": "bluebubbles",
  "target": "[phone]",
  "message": "Seed queue drained."
}

If you have named BlueBubbles accounts, add the actual account id:

{
  "action": "send",
  "channel": "bluebubbles",
  "accountId": "default",
  "target": "[phone]",
  "message": "Seed queue drained."
}

target: "bluebubbles:+1555..." is accepted by the BlueBubbles target normalizer once the channel is already BlueBubbles, but it is not the thing I’d rely on to switch channels from a Discord-bound session. Be explicit: channel: "bluebubbles".

The other likely blocker is cross-context policy. OpenClaw blocks cross-provider sends by default. For a Discord-bound agent to send BlueBubbles/iMessage, set:

{

  tools: {
    message: {
      crossContext: {
        allowAcrossProviders: true,
        marker: { enabled: true, prefix: "[from {channel}] " }
      }
    }
  }
}

Then restart the gateway. Docs: https://docs.openclaw.ai/help/faq#how-do-i-send-a-discord-message-from-telegram-cross-context-messaging-denied

Answers to the numbered bits:

1. Correct shape is channel: "bluebubbles" plus target: "+E164" / chat_guid:... / chat_id:... / chat_identifier:.... accountId is only for selecting a configured account.
2. No binding is needed for ad-hoc outbound sends. Bindings are for persistent ACP/session routing. They can help account selection, but they are not required if you pass channel, target, and optionally accountId.

3. channels.bluebubbles.enabled: true auto-activates the bundled BlueBubbles channel plugin. plugins.entries.bluebubbles.config: {} does not need enabled: true in normal config. Exception: if you use plugins.allow, make sure bluebubbles is in the allowlist; plugins.enabled: false, plugins.deny, or plugins.entries.bluebubbles.enabled: false can still block it.
4. Use openclaw status --deep and openclaw doctor; doctor now reports plugin/channel status warnings when the gateway is healthy. A practical outbound smoke test is:

openclaw message send --channel bluebubbles --target "[phone]" --message "test from OpenClaw"

5. In Simon’s TOOLS.md, write it very literally:

### iMessage / BlueBubbles notifications
Use the message tool with an explicit channel. Do not put "bluebubbles" in accountId unless that is the configured account id.

Example:
{ "action": "send", "channel": "bluebubbles", "accountId": "default", "target": "[phone]", "message": "Done." }

This requires tools.message.crossContext.allowAcrossProviders=true when the active session is Discord-bound.