Summary

iMessage DM replies echo back to the agent as new inbound messages. The echo cache fails to match because:

1. Text TTL too short: SENT_MESSAGE_TEXT_TTL_MS = 4000 (4s) but echoes arrive 5-10s later
2. Corrupted prefix: Echoed text has leading U+FFFD replacement characters that break exact text matching in normalizeEchoTextKey()

Reproduction

1. Agent sends a long reply (500+ chars) via iMessage DM
2. Message arrives at recipient
3. Within 5-30 seconds, the same message appears as a new inbound message with is_from_me=0
4. Text starts with garbled chars (\ufffd, shown as �) followed by a truncated copy of the original
5. Echo cache lookup fails → message processed as new user input → agent replies → loop

Affected versions

• v2026.3.31 (confirmed)
• v2026.4.2 (confirmed, same code path)

Root cause

normalizeEchoTextKey() in monitor-provider-*.js only strips whitespace/CR. It does not strip leading U+FFFD/U+FFFE/control chars that iMessage adds to reflected copies. Additionally, the 4s text TTL expires before most echoes arrive.

Suggested fix

1. Increase SENT_MESSAGE_TEXT_TTL_MS to 30s (matching the WhatsApp echo fix pattern)
2. Strip leading replacement/control characters in normalizeEchoTextKey():

const normalized = text.replace(/\r\n?/g, '\n').replace(/^[\ufffd\ufffe\uffff\u0000-\u001f]+/, '').trim();

Workaround

Patch ~/.npm-global/lib/node_modules/openclaw/dist/monitor-provider-*.js directly. Gets overwritten on npm update.

Related

• iMessage channel duplicate message loop - messages sent by agent are re-ingested as inbound #41330 (original echo regression)
• fix(imessage): prevent echo loop from leaking internal metadata and amplifying NO_REPLY into queue overflow #33295 (echo loop hardening)
• fix(whatsapp): drop fromMe echoes in self-chat DMs using outbound ID tracking #54570 (WhatsApp echo fix)
• fix(whatsapp): filter fromMe messages in groups to prevent infinite loop #53624 (WhatsApp group echo)

/cc @vincentkoc @joelnishanth