openclaw - 💡(How to fix) Fix WhatsApp group: CLI assistant reply generated but never dispatched (group lane only — DM works) [1 comments, 2 participants]

Summary

CLI backend (claude-cli) generates a reply for inbound WhatsApp group messages, but the reply never reaches the WhatsApp dispatch path. WhatsApp DM replies on the same setup work correctly. The agent runs to completion and writes its assistant text to the Claude CLI session jsonl, but [whatsapp] Sending message is never logged for the group response.

Reproducer

• OpenClaw 2026.5.3-1
• Claude CLI 2.1.126 backend (Max plan, OAuth)
• WhatsApp account paired, channels.whatsapp.groups["<groupId>@g.us"].requireMention = false
• Group sender is in channels.whatsapp.groupAllowFrom

Send any message into the configured group with requireMention: false. The bot processes the message — [whatsapp] Inbound message <groupId>@g.us is logged, then [agent/cli-backend] cli exec: provider=claude-cli model=opus trigger=user fires. The Claude CLI session jsonl gains both the user prompt and an assistant text response. But [whatsapp] Sending message is never logged for the reply, and OpenClaw's session jsonl + trajectory.jsonl are not written either.

Side-by-side evidence (same gateway, same WhatsApp account, same agent)

For the group, an example response captured in Claude CLI's session jsonl:

ASSISTANT TEXT: "Hey Raj 👋 What's up? 🔵🌀"

Despite this, the WhatsApp dispatch path never fires for the group lane.

Suspected location

In extensions/whatsapp/src/auto-reply/monitor/dispatch.ts (compiled into monitor-C4Fhg_lD.js), the dispatchWhatsAppBufferedReply function delivers replies via:

const reply = resolveSendableOutboundReplyParts(normalizedDeliveryPayload);
if (!reply.hasMedia && !reply.text.trim()) return;

Either dispatchReplyWithBufferedBlockDispatcher is not extracting any text from the CLI stream for group lanes, or resolveSendableOutboundReplyParts is returning an empty reply.text (after trim) and short-circuiting before deliverReply.

A HEARTBEAT_OK-strip filter is also wired into the dispatcher (onHeartbeatStrip), worth verifying it isn't over-matching for group payloads.

Bug history (not just a recent regression)

This bug has been silently present for at least the last 3 days. An older group session trajectory snapshot from 2026-05-03 shows model.completed with 130 output tokens followed by session.ended with assistantTexts: 0 — so OpenClaw was discarding the assistant text from the model output even back then. The bug went unnoticed because the only observable WhatsApp activity in that group was an unrelated daily cron sending pre-built messages directly to the group (not via the agent reply path).

Setup details

• OpenClaw 2026.5.3-1
• channels.whatsapp.groupPolicy: "allowlist"
• channels.whatsapp.dmPolicy: "pairing"
• messages.ackReactionScope: "group-mentions"
• agents.defaults.model.primary: "claude-cli/claude-opus-4-6"
• agents.defaults.model.fallbacks: ["claude-cli/claude-sonnet-4-6", "google/gemini-2.5-flash"]
• cliBackends.claude-cli.command: "/home/ubuntu/.local/bin/claude" with -p --output-format stream-json --include-partial-messages --verbose

DMs work end-to-end with the exact same agent/model/CLI configuration. Only the group lane drops the response.