Summary

WhatsApp connections enter a stale socket state where the gateway reports both accounts as "Listening" but inbound messages are silently swallowed — never surfaced to the agent. The socket appears healthy (no disconnect event) but is functionally dead.

This is message loss, not cosmetic reconnect noise.

Environment

• OpenClaw version: 2026.4.8
• Platform: macOS Darwin 25.2.0 (arm64)
• Two WhatsApp accounts configured (default + secondary)

Observed behavior

At reconnect, both accounts report Listening for personal WhatsApp inbound messages.

A message was sent to an active, allowlisted group ~7 minutes after reconnect. The connection appeared live. No disconnect event occurred.

Gateway logs for the ~17 minute window:

[timestamp] [whatsapp] Listening for personal WhatsApp inbound messages.
            [17 minutes of complete silence — no inbound event, no routing, no error]
[timestamp] [health-monitor] health-monitor: restarting (reason: disconnected)

The inbound message was never logged. No routing event. No agent run. The message was permanently lost — not delivered after reconnect.

Pattern

This stale socket state occurs repeatedly throughout the day alongside the 408 disconnect cycle. Both accounts disconnect and reconnect in sync, sometimes as frequently as every 2-3 minutes. On reconnect, the socket occasionally enters a stale state where it appears connected but silently drops all inbound messages.

The health-monitor has previously logged reason: stale-socket explicitly on the same day, confirming this is a known internal state.

Root cause hypothesis

After a rapid reconnect cycle, Baileys initialises the WebSocket but the connection is in a degraded state — the socket handshake completes but the message event pipeline is not fully re-established. Messages arrive at WhatsApp's server, Baileys acknowledges the socket-level keepalive, but message events are never emitted upward to OpenClaw.

Impact

• Messages are permanently lost. WhatsApp does not redeliver messages to a session that appears connected.
• healthMonitor: { enabled: true } does not catch this — it checks socket connectivity, not message flow.

Suggested fix

Add a message-flow health check alongside the socket health check: track the timestamp of the last inbound message event per account, and if no message has been received in N minutes while the socket is connected, treat it as a stale socket and force a reconnect. This is separate from the current keepAlive and healthMonitor mechanisms.

The existing No messages received in 30m - restarting connection logic is a step in this direction but the 30-minute window is too long — a message can be lost in a 17-minute stale window. Reducing this to ~10 minutes would significantly reduce message loss exposure.

Workaround

None currently. healthMonitor: true is enabled but does not detect message-flow staleness.