openclaw - 💡(How to fix) Fix WhatsApp: multi-image forwarded messages only deliver the first image to the LLM [2 pull requests]

Problem

When a user forwards a WhatsApp message containing two (or more) images, WhatsApp delivers them as separate messages ~200ms apart. Only the first image reaches the LLM turn; the second image appears to be dropped.

Current behaviour

1. Two inbound image/jpeg messages are logged by the gateway within ~200ms of each other
2. Only one [agents/tool-images] Image resized log entry appears
3. The LLM responds referencing only the first image
4. The second image is never surfaced to the agent — no resize, no error, no follow-up turn

Gateway log excerpt:

[whatsapp] Inbound message ... (direct, image/jpeg, 70 chars)
[whatsapp] Inbound message ... (direct, image/jpeg, 70 chars)   # 208ms later
[agent/embedded] low context window: ... source=agentContextTokens
[agents/tool-images] Image resized to fit limits: 943x2048px 54.7KB -> 31.7KB (-42%)   # only ONE resize
[whatsapp] Sent message ...   # reply references first image only

Root cause analysis

shouldDebounceTextInbound() in channel-inbound-DA8hoGuJ.js explicitly returns false when hasMedia is true (line 13). This means media messages bypass the inbound debounce entirely and each fires its own turn immediately.

With queue.mode: "steer", the second message should be steered into the running turn, but it appears to be silently dropped — no second image resize, no error, no separate follow-up turn.

By contrast, the Telegram channel handler has mediaGroupBuffer with mediaGroupFlushMs: 500 (in bot-etaDTLyM.js) that coalesces media-group messages before flushing them as a single turn. The WhatsApp channel has no equivalent media-group coalescing.

Requested change

Add WhatsApp media-group coalescing similar to Telegram's mediaGroupBuffer — when multiple media messages arrive from the same sender within a short window (~500ms), coalesce them into a single LLM turn with all images attached.

Alternatively, ensure that queue.mode: "steer" properly injects media attachments from steered messages into the running turn (not just text).

Environment

• OpenClaw version: 2026.5.3-1
• Channel: WhatsApp (built-in)
• Node: v22.22.2
• OS: Linux (x64)
• Config: channels.whatsapp.debounceMs: 0, messages.queue.mode: "steer"
• Setting debounceMs to a non-zero value does not help because shouldDebounceTextInbound bypasses debounce for media messages regardless