Summary

OpenClaw may start two iMessage watchers for the same local Messages source when channels.imessage.accounts contains both:

• a named account, for example swang430-gmail-com
• default

This can cause one inbound iMessage to be processed twice, resulting in duplicate replies.

In my case, sending one ping resulted in two pong replies.

Environment

• OpenClaw version: 2026.4.9
• macOS: Darwin 24.6.0
• iMessage CLI: imsg 0.4.0

Config shape

{
  "bindings": [
    {
      "agentId": "main",
      "match": {
        "channel": "imessage",
        "accountId": "swang430-gmail-com"
      }
    }
  ],
  "channels": {
    "imessage": {
      "enabled": true,
      "accounts": {
        "swang430-gmail-com": {
          "enabled": true,
          "cliPath": "imsg",
          "dmPolicy": "pairing",
          "groupPolicy": "allowlist"
        },
        "default": {
          "dmPolicy": "pairing",
          "groupPolicy": "allowlist"
        }
      }
    }
  }
}

Actual behavior

After gateway start, there were two imsg rpc processes under one openclaw-gateway parent.

Example process list:

ps -o pid,ppid,command -ax | grep -i '[i]msg rpc\|[o]penclaw-gateway'

Observed output before workaround:

28321     1 openclaw-gateway
28454 28321 /usr/local/Cellar/imsg/0.4.0/libexec/imsg rpc
28470 28321 /usr/local/Cellar/imsg/0.4.0/libexec/imsg rpc

Message history also showed one inbound message followed by two outbound replies:

id: 562, text: "ping", is_from_me: false
id: 563, text: "pong", is_from_me: true
id: 564, text: "pong", is_from_me: true

Expected behavior

Only one iMessage watcher should be started for a single local iMessage source, and one inbound message should only be handled once.

Workaround

Setting the default iMessage account to disabled fixed it:

"default": {
  "enabled": false,
  "dmPolicy": "pairing",
  "groupPolicy": "allowlist"
}

After restarting the gateway, only one imsg rpc process remained:

29183     1 openclaw-gateway
29278 29183 /usr/local/Cellar/imsg/0.4.0/libexec/imsg rpc

And ping -> pong returned to normal, with only one reply.

Likely root cause

It looks like iMessage account enumeration or monitor startup is treating both:

• channels.imessage.accounts.default
• the explicitly named iMessage account

as active monitor targets, even though they point to the same local iMessage backend.

This creates duplicate watch.subscribe consumers for the same source.

Suggested fix

Possible fixes:

1. Do not start a monitor for default when it is only acting as fallback config and a concrete bound account is already used.
2. Respect enabled: false consistently during iMessage monitor enumeration.
3. Deduplicate iMessage monitor startup when multiple account configs resolve to the same effective local backend, for example cliPath, dbPath, and account identity.

Notes

This does not appear to be caused by missing self-message filtering alone. The key symptom was duplicate inbound handling caused by duplicate watchers.