Summary

When requireMention: true is set on a WhatsApp group, swipe-replying to the bot's messages does not trigger a response. The bot silently ignores the reply. This is because WhatsApp migrated to LID (Linked Identity Device) format for user identities, and OpenClaw's applyGroupGating function only compares the quoted message sender against the traditional @s.whatsapp.net JID -- never against the @lid format.
Related: #11758 (same root cause, different symptom -- that issue covers explicit @mentions, this one covers implicit reply-to-bot detection)

Steps to reproduce

Configure a WhatsApp group with requireMention: true
Have the bot send a message in the group
Swipe-reply to the bot's message (on iPhone or WhatsApp Web) without typing the bot's name
The bot ignores the reply

Expected behavior

Reply-to-bot should count as an implicit mention (as documented) and trigger a response.

Actual behavior

The reply is silently dropped. The implicit mention check fails because the quoted message sender comes back in LID format (XXXXXXXXXXXX@lid) instead of the expected JID format ([email protected]).

OpenClaw version

OpenClaw Version: 2026.2.17 (4134875)

Operating system

OS: macOS (Apple Silicon, Mac Mini M4)

Install method

Node: v22

Logs, screenshots, and evidence

Enabling debug logging on inbound messages shows the reply context IS being delivered by Baileys, but in LID format:
json{
  "keys": ["extendedTextMessage", "messageContextInfo"],
  "hasContext": true,
  "participant": "XXXXXXXXXXXX@lid"
}
The bot's creds.json contains both identity formats:
json"me": {
  "id": "1XXXXXXXXXX:[email protected]",
  "lid": "XXXXXXXXXXXX:1@lid"
}

Impact and severity

Severity: Medium
Impact: For anyone using requireMention: true on WhatsApp groups, reply-to-bot (implicit mention) is completely broken if their account uses WhatsApp's LID format. Users must type the bot's name every time instead of just swiping to reply. This appears to be an expanding issue as WhatsApp continues migrating accounts to LID.

Additional information

Root Cause
In channel-web-.js, the applyGroupGating function computes implicitMention by comparing replySenderJid against selfJid and selfE164. It never extracts or compares the bot's LID. Since WhatsApp now returns the LID in the quoted message context, the comparison always fails.
Fix (3 edits to channel-web-.js)
All edits are in the compiled WhatsApp channel file (dist/channel-web-*.js). The equivalent changes would apply to the TypeScript source.
Edit 1: Capture selfLid from Baileys socket (near socket init)
javascript// BEFORE:
const selfJid = sock.user?.id;

// AFTER:
const selfJid = sock.user?.id;
const selfLid = sock.user?.lid;
Edit 2: Pass selfLid into the inbound message object
Add selfLid, right after selfJid, in the message object that gets passed to applyGroupGating:
javascriptselfJid,
selfLid, // <-- add this line
selfE164,
Edit 3: Add LID comparison to implicit mention check
javascript// BEFORE:
implicitMention: Boolean(
selfJid && replySenderJid && selfJid === replySenderJid ||
selfE164 && replySenderE164 && selfE164 === replySenderE164
),

// AFTER:
const selfLidBare = params.msg.selfLid?.replace(/:\d+/, "");
// ...
implicitMention: Boolean(
selfJid && replySenderJid && selfJid === replySenderJid ||
selfLidBare && replySenderJid && selfLidBare === replySenderJid ||
selfE164 && replySenderE164 && selfE164 === replySenderE164
),
The key insight: selfLid from creds.json has a device suffix (e.g., XXXXXXXXXXXX:1@lid) but the replySenderJid from the quoted message context has it stripped (e.g., XXXXXXXXXXXX@lid). The .replace(/:\d+/, "") normalizes this.
Gotcha
If you're patching the compiled JS with sed, be careful: the selfJid, pattern may match in multiple places. In my case, it matched at both the connection handler (correct) and a debug logging function (wrong). Adding selfLid, to the debug function caused a ReferenceError: selfLid is not defined crash because that variable isn't in scope there. Fix: use selfLid: msg.selfLid ?? null, in the debug location so it reads from the message object instead.
Notes

This patch gets wiped on npm update -g openclaw. Re-apply after updates.
Tested and working on both iPhone swipe-replies and WhatsApp Web (desktop) replies.
This likely affects anyone whose WhatsApp account uses LID format (ongoing WhatsApp migration).
Related: #11758 (same root cause, different symptom -- that issue covers explicit @mentions, this one covers implicit reply-to-bot detection)