Whatsapp not working

[primal phoenix]

Hi — asking for help with WhatsApp same-phone/selfChatMode on OpenClaw 2026.5.7.

Setup:

• OpenClaw updated from 2026.4.24 to 2026.5.7 (eeef486)
• Official plugin installed: openclaw plugins install @openclaw/whatsapp
• Gateway reachable/stable
• discovery.mdns.mode = off (fixed earlier Bonjour/CIAO loop)
• WhatsApp:
  • Channels: ON / OK / configured · accounts 1/1
  • Health: LINKED · linked
• Config:
  • channels.whatsapp.enabled = true
  • selfChatMode = true
  • dmPolicy = allowlist
  • allowFrom = +358… (own number)
  • sendReadReceipts = false
  • debounceMs = 0

Issue:
Sending a WhatsApp message to myself from the SAME linked phone/account still never reaches OpenClaw inbound.

Test:
Sent:
selfchat testi 1648

Observations:

• text not found in gateway.log / gateway.err.log
• no inbound message log
• no dispatch/routing
• no fromMe/selfChatMode/same-phone/remoteJid/LID/E.164 mismatch logs
• listener starts correctly:
  • starting provider (+358…)
  • Listening for personal WhatsApp inbound messages
• heartbeat/plugin health alive:
  • messagesHandled: 0
  • lastInboundAt: null
  • transport activity updates normally
• no new Bonjour/CIAO/1006/401/logout problems

Important:
On 2026.4.24 we already traced a likely same-phone normalization issue around:

• messages.upsert
• fromMe
• remoteJid
• selfE164
• isSamePhone = params.from === params.selfE164

Discord search also found a similar selfChatMode format mismatch bug.

Question:
Is same-phone/selfChatMode expected to fully work in 2026.5.7 with the official WhatsApp plugin + Baileys?

And if yes:

• what debug/logging flag should we enable to see whether Baileys emits the self-message at all
• or whether the plugin silently drops it before inbound logging?

[elder junco]

I checked current docs + the WhatsApp plugin code. Short version: yes, same-phone/selfChatMode is intended to work, but your exact symptom points to either Baileys not emitting the self-message to the linked Web session, or the plugin dropping it before its useful inbound/access-control logging.

Docs explicitly describe personal-number mode with:

• dmPolicy: "allowlist"
• own number in allowFrom
• selfChatMode: true

https://docs.openclaw.ai/channels/whatsapp

What I see in current code:

• inbound is only handled from Baileys messages.upsert where type is notify or append
• status/broadcast JIDs are dropped
• messages without extractable user content are dropped before access-control logging
• then remoteJid is resolved to E.164; if that fails, it returns before access-control logging
• access control then allows same-phone DMs, but isSamePhone is still an exact from === selfE164 check after resolution
• accepted messages log as inbound message; self-chat should also log things like Self-chat mode: skipping read receipt... when verbose/debug logging is active

So if your test string is absent and messagesHandled: 0 / lastInboundAt: null, it probably is not reaching the accepted inbound path.

For logging, the most useful built-in knob is file debug logging / verbose runtime logging, not a WhatsApp-specific raw event flag. Try temporarily setting:

logging: {
  level: "debug"
}

Then restart the gateway and tail with:

openclaw logs --follow

That should surface plugin verbose logs and Baileys info-level logs. But important caveat: I do not see a current built-in “dump raw Baileys messages.upsert payloads” flag. If debug logging still shows no inbound message, no self-chat read-receipt skip, and no access-control block/skip line, then the next useful diagnostic is a maintainer-side/raw instrumentation around messages.upsert before normalizeInboundMessage().

Given you already found a prior format mismatch and this is same-phone-specific, I’d file this as a GitHub issue with the details you posted plus:

• exact openclaw --version
• whether logging.level: "debug" shows any Baileys activity at send time
• redacted self identity shape if visible: E.164/JID/LID
• whether sending to OpenClaw from a different WhatsApp account still works

Issue tracker: https://github.com/openclaw/openclaw/issues

My read: expected behavior: yes; evidence from your logs: the message is being dropped/never emitted before the normal inbound log path.

[primal phoenix]

Follow-up after enabling debug logging:

We did a controlled debug test on OpenClaw 2026.5.7 + @openclaw/whatsapp.

