OpenClaw on iMessage

OpenClaw speaks iMessage through imsg, a command-line bridge that the Gateway spawns and talks to over JSON-RPC on standard input and output: no daemon, no port. It has to run on a Mac that is signed in to Messages, and if the Gateway lives elsewhere it reaches that Mac through an SSH wrapper. BlueBubbles support was removed; imsg is the only path now. Here is the setup, the permissions, the two modes, and the deployment patterns the docs recommend.

Setup on the Mac

• Install the official iMessage plugin on the Gateway host, then imsg through Homebrew from its tap; the setup wizard can offer that install, or an update, when it finds a missing or Homebrew-managed imsg.
• Point the channel at the imsg binary and at the Messages database under the user’s Library folder, start the Gateway, and approve the first DM pairing: requests expire after an hour.
• Grant Full Disk Access and Automation to the context that runs imsg; missed permission prompts are a listed troubleshooting entry, and so are messages that send while nothing arrives.

Basic mode and private API mode

Basic mode is what a fresh install gives: outbound text and media, inbound watch and history, the chat list, and no changes to the system. Private API mode injects a helper into Messages to reach its internal functions, which unlocks reactions, edits, unsend, threaded replies, effects, native polls, group management, typing indicators and read receipts. It requires System Integrity Protection off and library validation relaxed, and the injection refuses to run while SIP is on.

Disabling SIP is a real security tradeoff.

The docs are direct about that trade: SIP is one of macOS’s core protections, turning it off on Apple Silicon also removes the ability to run iOS apps on the Mac, and the recommendation is a dedicated Mac or a dedicated bot user for the bridge. If your threat model cannot tolerate SIP off anywhere, the channel is basic mode only. OpenClaw security best practices is the wider checklist.

Where the Gateway lives

• Same Mac: the usual deployment, Gateway and imsg together on the signed-in Messages host.
• Remote Mac over SSH or Tailscale: the Gateway on Linux or a VM, imsg on a Mac in the tailnet, a transparent SSH wrapper as the CLI path and a remote host setting for attachments. The wrapper must forward bytes as they arrive; one that buffers looks exactly like an iMessage outage.
• Dedicated bot macOS user: a separate Apple ID and user so bot traffic never touches your personal Messages profile; first run needs the Automation and Full Disk Access approvals in that user’s session.

Inbound recovery is automatic: after a bridge or Gateway restart, the channel replays what was missed and suppresses the backlog Apple can flush after a push recovery, without dispatching anything twice. OpenClaw not responding covers the general silent-channel ladder.

What it means in practice

iMessage is the one channel that cannot be moved off Apple hardware. A Gateway anywhere can serve it, but only with a Mac at your end running imsg, signed in, awake and reachable, and that Mac becomes part of the operating job: its updates, its permissions, its SIP decision.

On Diali

On Diali, iMessage is on the roadmap rather than in the connect list, because the Messages Mac has to be yours and the pairing between it and a hosted Gateway deserves a page of its own. Until then OpenClaw on Telegram is the channel most people start with; Hosted OpenClaw on Diali is the assistant.

• imsg on a signed-in Mac, Full Disk Access and Automation, pairing for DMs.
• Basic mode keeps SIP on; the private API needs it off, ideally on a dedicated Mac or user.
• The Gateway can live anywhere; the Mac cannot.