How to Add iMessage to Your OpenClaw Agent on Any VPS

The problem

OpenClaw supports WhatsApp, Telegram, Discord, Slack, and Signal out of the box. Most of these work on any Linux VPS. iMessage is the exception.

iMessage runs exclusively on Apple hardware. The Messages app reads from a local SQLite database (chat.db) that macOS protects behind Full Disk Access permissions. If your agent runs on a $5 DigitalOcean droplet or a Hetzner VPS, you simply cannot access this database. There is no official Apple API for iMessage, no third-party SDK, and no workaround that runs on Linux alone.

Security researchers have identified over 135,000 internet-exposed OpenClaw instances, the vast majority running on Linux VPS. None of them can use iMessage natively.

Community guides acknowledge this directly. A popular setup walkthrough on Substack recommends: "Start with WhatsApp, expand later. Get that working first before adding complexity." iMessage is treated as the advanced, difficult channel.

Approach 1: Dedicated Mac Mini

The most common solution. Buy a Mac Mini, run OpenClaw on it, and use the built-in imsg CLI or BlueBubbles to bridge Messages.

What you need

• Mac Mini M4 ($599+)
• HDMI dummy plug (~$10) so macOS initializes graphics properly for headless operation
• Stable internet connection and a place to keep the machine running 24/7
• An Apple ID signed into Messages

Setup steps

1. Install OpenClaw: npm install -g openclaw@latest
2. Run onboarding: openclaw onboard --install-daemon
3. Grant Full Disk Access to the imsg binary (not Terminal.app - see the gotchas below)
4. Grant Automation permissions for Messages.app
5. Configure the iMessage channel in your config

Known problems

Full Disk Access is confusing. Adding Terminal.app to FDA is not enough. macOS does not pass permissions down to sub-processes. You need to find the actual binary OpenClaw uses for iMessage (usually ~/.openclaw/bin/imsg or /opt/homebrew/bin/imsg) and add that specific path to Full Disk Access. If you installed via npm, the binary is often a wrapper script that macOS FDA rejects entirely.

Messages.app goes idle. On headless setups (no monitor, accessed via SSH), Messages.app can stop processing incoming events. The official docs recommend installing a LaunchAgent that pokes Messages every 5 minutes using AppleScript:

# ~/Library/LaunchAgents/com.openclaw.messages-keepalive.plist
# Runs every 300 seconds:
osascript -e 'tell application "Messages" to activate'

The echo loop. When OpenClaw sends a message via AppleScript, the chat.db filesystem watch event can fire before the is_from_me flag is set in the database. The bot sees its own outgoing message as a new incoming message. In one documented case, this created an infinite loop that ran for 53 minutes, generating significant API costs while the user was asleep.

Permission prompts in headless mode. macOS permission dialogs can appear but go unseen when running via SSH or as a LaunchAgent. Sending and receiving silently fails until someone physically approves the prompt on the machine.

Cost

Approach 2: Tailscale bridge (VPS + Mac)

Run the OpenClaw gateway on a cheap Linux VPS for 24/7 uptime, but connect it to a Mac at home over Tailscale for iMessage access. Alibaba Cloud published a full tutorial for this pattern.

How it works

1. Install Tailscale on both the Linux VPS and the Mac
2. Enable Remote Login (SSH) on the Mac
3. Grant Full Disk Access to sshd-keygen-wrapper
4. Create an SSH wrapper script on the VPS that forwards imsg commands to the Mac
5. Configure OpenClaw to use the SSH wrapper as the CLI path, with the remote Mac's chat.db path

# /root/.openclaw/scripts/imsg-ssh
#!/usr/bin/env bash
exec ssh -T user@mac-hostname /usr/local/bin/imsg "$@"

Problems with this approach

• Two machines to maintain. Your VPS and your Mac both need to stay online. If the Mac sleeps, reboots, or loses internet, iMessage stops working.
• Tailscale DNS interference. Tailscale can overwrite DNS settings on Linux. The Alibaba Cloud guide specifically warns about this and recommends manually setting nameservers to 1.1.1.1 or 8.8.8.8.
• SSH key management. You need passwordless SSH between the VPS and Mac, which adds another configuration layer.
• All the Mac-side problems from Approach 1 still apply (FDA, idle Messages.app, permission prompts).

Cost

Approach 3: macOS VM

Run macOS in a virtual machine on Apple Silicon hardware using tools like Lume. The OpenClaw docs have a guide for this.

Requirements

• Apple Silicon Mac (M1/M2/M3/M4)
• ~60 GB free disk space per VM
• ~20 minutes for initial setup

The catch

You still need Apple hardware. This approach gives you isolation (the VM is sandboxed) and easy snapshots, but it does not solve the fundamental problem of needing a Mac. You cannot run macOS VMs on standard cloud providers like AWS, DigitalOcean, or Hetzner.

Some cloud Mac services exist (MacStadium, MacinCloud), but they run $30-50+/mo and were not designed for iMessage relay use cases. Apple's Terms of Service also explicitly prohibit automated messaging, and accounts flagged for bot-like behavior get banned.

Approach 4: BlueBubbles

BlueBubbles is an open-source server that runs on a Mac and exposes Messages.app via a REST + WebSocket API. OpenClaw recommends BlueBubbles over the legacy imsg CLI for richer features. (For a detailed comparison, see BlueBubbles vs Claw Messenger.)

What BlueBubbles adds

• REST API for sending messages and media
• WebSocket for real-time incoming messages (no polling)
• Better attachment handling than the native imsg CLI
• Web-based admin panel for monitoring

What it doesn't solve

• Still requires a Mac running 24/7 with an HDMI dummy plug
• Messages.app still goes idle on headless setups (same AppleScript workaround needed)
• Attachments can be silently dropped due to webhook race conditions (GitHub #4848)
• Typing indicator bugs after reaction events (GitHub #11189)

Approach 5: Cloud messaging API

Instead of running your own Apple hardware, use a service that handles the iMessage infrastructure for you and exposes a simple API.

This is the approach Claw Messenger takes. Your agent connects via WebSocket, sends and receives messages through our infrastructure, and you never touch a Mac, BlueBubbles, or chat.db.

Setup

openclaw plugins install @emotion-machine/claw-messenger

// ~/.openclaw/openclaw.json
{
  "channels": {
    "claw-messenger": {
      "enabled": true,
      "apiKey": "cm_live_...",
      "serverUrl": "wss://claw-messenger.onrender.com"
    }
  }
}

That's it. No Mac, no BlueBubbles, no HDMI dummy plug, no AppleScript keep-alive, no Full Disk Access debugging.

What it supports

• iMessage, RCS, and SMS through one API
• Dedicated phone number for your agent
• Tapbacks, typing indicators, read receipts
• Group message support
• Works on any VPS, any OS

Cost

First year on the Base plan: $60. Compare that to $670+ for a Mac Mini setup.

Side-by-side comparison

Which approach is right for you?

If you already have a Mac running 24/7 and are comfortable with macOS system administration, BlueBubbles gives you the most control. Expect to spend an afternoon on setup and occasional maintenance when macOS updates break permissions.

If you run OpenClaw on a VPS and don't want to buy or maintain Apple hardware, a cloud messaging API removes the entire problem. You trade some control for zero maintenance.

If you want to experiment first, the Tailscale bridge lets you use a Mac you already own without moving your OpenClaw installation off your VPS. But plan for complexity.