openclaw - 💡(How to fix) Fix WhatsApp group commands ignored when owner sender is reported as LID JID [1 comments, 2 participants]

Summary

WhatsApp group commands like /new and /stop can be ignored in some group chats when Baileys reports the sender as a WhatsApp LID JID (@lid) instead of a normal phone JID (@s.whatsapp.net).

This appears to break owner/command authorization because the LID sender is not resolved through the WhatsApp auth directory before checking the configured owner allowlist.

Impact

In affected WhatsApp groups:

• /new does not start/reset a session.
• /stop does not stop/reset routing as expected.
• The command reaches the Gateway, but is treated as unauthorized or skipped before the normal command handler replies.
• The same account can be authorized correctly when represented as a normal phone JID, but not when represented as a LID JID.

Expected behavior

If the message sender is the configured owner, /new and /stop should be accepted in WhatsApp groups regardless of whether Baileys reports the sender as:

• a normal phone JID, or
• a LID JID that can be mapped back through the account auth state.

Observed behavior

For an affected group message:

• Sender identity sometimes arrives as @lid.
• Command authorization fails for that LID identity.
• The equivalent phone JID for the same account authorizes successfully.
• Result: group control commands are ignored or rejected even though the actual sender is the configured owner.

Likely cause

In @openclaw/whatsapp, command authorization and/or group gating paths call identity helpers without passing the account auth directory, so LID-to-phone resolution cannot happen.

For example, in the current stable package and also in @openclaw/[email protected], resolveWhatsAppCommandAuthorized() appears to call:

getSelfIdentity(params.msg)
getSenderIdentity(params.msg)

instead of passing the auth directory where available, e.g.:

getSelfIdentity(params.msg, params.authDir)
getSenderIdentity(params.msg, params.authDir)

There may be related group gating/history paths with the same issue, especially around owner bypass for control commands before mention gating.

Versions checked

• [email protected] stable: affected
• @openclaw/[email protected]: inspected, appears still affected

Suggested fix

Thread authDir through the WhatsApp command authorization and group gating identity resolution paths, then add a regression test where:

1. the configured owner is a phone/E.164 identity,
2. the incoming group sender is a LID JID,
3. the auth state can map the LID back to the owner,
4. /new and /stop are accepted as authorized commands.

Also worth testing mention-prefixed forms in groups if command parsing runs after mention stripping.