Summary

On OpenClaw 2026.4.9, the WhatsApp web channel is periodically restarting on an approximately 30 minute cadence even while the gateway itself remains healthy and the channel recovers automatically.

The installed runtime appears to enforce an internal watchdog timeout:

const MESSAGE_TIMEOUT_MS = tuning.messageTimeoutMs ?? 1800 * 1e3;

but that setting does not appear in the shipped runtime schema or docs/config surface.

Result: operators can observe a recurring reconnect defect, but cannot tune or disable the watchdog through supported configuration.

Environment

• OpenClaw: 2026.4.9
• Host: Linux 6.8.0-107-generic
• Channel: WhatsApp web
• Gateway stays up and reachable during the incident window

Observed behavior

Recurring log pattern:

2026-04-12T04:52:11Z [whatsapp] No messages received in 30m - restarting connection
2026-04-12T04:52:11Z [whatsapp] Web connection closed (status 499). Retry 1/12...
2026-04-12T04:52:15Z [whatsapp] Listening for personal WhatsApp inbound messages.

2026-04-12T06:08:16Z [whatsapp] No messages received in 30m - restarting connection
2026-04-12T06:08:16Z [whatsapp] Web connection closed (status 499). Retry 1/12...
2026-04-12T06:08:20Z [whatsapp] Listening for personal WhatsApp inbound messages.

The gateway remains healthy and openclaw status still shows WhatsApp OK / linked after recovery.

Expected behavior

• An idle but healthy WhatsApp session should not be forced into a reconnect every 30 minutes if the socket is otherwise fine.
• If a watchdog is intentionally present, its cutoff should be operator-configurable via supported config/schema/docs.

Runtime evidence

Installed runtime (/usr/lib/node_modules/openclaw/dist/login-g69ar5A1.js):

2295: const MESSAGE_TIMEOUT_MS = tuning.messageTimeoutMs ?? 1800 * 1e3;
2296: const WATCHDOG_CHECK_MS = tuning.watchdogCheckMs ?? 60 * 1e3;
2398: if (timeSinceLastMessage <= MESSAGE_TIMEOUT_MS) return;

Relevant block:

const MESSAGE_TIMEOUT_MS = tuning.messageTimeoutMs ?? 1800 * 1e3;
const WATCHDOG_CHECK_MS = tuning.watchdogCheckMs ?? 60 * 1e3;
...
if (keepaliveOk) return;
const timeSinceLastMessage = Date.now() - lastMessageAt;
if (timeSinceLastMessage <= MESSAGE_TIMEOUT_MS) return;
logger.warn("No messages received in 30m - restarting connection");
await client.destroy();
await connectOnce();

Config/schema/docs evidence

The exposed WhatsApp operations surface appears to include only:

• web.enabled
• web.heartbeatSeconds
• web.reconnect.*

Evidence from shipped files:

• docs/gateway/configuration-reference.md
• docs/channels/whatsapp.md
• dist/runtime-schema-*.js

I could not find any documented or schema-exposed messageTimeoutMs or watchdogCheckMs field, despite the runtime reading both internally.

Additional note

There was also earlier evidence of intermittent restored corrupted WhatsApp creds.json from backup warnings during some reconnect cycles, but the later 06:08Z recurrence reproduced the 30 minute watchdog restart without that restore warning in the immediate log window.

That suggests the hidden watchdog is a primary defect surface on its own, while auth-store restore churn may be a separate/intermittent reconnect-path weakness.

Why this matters

This creates an operator dead end:

• the restart behavior is runtime-driven
• the knob exists internally
• but there is no supported way to tune it

Suggested fixes

Any of these would help:

1. Expose messageTimeoutMs (and possibly watchdogCheckMs) in the supported WhatsApp config/schema/docs
2. Revisit the watchdog logic so an idle-but-healthy socket does not get restarted so aggressively
3. Clarify whether this watchdog is intended behavior and what the supported tuning path should be

Reproduction / verification

From the affected host:

journalctl --user -u openclaw-gateway --since '2026-04-12 04:45:00 UTC' --no-pager \
  | grep -E 'No messages received in 30m|status 499|restored corrupted WhatsApp creds.json from backup|Listening for personal WhatsApp inbound messages'

grep -n 'MESSAGE_TIMEOUT_MS\|messageTimeoutMs\|watchdogCheckMs' \
  /usr/lib/node_modules/openclaw/dist/login-g69ar5A1.js