Summary

After running openclaw update (updated to 2026.4.5), the iMessage channel replayed a large batch of already-processed messages, causing an outgoing message loop.

Version

• OpenClaw: 2026.4.5 (3e72c03)
• imsg: 0.5.0
• macOS: 25.3.1 arm64

Steps to Reproduce

1. Have iMessage channel configured and active with prior message history
2. Run openclaw update (or any restart that causes the plugin to briefly fail to load)
3. On restart, the iMessage channel replays messages from the chat history as if they are new

What Happened

During the update, the iMessage plugin failed to load mid-restart due to a missing dependency (Cannot find module), causing two forced restarts. When the channel finally came back up, it had lost its in-memory rowid cursor. imsg watch then replayed ~30 minutes of previously-processed messages — each one triggered an agent run and sent a reply, creating a loop.

From the logs:

2026-04-07T10:53:28 | [plugins] imessage failed during register: Error: Cannot find module ...
2026-04-07T10:54:44 | [default] starting provider (/opt/homebrew/bin/imsg ...)
2026-04-07T11:30:31 | imessage: delivered reply to imessage:[email protected]
2026-04-07T12:27:07 | imessage: delivered reply to imessage:[email protected]
[... 10+ more replies in a loop ...]

Root Cause

The iMessage channel does not persist its --since-rowid cursor to disk. The imsg watch command supports --since-rowid and --start parameters, but on any restart the cursor resets and old messages are replayed.

Expected Behavior

The last processed rowid should be persisted to disk (e.g. in ~/.openclaw/) so that after any restart (update, crash, config reload), imsg watch is called with --since-rowid instead of replaying the full backlog.

Workaround

Setting channels.imessage.historyLimit: 0 reduces but does not eliminate the replay window. The only real fix is cursor persistence.

Additional Context

• imsg watch --help confirms both --since-rowid and --start are supported
• The imessage docs already recommend migrating to BlueBubbles for new setups — this is a clear example of why
• The update process itself also seems to cause the plugin to fail mid-load, which is a secondary issue worth investigating