Environment

• OpenClaw: 2026.5.22 (a374c3a)
• imsg: 0.9.0
• macOS: Tahoe (26), M4 MacBook Air
• iMessage plugin config: debounceMs: 3000

Problem

User messages sent to a group chat immediately after an agent reply are silently dropped. The message never appears in the agent session transcript, and no new run is triggered.

Steps to Reproduce

1. Agent (heart-tone/Bloom) is bound to iMessage group chat (chat_id:43)
2. User sends a message → agent processes it and replies at 2:46 PM (session status: "done")
3. User sends a follow-up message at 2:48 PM (2 minutes later)
4. Expected: Gateway routes message to the agent, triggering a new run on the existing session
5. Actual: Message is silently dropped. Does not appear in session transcript. No new run triggered. No error in gateway logs.

Evidence

• Session agent:heart-tone:imessage:group:43 shows status "done" with lastMessagePreview: "Fixed — says $9.99 now. Good catch Jonathan!"
• The follow-up message ("Can you mockup a new arrivals section on the homepage...") sent 2 minutes later is not in the transcript
• The session was ready to accept new messages (persistent agent, 136K tokens in transcript)
• No relevant entries in gateway.log around the timestamp
• This appears to happen specifically when the user message arrives shortly after an agent outbound — suggesting echo/own-message filtering is too aggressive

Theory

The iMessage plugin may be misclassifying the inbound user message as an echo of the agent's own outbound message. Since all agents share a single iMessage account (Messages.app), the echo detection heuristic may have a time window that catches legitimate user messages sent within a few minutes of an agent reply on the same chat.

Alternatively, the debounceMs (3000ms) or some other deduplication logic may be interfering.

Impact

• Messages from the business owner to agents are silently lost
• No error, no warning, no retry — the user has no idea the agent never received their message
• This has been observed multiple times across different agents
• Workaround: user must resend the message after a longer delay

Desired Behavior

• Inbound messages should never be silently dropped
• If a message is filtered as an echo, it should be logged as a warning
• Echo detection should use message content matching, not just timing/chat heuristics