Problem

The WhatsApp channel has a hardcoded 30-minute idle timeout (MESSAGE_TIMEOUT_MS = tuning.messageTimeoutMs ?? 1800 * 1e3). When no inbound messages arrive for 30 minutes, the gateway logs:

[whatsapp] No messages received in 30m - restarting connection
[whatsapp] Web connection closed (status 499). Retry 1/12 in 2.15s… (status=499)
[whatsapp] Listening for personal WhatsApp inbound messages.

The reconnect itself is fast (~3 seconds) and always succeeds. The problem is:

1. Session context pollution — each disconnect/reconnect pair generates system messages that get injected into the agent's conversation context. Overnight (8+ hours idle), this produces ~16 pairs of connect/disconnect system messages, wasting tokens and cluttering the session.
2. Log noise — the gateway logs fill with expected, harmless reconnect events that obscure actual issues.

Current behaviour

monitorWebChannel() receives a tuning object, but callers only pass { statusSink, accountId }. The messageTimeoutMs field is never populated from config:

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

Requested change

Expose messageTimeoutMs via config so users can increase or disable the idle reconnect. For example:

{
  "channels": {
    "whatsapp": {
      "messageTimeoutMs": 7200000
    }
  }
}

A value of 0 or -1 could disable the watchdog entirely for always-on personal deployments where the connection is expected to be idle overnight.

Environment

• OpenClaw v2026.4.10
• WhatsApp channel, single account, personal DM pairing
• Gateway runs as systemd service 24/7