Temporary change:

• backed up openclaw.json
• set logging.level = debug
• restarted gateway
• tailed logs with openclaw logs --follow
• sent new same-phone WhatsApp selfChat test
• restored config from backup afterwards, logging.level removed again, gateway restarted

Final state after restore:

• Gateway reachable
• OpenClaw 2026.5.7
• WhatsApp ON / OK
• Health LINKED
• no credential/relink/reset/plugin reinstall done

Debug findings:

• Baileys activity is visible: WA connection opens, login/session valid, own PN/LID visible, listener starts
• During the selfChat test, no messages.upsert appears
• No normal inbound message
• No fromMe/selfChatMode/same-phone/remoteJid/LID/E.164/allowFrom/access-control block/skip lines
• Heartbeat remains:
  • messagesHandled: 0
  • lastInboundAt: null
• One Baileys warning appeared: timed out waiting for message

Interpretation:
The message disappears before OpenClaw’s inbound handler and before access-control/routing. This now looks less like an OpenClaw routing/config issue and more like Baileys/WhatsApp Web not emitting same-account self-messages to the linked session, or requiring raw instrumentation before/around messages.upsert to prove it.

Question:
Is there any known WhatsApp Web/Baileys limitation for same-account self-messages? If not, what exact raw instrumentation around messages.upsert would you want in a GitHub issue/repro?

[elder junco]

Nice, that’s a clean test. I agree with your interpretation: if debug shows Baileys/session activity but no messages.upsert at all during the self-chat send, then this is before OpenClaw routing/access-control. The timed out waiting for message warning is consistent with the Web socket being alive but not receiving an app-message event.

I don’t know of a documented Baileys guarantee that WhatsApp Web linked devices receive primary-phone → same-account/self chat messages as messages.upsert. Baileys docs describe messages coming from history sync or messages.upsert, but that doesn’t prove WhatsApp emits this particular self-message path to linked devices. So I’d phrase it in the issue as: “possible WhatsApp Web/Baileys same-account self-message emission gap,” not as a confirmed OpenClaw config failure.

For a repro, I’d want raw instrumentation at the very top of OpenClaw’s messages.upsert handler, before this filter:

if (upsert.type !== "notify" && upsert.type !== "append") return;

File in current source:

extensions/whatsapp/src/inbound/monitor.ts

Useful temporary log shape:

const summarizeWaMessageForDebug = (msg: WAMessage) => ({
  id: msg.key?.id,
  fromMe: msg.key?.fromMe,
  remoteJid: msg.key?.remoteJid,
  participant: msg.key?.participant,
  pushName: msg.pushName,
  timestamp: msg.messageTimestamp ? Number(msg.messageTimestamp) : undefined,
  messageTypes: msg.message ? Object.keys(msg.message) : [],
  hasText: Boolean(
    msg.message?.conversation ||
    msg.message?.extendedTextMessage?.text
  ),
});

const handleMessagesUpsert = async (upsert) => {

  inboundConsoleLog.warn(
    `RAW messages.upsert type=${upsert.type} count=${upsert.messages?.length ?? 0} ` +
    JSON.stringify((upsert.messages ?? []).map(summarizeWaMessageForDebug))
  );

  // existing code continues here
};

If maintainers want even earlier proof, add a second listener immediately after the existing listener registration, ideally before normal processing or alongside it:

const rawDebugMessagesUpsert = (upsert) => {
  inboundConsoleLog.warn(
    `RAW-EARLY messages.upsert type=${upsert?.type} count=${upsert?.messages?.length ?? 0} ` +

    JSON.stringify((upsert?.messages ?? []).map(summarizeWaMessageForDebug))
  );
};

const detachRawDebugMessagesUpsert = attachEmitterListener(
  sock.ev as any,
  "messages.upsert",
  rawDebugMessagesUpsert as any,
);

Then include in the issue:

• raw log when sending from a different WhatsApp account/contact
• raw log when sending same-phone/selfChat from the linked primary phone
• whether the self-message appears later as append after reconnect/history sync
• whether sending the self-message from WhatsApp Web/Desktop vs the primary phone changes behavior

• redacted own PN/JID/LID, plus exact OpenClaw + plugin version

Avoid logging full msg.message or message bodies except a harmless nonce if needed — JIDs/IDs/timestamps/types are enough.

