watch.subscribe can report group link-preview messages as chat_id=0 DM-shaped payloads

[zqchris]

Summary

watch.subscribe can emit a malformed notification for an iMessage group link-preview message: the live watch payload loses the group conversation metadata and reports the event as a DM-like chat_id=0 payload, while messages.history for the same message GUID returns the correct group metadata.

This can cause downstream consumers to route replies to the sender DM unless they add their own fail-closed recovery guard.

Observed watch payload shape

For a group message containing a URL plus text, the OpenClaw monitor received an event equivalent to:

{
  "chat_id": 0,
  "chat_guid": "",
  "chat_identifier": "",
  "is_group": false,
  "sender": "<redacted account/handle>",
  "text": "https://example.invalid/...\n<message text>",
  "guid": "<redacted guid>"
}

The downstream log showed it as a direct-message route:

• inbound: chatId=0 from=imessage:<sender>
• outbound target became imessage:<sender>

Same GUID via history

Querying the same message GUID through messages.history returned the correct group record:

{
  "chat_id": 349,
  "chat_guid": "any;+;<redacted group>",
  "chat_identifier": "<redacted group identifier>",
  "is_group": true,
  "participants": ["<redacted>", "<redacted>"],
  "guid": "<same guid>"
}

All personal handles, message GUIDs, and group names are redacted here, but the mismatch was confirmed live on the same machine and same bridge.

Expected behavior

watch.subscribe should emit the same stable conversation metadata as messages.history for the same message GUID, especially:

• correct positive chat_id
• is_group: true for group chats
• non-empty chat_guid / chat_identifier when available
• participants/group name when available

If a live watch event cannot resolve conversation metadata, it should expose a clear error/partial flag rather than emitting a DM-shaped payload.

Downstream mitigation

OpenClaw added a local mitigation to recover malformed chat_id=0 payloads by GUID before routing, and to drop fail-closed if recovery fails:

• OpenClaw issue: iMessage group link-preview watch payload can lose conversation anchor and route reply to DM openclaw#84470
• Local mitigation commit: zqchris/openclaw@7c56a6bba852

Environment notes

• imsg status --json reported bridge_version: 2, v2_ready: true, and watch.subscribe / messages.history in rpc_methods.
• The triggering message was a group link-preview/link-rich message.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve.

Workflow note: Future ClawSweeper reviews update this same comment in place.

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

Summary
Keep open. Current main still has a source-reproducible path where a live watch row without a resolved chat join becomes chat_id: 0, then the RPC payload builder emits empty chat identifiers and is_group: false; that matches the reported DM-shaped group-link-preview payload and is not covered by an existing imsg PR.

Reproducibility: no. full live reproduction was run in this read-only pass. Source inspection shows a clear current-main path from an unjoined watch row to chat_id: 0, empty chat metadata, and is_group: false, matching the reporter's redacted live payload.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Share version, platform, channel/provider, and relevant config details.

Next step
Maintainer review is needed before a repair lane changes live iMessage watch semantics for a privacy-sensitive wrong-recipient routing bug.

Security
Needs attention: The issue itself is security-sensitive because malformed group watch payloads can cause wrong-recipient iMessage replies even though no patch is under review.

Review details

Best possible solution:

Make watch payload construction refuse normal message notifications when chat metadata is unresolved: retry or requery by row/GUID until the chat join resolves, and if it cannot, emit an explicit error/partial state or drop fail-closed instead of producing empty chat identifiers.

Do we have a high-confidence way to reproduce the issue?

No full live reproduction was run in this read-only pass. Source inspection shows a clear current-main path from an unjoined watch row to chat_id: 0, empty chat metadata, and is_group: false, matching the reporter's redacted live payload.

Is this the best way to solve the issue?

Partly. The invariant is clear, but maintainers should choose the exact watch behavior for unresolved metadata, such as short retry/requery versus explicit error or fail-closed drop, because it affects live stream delivery semantics.

Label changes:

• add P1: A live iMessage group event can be exposed to downstream agents as a direct-message-shaped payload, creating wrong-recipient routing in real channel workflows.
• add impact:security: Wrong-recipient iMessage delivery can expose group-context agent output to an unintended direct recipient.
• add impact:message-loss: The reported failure can misroute a reply away from the originating group conversation to a sender DM.
• add issue-rating: 🐚 platinum hermit: Current issue advisory state selects this label.
• add clawsweeper:needs-live-repro: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.
• add clawsweeper:needs-security-review: Current issue advisory state selects this label.

