Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

After upgrading from a 3.* release to OpenClaw 2026.4.2 on macOS Sequoia 15.1, my iMessage channel started looping assistant replies back into the same DM as new inbound messages.

This did not happen on my previous 3.* install with essentially the same config (Telegram + iMessage, DM bound to main). Telegram and webchat remain healthy; only iMessage shows this loop behavior.

Steps to reproduce

Install OpenClaw 2026.4.2 on macOS using: Copy curl -fsSL https://openclaw.ai/install.sh | bash -s -- --no-onboard Copy an existing .openclaw directory from an older 3.* setup over the new install to reuse config and workspace. Enable both Telegram and iMessage channels with dmPolicy: "pairing" and session.dmScope: "main": Copy "session": { "dmScope": "main" }, "channels": { "telegram": { "enabled": true, "dmPolicy": "pairing", "allowFrom": ["<telegram_user_id>"] }, "imessage": { "enabled": true, "cliPath": "/opt/homebrew/bin/imsg", "dbPath": "/Users/<user>/Library/Messages/chat.db", "dmPolicy": "pairing", "allowFrom": ["+<my_phone_number>"] } } From my iPhone, send any message via iMessage to the OpenClaw iMessage contact (paired number). Observe the assistant’s first reply (expected), then additional messages that: start with a few garbled bytes (e.g. ��
, �a
, ��), and contain the full text of the previous assistant reply. These echoed messages are treated as new inbound messages, causing the assistant to respond again → loop continues.

Expected behavior

iMessage DM should behave like Telegram DM: Each user message produces at most one assistant reply. Assistant replies are not re-injected as new inbound messages. No garbled prefix bytes or repeated full-response payloads appear in the iMessage thread.

Actual behavior

On 2026.4.2, with the config above: After I send a message from iMessage, the assistant replies once as expected. Then additional messages appear in the same DM that: begin with a few garbled characters; and contain the full text of the assistant’s last reply. These “echo” messages are treated as new user messages, so the assistant responds to its own previous replies, effectively creating an endless self-dialogue in my iMessage thread. Telegram and webchat channels do not show this behavior with the same dmScope and agent setup.

OpenClaw version

OpenClaw: 2026.4.2

Operating system

OS: macOS Sequoia 15.1 (arm64)

Install method

curl -fsSL https://openclaw.ai/install.sh | bash -s -- --no-onboard

Model

openaiopenai-codex/gpt-5.1

Provider / routing chain

openclaw

Additional provider/model setup details

• OS: macOS Sequoia 15.1 (arm64)
• OpenClaw: 2026.4.2
• Install method:
  • Previously on a 3.* version (iMessage worked fine there)
  • Uninstalled old version
  • Installed 2026.4.2 via:

    curl -fsSL https://openclaw.ai/install.sh | bash -s -- --no-onboard

  • Copied old ~/.openclaw directory over the new one to reuse config/workspace
• Channels:
  • Telegram: enabled, works normally
  • iMessage: enabled, shows loop
• Session config:

  "session": {
    "dmScope": "main"
  }

• iMessage channel config:

  "channels": {
    "imessage": {
      "enabled": true,
      "cliPath": "/opt/homebrew/bin/imsg",
      "dbPath": "/Users/<user/Library/Messages/chat.db",
      "dmPolicy": "pairing",
      "allowFrom": ["+<my_phone_number"],
      "groupAllowFrom": ["open"],
      "groupPolicy": "allowlist"
    }
  }

• Plugins:

  "plugins": {
    "entries": {
      "imessage": { "enabled": true },
      "telegram": { "enabled": true }
    }
  }

• No webchat / control-ui / custom mirror/forward configuration present in openclaw.json.

. What I tried

• Verified openclaw status shows:
  • Telegram: ON, OK
  • iMessage: ON, OK, configured
• Checked openclaw.json for any webchat, control, ui, mirror, or forward fields:
  • None present; config is essentially wizard defaults + my channels.
• Changed session.dmScope from "main" to "per-peer" and restarted gateway:
  • Behavior changed slightly but did not eliminate the iMessage loop.
  • Reverted dmScope back to "main".
• Confirmed Telegram and webchat work cleanly with no echo/loop.
• Fixed a separate sandbox/Docker error by starting Docker Desktop:
  • Sandbox now works, but iMessage loop persists, so it’s not caused by Docker being down.

Questions / Help wanted

• Is this a known regression in the iMessage channel in 2026.4.2, especially when multiple channels share the same dmScope / main session?
• Is there a recommended workaround (other than disabling the iMessage channel entirely) while keeping multi-channel DMs bound to main?
• If you’d like, I can capture openclaw logs --follow focused on iMessage events and share a redacted snippet.

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response