OpenClaw iMessage in June 2026: BlueBubbles Is Gone, imsg Is In, and the Safe Migration Path
OpenClaw’s iMessage path changed materially in 2026. The official docs now say BlueBubbles is removed from the supported channel path, and current iMessage support runs through the bundled imessage plugin that starts imsg locally or over SSH on a signed-in Mac. If your gateway still depends on channels.bluebubbles, the practical work now is not debating the old stack. It is migrating cleanly to channels.imessage, validating permissions, and testing the features you actually use before you tear the old bridge down.
1. What changed in the supported iMessage stack
The short version is simple: OpenClaw no longer ships a BlueBubbles channel. The supported path is now the bundled imessage plugin, which talks to imsg rpc over JSON-RPC on stdin/stdout. That means there is no longer a BlueBubbles HTTP server, webhook route, REST password, or separate BlueBubbles runtime in the current iMessage setup.
For operators, that changes the failure model and the migration checklist. The Messages host matters more, local macOS permissions matter more, and transport details like SSH wrappers now matter if your gateway is not running on the same Mac that is signed into Messages.
2. Pick the right host pattern before you migrate
The current docs are explicit that OpenClaw iMessage should run through imsg on a signed-in macOS Messages host. If your main gateway runs on Linux or Windows, OpenClaw still supports iMessage by pointing channels.imessage.cliPath at an SSH wrapper that runs imsg on the Mac.
That is a useful split for mixed-device teams. You can keep the gateway on a Windows or Linux operator box while leaving the Apple-specific bridge on the Mac that already owns Messages. If that is your environment, it is worth reading our guide on running OpenClaw on Windows safely, because the gateway and the iMessage bridge now have cleaner but stricter boundaries.
For attachment-heavy workflows, OpenClaw also expects remoteHost, attachment roots, and strict host-key checking to be correct. In other words, a remote Mac pattern works, but it is an ops pattern, not a shortcut.
3. Translate the config, not just the binary
The safe migration is not just installing imsg. It is translating every relevant behavior key from channels.bluebubbles to channels.imessage and dropping the fields that no longer exist.
{
channels: {
imessage: {
enabled: true,
cliPath: "/opt/homebrew/bin/imsg",
dmPolicy: "pairing",
allowFrom: ["+15555550123"],
groupPolicy: "allowlist",
groupAllowFrom: ["+15555550123"],
groups: {
"*": { requireMention: true }
},
includeAttachments: true
}
}
}The removed BlueBubbles fields are the important tell. channels.bluebubbles.serverUrl and channels.bluebubbles.password do not have iMessage equivalents anymore, because there is no BlueBubbles HTTP service in the supported path.
The fields you should review carefully are the behavioral ones: allowlists, group rules, attachment handling, action toggles, and ACP bindings. OpenClaw’s migration docs also note that pairing approvals carry over by handle, but old BlueBubbles session keys do not become iMessage session keys. If you rely on historical per-chat continuity, plan for that explicitly.
4. Permissions and advanced actions are now the real gating items
The current iMessage docs call out three requirements that are easy to underestimate: Messages must be signed in on the Mac, Full Disk Access must exist for the process context running OpenClaw and imsg, and Automation permission is required to send through Messages.app.
There is also an important capability split. Basic text and media send/receive work without the private API bridge, but advanced actions such as threaded replies, tapbacks, edit, unsend, effects, read receipts, typing indicators, and group management require imsg launch plus a successful private API probe. The docs further note that those advanced actions require System Integrity Protection to be disabled on the Messages host. That is not a casual setting, so production teams should decide whether they truly need advanced actions or whether plain send/receive is enough.
If you are introducing attachments, remember that channels.imessage.includeAttachments is still off by default. Set it deliberately and pair it with the right attachment roots, especially if the Mac bridge is remote.
5. The common migration mistakes are operational, not conceptual
The docs identify a few failure modes that will waste hours if you treat them like model or agent bugs.
First, if you keep groupPolicy: "allowlist" but forget to copy the old groups block, group messages can silently stop flowing. Second, an SSH wrapper in front of imsg must behave like a transparent stdio pipe. If it buffers stdin/stdout, OpenClaw can look like it has an iMessage outage even when imsg itself is healthy.
Third, outbound sends can still fail in remote setups if the wrong macOS process context owns the Automation permission. Fourth, deleting the old BlueBubbles server too early removes your rollback path before you have validated DMs, groups, attachments, and any private API actions you actually use.
The practical sequence is straightforward: install and verify imsg, translate config, run openclaw channels status --probe, approve a fresh DM pairing, and test live traffic before final cutover. The current iMessage docs also say inbound recovery is automatic after a bridge or gateway restart, which is a real quality-of-life improvement once the bridge is configured correctly.
6. Why this matters for managed OpenClaw deployments
This change makes the iMessage path more opinionated, but also more legible. The bridge is now centered on a signed-in Mac plus imsg, with clearer transport and permission boundaries. That is better for operators who want a documented path, but only if they treat the migration as infrastructure work instead of a superficial plugin swap.
If you are also tightening plugin policy, approvals, or remote host access, pair this migration with our OpenClaw plugin security checklist. iMessage cutovers fail less often when channel migration and gateway hardening happen together.
Need help designing the Mac bridge, validating SSH transport, or moving a BlueBubbles-era setup into a supportable OpenClaw runbook? Talk to ALL CLEAR DIGITAL about a migration sprint, security review, or managed operator setup.