openclaw - 💡(How to fix) Fix iMessage self-chat echo suppression fails: message-ID short-circuit prevents text-based fallback match [1 participants]

Bug: iMessage self-chat echo suppression fails due to message-ID short-circuit in SentMessageCache.has()

Summary

After updating to the latest OpenClaw release, outbound agent replies in iMessage self-chat (Notes to Self / single-person conversation) are echoed back and re-ingested as new inbound messages. This triggers duplicate agent turns and creates an echo loop.

Root Cause

The echo suppression logic in SentMessageCache.has() short-circuits on message ID mismatch before reaching the text-based fuzzy match fallback.

In monitor-provider-*.js, the has() method:

1. Looks up the inbound message's ID/GUID in messageIdCache
2. If not found and skipIdShortCircuit is false, returns false immediately
3. Never reaches the textCache fuzzy substring comparison

The problem: iMessage echoes arrive with a new GUID (assigned by the Messages framework), different from the GUID of the original outbound message. So the ID lookup always misses. And since skipIdShortCircuit is derived from !hasInboundGuid — and all iMessage messages have GUIDs — it's always false, triggering the early return.

// Simplified reproduction of the bug path:
has(scope, lookup, skipIdShortCircuit = false) {
    const messageIdKey = normalizeEchoMessageIdKey(lookup.messageId);
    if (messageIdKey) {
        const idTimestamp = this.messageIdCache.get(`${scope}:${messageIdKey}`);
        if (idTimestamp && ...) return true;
        // ⚠️ BUG: This returns false before trying text match
        if (!skipIdShortCircuit && !(textTimestamp conditions...)) return false;
    }
    // Text fuzzy match below is never reached for iMessage echoes
    if (textKey) { ... }
}

Environment

• OpenClaw version: Latest as of 2026-04-02
• Platform: macOS, Apple Silicon (Mac Studio)
• iMessage setup: Self-chat (agent sends to the same phone number it monitors)
• Regression: This worked in prior versions. Started failing after update, but not immediately (likely needed specific message patterns/state to trigger).

Symptoms

1. Echo text replies — Agent's own replies bounce back with garbled prefix characters (\u001b\u0001, \ufffc, etc.) from NSAttributedString serialization
2. Empty messages — Messages with only attributed body data (no plain text) pass through as empty inbound messages
3. Cascading echo loops — Each echo triggers a new agent turn, which sends a new reply, which echoes again

Workaround

Removing the early return false in SentMessageCache.has() when the message ID doesn't match, allowing fallthrough to the text-based fuzzy comparison. Specifically, replacing:

if (messageIdKey) {
    const idTimestamp = this.messageIdCache.get(`${scope}:${messageIdKey}`);
    if (idTimestamp && Date.now() - idTimestamp <= SENT_MESSAGE_ID_TTL_MS) return true;
    const textTimestamp = textKey ? this.textCache.get(`${scope}:${textKey}`) : void 0;
    const textBackedByIdTimestamp = textKey ? this.textBackedByIdCache.get(`${scope}:${textKey}`) : void 0;
    if (!skipIdShortCircuit && !(typeof textTimestamp === "number" && (!textBackedByIdTimestamp || textTimestamp > textBackedByIdTimestamp))) return false;
}

With:

if (messageIdKey) {
    const idTimestamp = this.messageIdCache.get(`${scope}:${messageIdKey}`);
    if (idTimestamp && Date.now() - idTimestamp <= SENT_MESSAGE_ID_TTL_MS) return true;
}

This allows the method to always fall through to the text-based matching, which correctly identifies echoes via fuzzy substring comparison.

Additional Context

• The buildIMessageEchoScope (inbound) and deliverReplies scope (outbound) formats do match (${accountId}:imessage:${sender} vs ${accountId}:${target} where target includes imessage: prefix), so the scope is not the issue.
• The fuzzy text match (textKey.includes(cachedText) || cachedText.includes(textKey)) works correctly once reached — chunked outbound messages are properly matched against concatenated echo text.
• Echo text normalization (stripping control characters, \ufffc, etc.) also works correctly.
• The skipIdShortCircuit flag is derived from !hasInboundGuid, but all iMessage messages have GUIDs, making this flag effectively always false for iMessage.

Suggested Fix

Either:

1. Remove the ID-based short-circuit entirely (our workaround)
2. Set skipIdShortCircuit = true for self-chat echo detection specifically
3. Always fall through to text matching when in self-chat context (isSelfChat && is_from_me)