openclaw - 💡(How to fix) Fix WhatsApp channel stuck in start-account phase after restart — inbound messages silently dropped [1 comments, 2 participants]

Summary

After upgrading to v2026.5.6 (CLI + WhatsApp plugin), the WhatsApp channel gets permanently stuck in the channels.whatsapp.start-account startup phase. The gateway logs Listening for personal WhatsApp inbound messages (both accounts), but zero inbound messages are ever received. Outbound sends also hang without confirmation.

Reproduction

1. OpenClaw v2026.5.6, WhatsApp plugin v2026.5.6, macOS 26.2 arm64, node 25.8.2
2. groupPolicy: "allowlist" with groupAllowFrom and groups configured for 7 WhatsApp groups on the default account
3. Stop gateway cleanly, wait 2s, start gateway
4. Gateway logs show "Listening for personal WhatsApp inbound messages" for both accounts
5. Send a WhatsApp message to any configured group
6. No Inbound message log entry ever appears
7. Diagnostic liveness warnings show phase=channels.whatsapp.start-account indefinitely — never transitions to completed

Evidence

Startup sequence (looks normal)

[whatsapp] [default] starting provider (+XXXX)
[whatsapp] [secondary] starting provider (+XXXX)
[gateway] ready
[whatsapp] Listening for personal WhatsApp inbound messages.
[whatsapp] Listening for personal WhatsApp inbound messages.

Diagnostic liveness (stuck in start-account phase)

[diagnostic] liveness warning: reasons=event_loop_delay interval=30s
  eventLoopDelayP99Ms=89.1 eventLoopDelayMaxMs=2516.6
  phase=channels.whatsapp.start-account

This phase persists for minutes (tested up to 5 min). No transition to a completed/ready state.

Gateway log stops writing

After initial startup burst (TUI connect, heartbeat fire, memory qmd syncs), the gateway.log goes completely silent. No new entries for 1-2+ minutes at a time. The process is alive (ps shows R state) and HTTP 200 on the dashboard, but the event loop appears saturated.

Pattern across 3 restarts

• launchctl kickstart -k → same result
• Clean stop/start (no TUI) → same result
• Clean stop/start (TUI reconnects after) → same result

All three show "Listening" but zero inbound messages.

Context

• Prior to v2026.5.6, inbound messages were working (last confirmed inbound: 2026-05-06T20:55:31, before the first restart onto v2026.5.6 with new group config)
• The config change that preceded this: added groupAllowFrom (7 groups) and groups (7 entries with requireMention: false) to channels.whatsapp.accounts.default
• groupPolicy was already "allowlist" but groupAllowFrom and groups were both null before this change
• Secondary account has groupAllowFrom and groups configured and was working before

Additional observation: silent outbound delivery failure

Even before the restart issue, assistant text responses to WhatsApp groups were being generated and written to the session transcript but never delivered as WhatsApp messages. No error logged. Only explicit message tool calls (used by cron jobs) successfully sent. This was the original investigation that led to discovering the missing groupAllowFrom config.

Environment

• OpenClaw: v2026.5.6 (325df3e)
• WhatsApp plugin: v2026.5.6
• OS: macOS 26.2 (arm64)
• Node: v25.8.2
• 2 WhatsApp accounts (default + secondary)
• 7 agents with individual WhatsApp groups
• healthMonitor.enabled: true

Expected behavior

WhatsApp channel should fully initialize and process inbound messages after restart. The start-account phase should complete within a reasonable timeout.

Actual behavior

WhatsApp channel permanently stuck in start-account phase. "Listening" logged but inbound handler is dead. No inbound messages processed. Gateway event loop shows high delay.