openclaw - 💡(How to fix) Fix [Feature]: Support WhatsApp interactive list context and list replies

Summary

Expose WhatsApp interactive list rows to agents and allow the WhatsApp channel to reply with a selected row id.

Problem to solve

WhatsApp business and service flows often send interactive lists (listMessage) where each option has a stable row id. Today the WhatsApp channel does not expose the incoming list rows/row ids as structured context, and outbound message actions do not provide a first-class way to answer the list with singleSelectReply.selectedRowId.

That means agents have to guess from visible text such as "Option 1" or send a plain text answer. This is unreliable for flows where WhatsApp expects an actual list selection payload, for example appointment booking, delivery scheduling, account-service menus, or bill/payment workflows.

<img width="150" alt="Image" src="https://github.com/user-attachments/assets/06f7391a-7dfc-4019-a03c-b070c82a976f" /> <img width="150" alt="Image" src="https://github.com/user-attachments/assets/d5c2142b-a9f2-45b2-9583-2228c724cb63" /> <img width="150" alt="Image" src="https://github.com/user-attachments/assets/4d0c8333-ea7c-40b6-b3c2-142f1efefcb3" />

Proposed solution

Add first-class WhatsApp interactive list support in the WhatsApp Web channel:

1. Inbound extraction: detect listMessage payloads, including wrapped messages such as ephemeralMessage, and extract title, description, button text, footer text, list type, section titles, row titles, row descriptions, and row ids.
2. Agent context: render the list options into the inbound body for readability and attach an untrusted structured context entry labeled WhatsApp list so agents can choose by row id instead of guessing labels.
3. Content gating: ensure inbound list prompts count as user-visible content so they are not dropped by the inbound content gate added around #73823.
4. Outbound action: add a WhatsApp list-reply message action that sends a Baileys list reply payload with singleSelectReply.selectedRowId, plus optional quote context for the original list message.
5. Tests: cover direct and wrapped inbound list messages, structured context propagation, send payload shape, runtime action gating, and row-id validation.

Alternatives considered

• Send the row title as plain text: this can work for some bots but fails when the remote flow expects a WhatsApp interactive list reply payload.
• Expose raw Baileys payloads to agents: this is more brittle and gives agents too much low-level transport detail.
• Only parse listResponseMessage: useful after a user clicks a list row, but insufficient for automation because the agent must first see the available rows and their row ids.
• Treat quick-reply buttons and native-flow interactions in the same change: useful, but larger. This request is scoped to WhatsApp list prompts and list replies; button reply support can be a follow-up.

Impact

Affected: WhatsApp Web channel users automating conversations with business/service bots that use interactive lists. Severity: Medium to high; it blocks workflows that require selecting from a list. Frequency: Every bot flow that requires a WhatsApp list selection. Consequence: Agents cannot complete the flow autonomously, users must intervene manually, or automation has to guess option labels without access to the real row id.

Evidence/examples

Related prior work: #73823 added a content gate for inbound WhatsApp user-visible content and explicitly considered wrapped interactive responses. This feature should follow the same discipline: wrapper-aware extraction, explicit positives/negatives, and no side effects from non-content events.

Concrete example shape: an inbound listMessage includes sections and rows with stable rowId values; an outbound list selection is represented by a list reply with singleSelectReply.selectedRowId.

Local validation for the proposed implementation includes targeted tests for direct and wrapped list extraction, structured context propagation, list reply send payloads, and runtime action validation, plus the full WhatsApp extension test lane.

Additional information

This should remain backward-compatible: existing text/media/contact/location handling should continue unchanged. The structured list context should be treated as untrusted input, like other inbound WhatsApp structured objects.