openclaw - 💡(How to fix) Fix iMessage group link-preview watch payload can lose conversation anchor and route reply to DM

Summary

A malformed iMessage watch notification for a group link-preview message can be interpreted as a direct message, causing OpenClaw to reply to the sender DM instead of the originating group.

This is a high-risk routing/privacy bug: when a channel payload loses its conversation anchor, OpenClaw must not fall back to a sender DM.

Observed behavior

A group message containing a link arrived from watch.subscribe with this effective shape:

• chat_id: 0
• empty chat_guid
• empty chat_identifier
• is_group: false
• sender set to the account/handle that later became the DM target
• message text contained the URL plus user text

OpenClaw routed it as:

• inbound: chatId=0 from=imessage:<sender>
• session: agent:<agent>:imessage:default:direct:<sender>
• outbound: imessage: delivered reply to imessage:<sender>

The same message GUID looked up through messages.history belonged to the real group:

• chat_id: 349
• is_group: true
• non-empty chat_guid / chat_identifier
• group participants present

I am intentionally redacting handles, GUIDs, and group names here.

Expected behavior

If iMessage watch payloads lack a valid conversation anchor, OpenClaw should either:

1. recover the real conversation from a stable message identifier before routing, or
2. fail closed and drop the event.

It should never route a malformed group/link-preview event to a sender DM.

Local mitigation proof

A local patch on patch/chris adds a guard and recovery path:

• detect chat_id <= 0 with empty chat_guid and chat_identifier
• use the message GUID to inspect recent chats.list + messages.history
• repair the payload before routing when the GUID is found
• drop the event when the real conversation cannot be recovered

Commit: https://github.com/zqchris/openclaw/commit/7c56a6bba852

After the patch and gateway restart, the same event replayed as:

• inbound: chatId=349 from=imessage:group:349
• session: agent:<agent>:imessage:group:349
• outbound: imessage: delivered reply to chat_id:349

Verification run locally

• env OPENCLAW_VITEST_MAX_WORKERS=1 node scripts/run-vitest.mjs extensions/imessage/src/monitor/conversation-repair.test.ts extensions/imessage/src/monitor.gating.test.ts
• pnpm exec oxfmt --check --threads=1 extensions/imessage/src/monitor/conversation-repair.ts extensions/imessage/src/monitor/conversation-repair.test.ts extensions/imessage/src/monitor/monitor-provider.ts extensions/imessage/src/monitor/inbound-processing.ts extensions/imessage/src/monitor.gating.test.ts
• git diff --check
• pnpm build
• live gateway restart and replay/log verification as described above

Notes

The underlying bridge/source issue appears to be in imsg watch.subscribe, because messages.history for the same GUID returns the correct group metadata. I am filing a companion issue against openclaw/imsg for that payload mismatch.