Whatsapp not working

[vestal wren]

Hi, I’d appreciate help diagnosing an OpenClaw WhatsApp inbound issue.

Environment:

• OpenClaw 2026.5.12
• @openclaw/whatsapp@2026.5.12 exact-pinned
• WhatsApp channel shows linked/running/connected/healthy
• Gateway and Discord are OK
• WhatsApp is scoped to DM/self-chat usage

Issue:
A WhatsApp self-chat message does not become an accepted inbound message in OpenClaw and does not create an agent turn. This does not look like a connection outage because the WhatsApp channel stays healthy/linked.

Already tested:

1. Post-update smoke test: self-chat message did not show as accepted inbound, and there was no agent dispatch/reply log.
2. Env-gated temporary instrumentation around messages.upsert / inbound normalization: the test message did not hit the instrumentation at all.
3. Broader env-gated event-surface instrumentation in the WhatsApp monitor file:
   • messaging-history.set/status
   • messages.upsert/update
   • message-receipt.update
   • chats.upsert/update
   • contacts.upsert/update
   • lid-mapping.update
   • connection.update
   • creds.update

Result:
No diagnostic event lines from the self-chat test, no inbound message, no accepted inbound, no enqueue/dispatch/reply. WhatsApp stayed healthy. All temporary patches/env flags were rolled back and the rollback was verified.

Current interpretation:
This no longer looks like a normal OpenClaw inbound-normalization skip. It looks more like self-chat is not delivered to the linked-device/Baileys socket as a usable event, or it lands outside the listener surfaces OpenClaw uses.

Question:
Is this a known self-chat + WhatsApp linked-device/Baileys limitation in OpenClaw? Should the next step be a clean WhatsApp relink/reinstall, or first a non-self-chat inbound test? Is there another event surface or setting worth checking before resetting the session?
```

[inland aurora]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[prisma hollow]

I checked current docs/source. OpenClaw does have explicit personal-number/self-chat support, so I would not treat this as an intentional “self-chat unsupported” mode. Docs: https://docs.openclaw.ai/channels/whatsapp

The important bit from your instrumentation is: if messages.upsert and the broader Baileys event surface never fire, this is probably below OpenClaw inbound normalization. The current WhatsApp inbound monitor consumes messages.upsert for actual inbound messages and connection.update for lifecycle; once a message reaches messages.upsert, OpenClaw has self-chat handling for fromMe, allowlist/self-number checks, read-receipt suppression, and echo dedupe.

Recommended next step before any reset: do a non-self-chat DM test from another WhatsApp account/device to the linked WhatsApp number.

Expected branches:

• Non-self DM works, self-chat does not: likely a self-chat delivery/linked-device/Baileys edge case. I’d file that as a GitHub issue with your instrumentation notes: https://github.com/openclaw/openclaw/issues
• Non-self DM also produces no messages.upsert: then it’s not self-chat-specific; check allowlist/pairing, then relink.
• Non-self DM produces messages.upsert but gets skipped: then inspect channels.whatsapp.allowFrom, dmPolicy, account id overrides, and pairing state.

Useful checks before relink:

openclaw status --all
openclaw channels status --probe
openclaw pairing list whatsapp