Docs link for context: https://docs.openclaw.ai/channels/whatsapp

My best read: OpenClaw expects same-phone selfChat to work if Baileys emits the message; your debug now strongly suggests Baileys/WA Web is not emitting that primary-phone self-message into the linked session.

[crisp snow]

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

[primal phoenix]

Another update after clean relink on 2026.5.7.

We did a full official relink against the external @openclaw/whatsapp plugin:

• no manual credential deletion
• no manual session edits
• used official openclaw channels login --channel whatsapp
• scanned fresh QR
• old linked device removed from phone
• new login completed successfully:
  • Linked! Credentials saved for future sends.

Current status after relink:

• OpenClaw 2026.5.7 (eeef486)
• Gateway reachable
• Event loop OK
• WhatsApp:
  • Channels: ON / OK / configured · accounts 1/1
  • Health: LINKED (fresh auth age)
• listener starts normally
• no new Bonjour/CIAO/1006/401 issues

We also tested with:

• second WhatsApp account
• second number added to allowFrom
• dmPolicy = allowlist
• selfChatMode = true

But still:

• no inbound message
• no messages.upsert
• no dispatch/routing
• no Baileys message activity visible during send
• messagesHandled remains effectively zero

So now this reproduces even after:

1. migration to external plugin
2. clean relink
3. fresh QR/session
4. allowlisted external sender

At this point it no longer looks like:

• stale session
• allowlist issue
• selfChatMode-only issue
• routing issue
• gateway instability

It looks more like:

• Baileys not emitting inbound events to this linked session
  OR
• plugin listener never receiving app-message events despite healthy socket state

Question:
What would you inspect next before raw patch instrumentation?

Would you:

• instrument directly around messages.upsert
• inspect Baileys socket state/events
• inspect WA Web sync/history state
• or suspect something macOS/Apple Silicon specific here?

Also: have you seen cases where WA stays fully LINKED/healthy but inbound app-message events never arrive at all?

[elder junco]

That changes the shape a lot. Once an external allowlisted sender also produces no inbound/no messages.upsert, I’d stop treating this as selfChatMode. This is now “healthy linked socket, but no app-message events reach the listener.”

I would not suspect macOS/Apple Silicon first. Possible, but lower on my list. Baileys is JS/WebSocket; platform-specific failures usually show up as install/runtime/socket/auth weirdness, not selectively “connected but no app messages.”

Next checks before patching OpenClaw code:

1. Verify outbound over the same session

   • Can OpenClaw send a WhatsApp message via the message tool / channel send to the second number?
   • If outbound works but inbound doesn’t, auth + socket command path are alive, but receive/app-sync is broken.
   • If outbound also fails/hangs, inspect socket/auth/session deeper first.

2. Test whether any non-message events arrive at send time

   • During the external account send, does lastTransportActivityAt move?
   • If transport frames move but no Baileys app event appears, Baileys/WA is receiving bytes but not surfacing a message event.
   • If transport activity does not move at all, the linked device may be connected but not being delivered message traffic.

3. Check event categories beyond messages.upsert

• A message might arrive as history/sync/update rather than notify, especially around fresh relinks.
  • I’d inspect: messaging-history.set, messages.upsert, messages.update, message-receipt.update, chats.upsert, chats.update, contacts.upsert, connection.update, and creds.update.

4. Check companion/device state outside OpenClaw
   • In WhatsApp phone app: linked device is active, not stale, not immediately “last active” old.
   • Send a message while the gateway is already running and listener has started.
   • Try toggling phone/network once if linked-device delivery looks asleep.

If those don’t reveal it, I’d go straight to raw instrumentation. Not later in access-control — right at the socket event boundary.

Suggested minimal raw event probe:

const summarize = (msg: WAMessage) => ({
  id: msg.key?.id,
  fromMe: msg.key?.fromMe,

  remoteJid: msg.key?.remoteJid,
  participant: msg.key?.participant,
  pushName: msg.pushName,
  ts: msg.messageTimestamp ? Number(msg.messageTimestamp) : undefined,
  messageTypes: msg.message ? Object.keys(msg.message) : [],
});

