I enabled the iMessage channel on my OpenClaw setup. Within seconds — literally seconds — my agent auto-replied to my wife with a device pairing code.

Not a greeting. Not something helpful. A raw pairing code, sent to the most recent conversation in my iMessage history, which happened to be my wife.

This is the story of how that happened, why the defaults are dangerous, and the exact config changes that prevent it.

The Setup

I run OpenClaw on a Mac Studio with about 45 cron jobs, Telegram as my primary channel, and a bunch of integrations. I'd been using the imsg CLI (a third-party iMessage bridge) for sending messages from the command line, and I wanted to try enabling iMessage as a full OpenClaw channel — meaning my agent could receive and respond to iMessages directly.

The docs said to add an iMessage channel config. I did:

{
  "channels": {
    "imessage": {
      "enabled": true,
      "plugin": "imessage"
    }
  }
}

Gateway restarted. Channel connected. And then my agent — trained to be helpful, responsive, and proactive — did what it was designed to do.

It replied to the first incoming message it saw.

What Went Wrong

Here's the chain of events:

  1. iMessage channel enabled — the bridge starts watching the Messages database
  2. My wife had texted me earlier — normal conversation, nothing unusual
  3. The agent saw her message as an "incoming message on the iMessage channel"
  4. It tried to establish a session and sent a pairing/auth code back
  5. My wife received a random code from "me" (since iMessage sends as my Apple ID)
The core problem: When you enable iMessage as a channel, there's no whitelist. Every incoming iMessage becomes a potential agent conversation. The agent doesn't know the difference between "someone trying to talk to the AI" and "your wife asking what's for dinner."

This is fundamentally different from Telegram, where you control exactly which chat IDs the bot responds to. iMessage has no bot concept — it's just your phone number.

The Fix

I disabled both the channel and the plugin immediately:

// Gateway config patch
{
  "channels": {
    "imessage": {
      "enabled": false
    }
  },
  "plugins": {
    "entries": {
      "imessage": {
        "enabled": false
      }
    }
  }
}

Two things had to be disabled, not one. The channel config AND the plugin entry. If you only disable the channel, the plugin can still process messages.

How To Do It Safely (If You Still Want iMessage)

If you want iMessage as a channel, you need guardrails that don't exist by default:

  1. Contact whitelist: Only respond to specific phone numbers or Apple IDs. Everyone else gets ignored.
  2. Keyword trigger: Require a specific phrase to activate the agent (like "Hey OpenClaw") rather than responding to every message.
  3. Separate Apple ID: The nuclear option — create a dedicated Apple ID just for the agent. Nobody texts it except you.

For most setups, option 3 is the only truly safe one. Options 1 and 2 depend on bridge support that may or may not exist in your iMessage plugin.

My recommendation: don't enable iMessage as a channel unless you've solved the isolation problem first. Use the imsg CLI for outbound messages (sending) and keep Telegram/Discord/Signal as your inbound channel where the agent actually listens.

The Lesson

Channel activation is not reversible in the way you think. The moment a channel goes live, your agent is listening. And if your agent is trained to be helpful and responsive (which... it should be), it will respond to whatever it hears first.

With Telegram, that's fine — bots have their own identity. With iMessage, you are the bot. Every response goes out as you. To your contacts. From your phone number.

Rule I now follow: Before enabling any new channel, ask: "If my agent responds to the first message it sees on this channel, what's the worst that happens?" If the answer involves a real human receiving an unexpected message from "me" — don't enable it without a whitelist.

The pairing code was embarrassing but harmless. It could have been worse. Imagine the agent trying to be helpful in response to a text from your boss, your mom, or your doctor.

What's Next

The iMessage channel stays disabled until OpenClaw (or a community plugin) adds proper contact whitelisting. In the meantime, I use the imsg CLI as a tool — the agent can send iMessages when I ask it to, but it doesn't listen on iMessage.

Tomorrow: 6 Learning Crons, $1.66/Day, Zero Lessons — what happens when your "self-improvement" crons just write newsletters to themselves.