Bug Description

When the WhatsApp Web session is logged out (due to phone-side disconnect, session conflict, or instability), the gateway's WhatsApp listener permanently stops and cannot be recovered without a full gateway restart + manual relink.

Environment

• OpenClaw version: 2026.3.13 (61d171a)
• OS: Windows 11 (Windows_NT 10.0.26200 x64)
• Node: v24.13.1
• Channel: WhatsApp (personal Web)

Steps to Reproduce

1. Start gateway with WhatsApp Web linked and working
2. Wait for a session logout event (happens intermittently)
3. All proactive sends fail with: No active WhatsApp Web listener (account: default)
4. openclaw channels status --probe reports linked, running, connected (stale status)
5. openclaw message send fails with the same error
6. openclaw channels login --channel whatsapp shows Linked! Credentials saved
7. message send again — still fails. The gateway process doesn't pick up the new listener.
8. Only a full openclaw gateway restart + channels login resolves it (temporarily).

Root Cause Analysis

Found in source at dist/channel-web-BZO9MGfW.js, around line 2120:

if (loggedOut) {
    runtime.error('WhatsApp session logged out...');
    await closeListener();
    break;  // EXITS THE RECONNECT LOOP PERMANENTLY
}

When loggedOut === true, the code:

1. Calls closeListener() which sets setActiveWebListener(account.accountId, null)
2. Breaks out of the reconnect loop entirely
3. The gateway continues running but with no WhatsApp listener

After this, even a successful channels login doesn't help because:

• The login runs in a separate CLI process
• The gateway's main monitor loop has already exited via break
• There's no mechanism for the gateway to re-enter the monitor loop after a successful relink

Additional Issues

1. Stale status reporting: channels status --probe reports connected even when the listener is dead.
2. Auto-reply vs proactive send divergence: Inbound messages and auto-replies continue working (via the web-inbound path), but proactive sends (message send, cron announces, subagent announces) fail because they call requireActiveWebListener().

Expected Behavior

• After a logout event, the gateway should attempt to re-authenticate using stored credentials before giving up
• If re-auth fails, it should enter a retry loop (with backoff) instead of permanently breaking
• channels login from CLI should be able to inject a new listener into the running gateway process
• channels status should accurately reflect the listener state

Impact

This bug breaks all proactive messaging:

• Cron job delivery (email monitoring, scheduled reports)
• Sub-agent announce delivery
• CLI message send
• Any feature that uses requireActiveWebListener()

Workaround

Currently the only workaround is: openclaw gateway restart followed by openclaw channels login --channel whatsapp — but the session may logout again at any time, requiring repeated manual intervention.