Bug type

Regression (worked before, now fails)

Summary

PR #38440 added a self-chat echo dedupe to the iMessage channel to prevent echo loops (related to #32166, #1649). The dedupe drops is_from_me:false events when a matching is_from_me:true event was recently seen with the same chat, text, and created_at. This correctly dedupes agent-generated reply echoes, but it also drops genuine user-initiated inbound messages because macOS creates the same two-entry pattern for user-sent messages in self-chat. The result is that zero messages reach the agent — total loss of iMessage functionality for self-chat users.

Steps to reproduce

1. Configure iMessage with the owner's own phone number in allowFrom (self-chat pattern):

"imessage": {
  "enabled": true,
  "dmPolicy": "allowlist",
  "allowFrom": ["+1XXXXXXXXXX"],
  "groupPolicy": "disabled"
}

2. Start the gateway on v2026.3.12 or later
3. Send any iMessage to yourself (the number in allowFrom)
4. Wait for agent response

Expected behavior

The agent receives the inbound message and responds, as it did on versions prior to v2026.3.12.

Actual behavior

• The message is silently dropped by the dedupe logic
• No session is created or updated
• No error or warning appears in the gateway logs
• openclaw channels status --probe reports iMessage as healthy
• The agent never sees the message and never responds
• This happens for every message sent in self-chat — not intermittently

OpenClaw version

v2026.3.13 (regression introduced in v2026.3.12 by PR #38440)

Operating system

macOS Tahoe (arm64)

Install method

npm global

Model

N/A (channel-level bug, not model-specific)

Provider / routing chain

N/A (iMessage channel via imsg rpc)

Config file / key location

imessage channel config in openclaw.json

Additional provider/model setup details

Self-chat iMessage configuration with own phone number in allowFrom.
Gateway: OpenClaw v2026.3.13
OS: macOS Tahoe (arm64)
Node: v22.22.1
imsg: v0.5.0

Logs, screenshots, and evidence

No errors or warnings appear in the gateway logs. The channel reports as healthy via `openclaw channels status --probe`. The failure is entirely silent — no log entries, no diagnostics indicate anything is wrong.

The only evidence of the bug is the absence of any agent response. No session is created, no webhook fires, no error is thrown.

Impact and severity

Severity: High — silent data loss affecting 100% of inbound messages.

• Total loss of iMessage functionality for users running the self-chat pattern (own number in allowFrom)
• Silent failure — no errors, no logs, no diagnostics indicate anything is wrong
• Users lose their primary communication channel with the agent without any indication of why
• The self-chat pattern is documented in multiple issues (iMessage self-chat creates echo loop despite v2026.1.22 fixes #1649, [Bug]: iMessage self-chat causes bot to re-ingest its own messages, leading to session loops #2585) and is a known, supported use case

Additional information

Root Cause

The dedupe cannot distinguish between:

1. Agent-generated reply echoes (is_from_me:true created by imsg send → is_from_me:false received copy) — these should be dropped
2. User-initiated messages (is_from_me:true sent by user in Messages.app → is_from_me:false received copy) — these should be delivered

Both create identical chat.db entry pairs (same text, same created_at). The dedupe treats all such pairs as echoes.

Agent sends "Hello":
  ROWID 1001: is_from_me=1, text="Hello", created_at=T1
  ROWID 1002: is_from_me=0, text="Hello", created_at=T1  ← should be dropped (echo)

User sends "Hey":
  ROWID 1003: is_from_me=1, text="Hey", created_at=T2
  ROWID 1004: is_from_me=0, text="Hey", created_at=T2  ← should be DELIVERED (real message)

Why this only affects self-chat

In normal (non-self-chat) configurations, the user's phone number differs from the agent's. The is_from_me flag reliably indicates the agent's outbound messages, and user inbound messages never have a matching is_from_me:true entry.

Recommended Fix

Track agent-initiated sends explicitly. When the gateway sends a message via imsg send, record the text+timestamp in an "agent-sent" cache. Only match against this cache when deduping — not against arbitrary is_from_me:true events from the database.

This way:

• Agent sends "Hello" → recorded in agent-sent cache → echo dropped (correct)
• User sends "Hey" → NOT recorded in agent-sent cache → message delivered (correct)

Workaround

Roll back to a pre-#38440 version. This restores message delivery but also restores the echo loop bug (#1649):

npm install -g [email protected]
openclaw gateway restart

No workaround exists that fixes both the echo loop and the dedupe regression simultaneously.

Related Issues / PRs

• fix(imessage): dedupe reflected self-chat duplicates #38440 — iMessage self-chat echo dedupe (merged) — the PR that introduced this regression
• fix(bluebubbles): dedupe reflected self-chat duplicates #38442 — BlueBubbles self-chat echo dedupe (merged) — same pattern, likely same regression for BB self-chat users
• iMessage self-chat creates echo loop despite v2026.1.22 fixes #1649 — Original self-chat echo loop bug
• iMessage self-chat echo: reflected duplicate messages bypass from-me filtering #32166 — Detailed root cause analysis of the two-entry pattern
• iMessage channel duplicate message loop - messages sent by agent are re-ingested as inbound #41330 — Duplicate message loop report
• [Bug]: iMessage self-chat causes bot to re-ingest its own messages, leading to session loops #2585 — Self-chat re-ingestion bug with screenshots
• Echo tracker doesn't cover tool-sent messages in self-chat mode #26770 — Echo tracker doesn't cover tool-sent messages in self-chat mode (related gap in echo tracking)