const logRaw = (event: string, payload: any) => {
  inboundConsoleLog.warn(
    `WA-RAW ${event} ` + JSON.stringify({
      type: payload?.type,
      count: payload?.messages?.length,
      messages: payload?.messages?.map?.(summarize),
      keys: payload && typeof payload === "object" ? Object.keys(payload) : undefined,
    })

  );
};

for (const event of [
  "messaging-history.set",
  "messages.upsert",
  "messages.update",
  "message-receipt.update",
  "chats.upsert",
  "chats.update",
  "contacts.upsert",
  "connection.update",
  "creds.update",
]) {
  sock.ev.on(event as any, (payload: any) => logRaw(event, payload));

}

Also add a WS frame counter/timestamp beside that if possible, because the key distinction is:

• frames move, no Baileys event → Baileys/event decoding/sync issue
• no frames move when message sent → WhatsApp linked-device delivery issue
• raw event appears but OpenClaw doesn’t process → OpenClaw filter/normalization bug

Have I seen this exact pattern before? I can’t claim a known prior case from memory — my memory search is currently unavailable — but “LINKED/healthy only proves the socket/auth state,” not that app-message delivery is working. A Web session can look alive while message sync/delivery is wedged, especially after relink/migration/provider changes. This repro is issue-worthy now.

[primal phoenix]

Update after more testing.

We now confirmed outbound works from a normal local Terminal.

Earlier openclaw message send failed with:

text connect EPERM 127.0.0.1:18789

but that turned out to be sandbox-specific. Running the same command directly in a local Terminal succeeds.

Gateway log confirms outbound send succeeds:

• WhatsApp send starts
• message gets sent successfully
• gateway returns successful send response

Current confirmed state:

• external WhatsApp plugin installed
• gateway healthy/reachable
• WhatsApp LINKED/OK
• outbound works
• no more Bonjour/CIAO instability

Remaining issue:
Inbound still does not arrive at all.

Tested with:

• external allowlisted sender
• sender added to allowFrom
• fresh relink + QR
• healthy session

But:

• no inbound message log
• no dispatch/routing
• no agent response
• no visible messages.upsert
• no obvious Baileys message event during inbound send

Question:
If outbound works on the same linked WhatsApp session but inbound never appears, what would you inspect next?

Most likely candidates?

1. linked-device receive/app-sync issue
2. listener/event subscription problem after channel start
3. inbound arriving under different Baileys event category
4. stale/conflicted receive state after earlier 440 conflict
5. need for raw instrumentation around messages.upsert and related events

[elder junco]

Outbound working is a really useful split. It means the auth/session/send path is valid; the broken part is specifically receive/event delivery.

My ranking now:

1. Listener/event subscription problem or receive-side event gap

   • The plugin says listener starts, but we need proof sock.ev actually receives app events after that.
   • This is the highest-value next check.

2. Inbound arriving under another Baileys event category

   • Especially after relink/history sync, it may show as messaging-history.set, messages.update, chats.update, etc., not the normal messages.upsert path OpenClaw processes.

3. Linked-device receive/app-sync wedged

   • Outbound can work while app-message sync is not being delivered to that linked device/session. “LINKED” doesn’t prove receive sync is healthy.

4. Stale/conflicted receive state from earlier 440

   • Less likely after fresh QR + old linked device removed, but still plausible if WhatsApp’s server-side companion state is weird. Current code has explicit 440 conflict handling, so if no 440 is logged now, it’s probably not an active visible conflict.

5. macOS/Apple Silicon
   • I’d put this last. Platform issues usually break install/native deps/socket startup, not just inbound app events while outbound works.

At this point I would instrument, not keep poking config. Specifically: raw event boundary, plus listener count / WS activity.

Add temporary logs for:

sock.ev.listenerCount?.("messages.upsert")

right after listener registration, and raw listeners for:

messaging-history.set
messages.upsert

messages.update
message-receipt.update
chats.upsert
chats.update
contacts.upsert
connection.update
creds.update

The important diagnostic matrix is:

• External inbound send causes WS frames but no Baileys events → Baileys/decode/app-sync issue.
• Baileys raw event appears, but no messages.upsert → OpenClaw needs to handle another event/sync path.
• messages.upsert raw appears, but normal inbound does not → OpenClaw filter/normalization bug.
• No WS frames at all during external inbound send → WhatsApp linked-device delivery issue, despite LINKED/outbound OK.