Label justifications:

• P1: A live iMessage group event can be exposed to downstream agents as a direct-message-shaped payload, creating wrong-recipient routing in real channel workflows.
• impact:message-loss: The reported failure can misroute a reply away from the originating group conversation to a sender DM.
• impact:security: Wrong-recipient iMessage delivery can expose group-context agent output to an unintended direct recipient.

Security concerns:

• [high] Prevent anchorless group watch rows from becoming DMs — Sources/IMsgCore/MessageStore+Queries.swift:84
  All-chat watch can currently emit a row with chat_id resolved to 0; the payload layer then fills empty chat identifiers and is_group: false, which downstream consumers may treat as a sender DM.
  Confidence: 0.84

Acceptance criteria:

• Add a focused regression fixture for a message row observed before its chat_message_join metadata resolves.
• Run make test after adding coverage for watch/RPC payload behavior.
• Run make lint before merge.

What I checked:

• Reporter live mismatch and downstream mitigation: The issue body reports a live watch.subscribe notification with chat_id: 0, empty chat_guid/chat_identifier, and is_group: false, while messages.history for the same GUID returned group metadata; the linked OpenClaw issue remains open with a local mitigation and PR reference for downstream routing.
• All-chat watch allows rows before chat metadata is resolved: MessagesAfterQuery uses LEFT JOIN chat_message_join when no chat_id filter is supplied, so a newly observed message row with no join row yet can still be selected by all-chat watch. (Sources/IMsgCore/MessageStore+Queries.swift:84, c7ae79c1b195)
• Unresolved chat joins become chat_id 0: decodeMessageRow resolves the chat id from the selected cmj.chat_id, then the fallback chat id, then 0; for all-chat watch the fallback is nil, matching the reported chat_id=0 output shape. (Sources/IMsgCore/MessageStore+Messages.swift:337, c7ae79c1b195)
• RPC watch emits the built payload directly: handleWatchSubscribe streams MessageWatcher messages, calls buildMessagePayload, and sends the result as a message notification without a guard for chat_id <= 0 or missing chat identifiers. (Sources/imsg/RPCServer+Handlers.swift:122, c7ae79c1b195)
• Payload builder turns missing chat info into DM-shaped fields: buildMessagePayload looks up chat info and participants by message.chatID; messagePayload then substitutes empty strings for missing chat metadata and computes is_group only from those empty identifiers, producing is_group: false. (Sources/imsg/RPCPayloads.swift:39, c7ae79c1b195)
• Documented contract expects watch/history chat metadata: Docs say nested chat metadata in history/watch includes identifiers, group/direct flag, and participants, and watch debouncing is intended to collapse database follow-up writes into one stable emission per row. (docs/watch.md:67, c7ae79c1b195)

Likely related people:

• steipete: Local blame on the current watch query/payload implementation points to the v0.9.0 release snapshot, and remote history shows this person hardened URL balloon watch dedupe, exposed RPC watch debounce, and added group metadata to JSON output. (role: recent area contributor; confidence: high; commits: b85e701f2b0b, c9fa1c20033c, 60ed8a9f02eb; files: Sources/IMsgCore/MessageStore+Messages.swift, Sources/IMsgCore/MessageStore+Queries.swift, Sources/imsg/RPCServer+Handlers.swift)
• lesaai: PR history shows this person authored the original URL balloon watch deduplication change, which is the closest prior work on link-preview-specific watch behavior. (role: URL preview watch contributor; confidence: medium; commits: a2c16b3caccb; files: Sources/IMsgCore/MessageStore+Messages.swift)
• omarshahine: Remote history shows recent work changing the message/history/watch query path and moving query structs into MessageStore+Queries.swift, so this person is relevant for routing maintainers through the current message-row implementation. (role: recent adjacent contributor; confidence: medium; commits: dc94c36d308e, 2d7b506d1736; files: Sources/IMsgCore/MessageStore+Messages.swift, Sources/IMsgCore/MessageStore+Queries.swift, Sources/imsg/RPCServer+Handlers.swift)

Remaining risk / open question:

• The redacted live event has not yet been converted into a deterministic fixture, so the exact Messages write-order race still needs a regression test.
• The fix needs to avoid turning legitimate direct-message rows into dropped events while preventing unresolved group rows from looking like DMs.
• Wrong-recipient iMessage routing is privacy-sensitive, so maintainers should choose the retry/drop/error semantics before landing behavior changes.

Codex review notes: model gpt-5.5, reasoning high; reviewed against c7ae79c1b195.