openclaw - 💡(How to fix) Fix [Bug]: WhatsApp group: subsequent @mentions silently dropped after first (regression 2026.5.26)

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

Problem

After upgrading 2026.5.22 → 2026.5.26, only the first @mention of an agent in a WhatsApp group registers in the dashboard and receives a response. All subsequent @mentions in the same session window are silently dropped — no inbound event logged, no response delivered.

Worked correctly on 2026.5.22.

Root Cause

PR #85517 ("Fix foreground reply fence visibility") made the reply fence visibility-aware. With messages.groupChat.visibleReplies: "automatic", the first mention triggers auto-delivery which sets visibleReplySent = true in the fence's per-dispatch state. The fence then cancels all subsequent dispatches in the same group session window before they reach the agent or dashboard.

This interaction did not exist on 2026.5.22 — old fence did not track visibleReplySent. PR review notes confirm live WhatsApp transport was not tested in #85517.

Expected Behavior

All @mentions register as inbound events and receive responses regardless of how many arrive in the same session window — matching 2026.5.22 behavior.

Current Workaround

Revert messages.groupChat.visibleReplies from "automatic" to "message_tool". Restores correct multi-mention behavior immediately (hot-reloads, no restart needed).

Possible Solutions

1. Fix visibility-aware fence in #85517 to not cancel pending dispatches when visibleReplies: "automatic" is set — auto-delivery should not signal "session done" for subsequent inbound triggers
2. Gate visibleReplySent cancellation to only apply when session was explicitly closed by the agent, not by auto-delivery

Impact

Production regression for any WhatsApp deployment using visibleReplies: "automatic". Multiple users mentioning an agent simultaneously results in only first getting a response — all others silently lost with no log or acknowledgment.

Environment

• OpenClaw: 2026.5.26
• Channel: WhatsApp (Baileys), group chat
• Config: groupPolicy: open, replyToMode: first, historyLimit: 0
• Related PR: #85517

Steps to reproduce

1. Start OpenClaw 2026.5.26 with messages.groupChat.visibleReplies: "automatic" in openclaw.json.
2. Have two different users @mention the same agent in a WhatsApp group within 30 seconds of each other.
3. Observe: only first @mention appears in dashboard and receives a response. Second @mention produces no inbound event and no response.

Expected behavior

In 2026.5.22, both @mentions registered as separate inbound events in the dashboard and each received a response. All @mentions in a group session window were processed independently.

Actual behavior

Only the first @mention is logged in the dashboard and triggers a response. All subsequent @mentions in the same session window are silently dropped — no inbound event, no log entry, no response delivered to the user.

OpenClaw version

2026.5.26

Operating system

macOS 15.4 (Mac mini, arm64)

Install method

npm global

Model

openrouter/openai/gpt-5.4-mini

Provider / routing chain

openclaw -> openrouter -> openai/gpt-5.4-mini

Additional provider/model setup details

Fallback chain: openrouter/openai/gpt-5.4-mini -> openrouter/google/gemini-3-flash-preview. Agent: clerk, bound to WhatsApp account via bindings[agentId: "clerk", match: {accountId: "clerkwa", channel: "whatsapp"}]. Relevant config under channels.whatsapp.accounts.clerkwa and messages.groupChat.

Logs, screenshots, and evidence

No dashboard inbound event logged for second @mention — absence of log entry is the evidence.
  Workaround confirmed: reverting messages.groupChat.visibleReplies from "automatic" to
  "message_tool"
  immediately restores multi-mention behavior without restart (hot-reload).
  Root cause traced to PR #85517 — visibility-aware fence sets visibleReplySent = true on first
  auto-delivery, cancelling subsequent dispatches in same group session window.

Impact and severity

Affected: All WhatsApp group users on 2026.5.26 with visibleReplies: "automatic" Severity: High — blocks multi-user concurrent workflows entirely Frequency: Always (100% reproducible — every second @mention dropped) Consequence: Users receive no response and no acknowledgment; silent failure with no error shown

Additional information

Last known good: 2026.5.22 First known bad: 2026.5.26 Regression introduced by PR #85517 ("Fix foreground reply fence visibility") — visibility-aware fence was not tested against live WhatsApp transport per PR review notes. Temporary workaround: set messages.groupChat.visibleReplies: "message_tool" (hot-reloads, no restart needed).