How to Add iMessage to OpenClaw Without a Mac
A managed relay for iMessage, RCS, and SMS that works with any AI agent. No Apple hardware required.
If you run OpenClaw on anything other than a Mac, you've probably hit this wall: the iMessage integration requires BlueBubbles, BlueBubbles requires macOS, and macOS requires Apple hardware running 24/7. For a messaging feature.
Most people deploying OpenClaw in production run their agents on Linux VPSes, in Docker containers, on cloud VMs. The Mac is an infrastructure dependency for a single messaging channel, and it blocks adoption for anyone who doesn't have Apple hardware sitting around.
We built Claw Messenger to solve this. It's a relay that gives your OpenClaw agent a real phone number with iMessage, RCS, and SMS. No macOS anywhere in the chain. It also works with any other AI agent framework via WebSocket or REST API.
Why does OpenClaw iMessage require a Mac?
The built-in integration uses BlueBubbles, which reads the iMessage database stored locally on macOS. That database only exists on Apple hardware. So if you want your OpenClaw agent to send and receive iMessages, the official path is: buy or rent a Mac, leave it running 24/7, grant Full Disk Access, and maintain it.
We kept hearing the same question in the OpenClaw community: how do I add iMessage to my agent on Linux? The answer was always "you can't, unless you get a Mac." We wanted a different answer.
How to set up OpenClaw iMessage on Linux or Docker
Install the plugin:
openclaw plugins install @emotion-machine/claw-messenger
Add the channel block to ~/.openclaw/openclaw.json:
{
"channels": {
"claw-messenger": {
"apiKey": "cm_your_key_here",
"serverUrl": "wss://relay.clawmessenger.com"
}
}
}
Restart the gateway:
openclaw gateway restart
Register the phone numbers you want to allow in the dashboard. Only registered numbers can reach your agent. This is a security default. Open inbound from any number is a spam vector we decided to block from day one.
Text the agent's number from your iPhone. You should get a reply back over iMessage.
No Xcode. No Full Disk Access. No Mac.
How the relay routes iMessage without macOS
Your OpenClaw gateway opens a persistent WebSocket to wss://relay.clawmessenger.com. When someone texts your agent's number, the carrier delivers the message to the relay infrastructure. It gets forwarded to your gateway over the WebSocket. Your agent processes it. The reply goes back the same way.
Message content is not stored on the relay servers. The WebSocket is TLS-encrypted. Protocol selection (iMessage vs. RCS vs. SMS) happens automatically at the carrier level based on the recipient's device. You configure one channel; the relay handles routing.
For agents that handle sensitive operations, add HMAC webhook verification:
{
"channels": {
"claw-messenger": {
"apiKey": "cm_...",
"serverUrl": "wss://relay.clawmessenger.com",
"webhookSecret": "whsec_..."
}
}
}
Every inbound payload is signed. Your gateway verifies the signature before processing. This prevents spoofed messages from reaching your agent's logic.
What iMessage features work with AI agents?
We built this expecting people to use it for text Q&A. What actually happened was more interesting. People started using native iMessage features as agent inputs.
Tapbacks turned out to be useful for confirmations. One early user set up thumbs-up to approve calendar entries and thumbs-down to reject them. No typing, just a long-press reaction. The agent receives tapback events with the reaction type and the referenced message, so you can build binary confirmation flows with near-zero interaction cost.
Typing indicators changed the feel of conversations more than expected. When the agent sends a typing bubble before responding, the exchange reads like texting a person. Without it, replies materialize out of nothing and the experience feels mechanical.
The RCS and SMS fallback matters because your agent's contacts aren't all on iPhones. When a non-Apple device texts the agent, the system falls back to RCS where supported, then SMS. One number, three protocols, no configuration.
BlueBubbles comparison
BlueBubbles is open source and free. If you have a Mac to dedicate, it's a solid option. Here's how the two approaches compare:
| BlueBubbles | Managed relay | |
|---|---|---|
| Requires macOS | Yes, running 24/7 | No |
| Setup time | 30-60 minutes | ~5 minutes |
| Maintenance | You manage the Mac | Managed service |
| Linux / Docker / VPS | Not supported | Fully supported |
| RCS + SMS fallback | No | Automatic |
| HMAC webhook verification | No | Yes |
Both approaches work. The Mac-based route gives you more control and costs nothing beyond hardware. The managed route removes the Apple hardware dependency.
Using the WebSocket API with any AI agent
The OpenClaw plugin is one integration, but the underlying relay is a WebSocket and REST API that works with any agent framework. The general pattern in Python:
import asyncio
import websockets
import json
async def imessage_loop(api_key, handle_message):
uri = f"wss://relay.clawmessenger.com?key={api_key}"
async with websockets.connect(uri) as ws:
while True:
raw = await ws.recv()
message = json.loads(raw)
reply = await handle_message(message)
await ws.send(json.dumps({
"to": message["from"],
"text": reply
}))
Your handle_message function is where the agent lives. It can be a LangChain agent's invoke(), an n8n workflow, a LangGraph stateful graph, or plain if/else logic. The relay is just the transport layer. It doesn't care what generates the reply.
For serverless or webhook-based agents, there's also a REST API. Receive messages via HMAC-verified webhook POST, send replies with a simple HTTP call. No persistent WebSocket needed.
The message format is minimal JSON:
{
"from": "+15551234567",
"text": "Hey, what's the weather like tomorrow?",
"timestamp": "2026-04-02T14:30:00Z",
"type": "imessage"
}
We're Emotion Machine, a conversational AI company based in San Francisco. Claw Messenger is one of several tools we build for AI agent communication. Reach us at hello@emotionmachine.ai.
