openclaw - 💡(How to fix) Fix [Bug]: WhatsApp flaps and Telegram polling stalls on WSL2 in 2026.4.26 [2 comments, 2 participants]

Bug type

Channel reliability / WSL2 regression

Summary

On WSL2 with OpenClaw 2026.4.26, both configured messaging channels are unreliable:

• WhatsApp is reported as linked/connected/healthy, but repeatedly disconnects, fails WebSocket handshakes, hits DNS EAI_AGAIN, and sometimes receives WhatsApp-side 405 Connection Failure.
• Telegram is reported as running in polling mode, but long-polling stalls for 120+ seconds and then restarts.
• User-visible result: WhatsApp integration effectively does not work reliably, and Telegram responses are slow, inconsistent, or incoherent because transport stalls combine with stuck agent/model runs.

This appears to be a channel runtime/network handling issue on WSL2 rather than a simple missing token or unlinked account.

Environment

• OpenClaw: 2026.4.26 (be8c246)
• OS: WSL2 Ubuntu 24.04.4 LTS on Windows
• Kernel: 6.6.87.2-microsoft-standard-WSL2
• Install method: npm global (~/.npm-global/bin/openclaw)
• Gateway mode: local loopback
• Node used by service: /usr/bin/node
• Channels enabled: telegram, whatsapp
• Telegram mode: polling
• WhatsApp mode: WhatsApp Web / linked account

Channel status snapshot

openclaw channels status --json reports both channels as configured/running:

{
  "telegram": {
    "configured": true,
    "running": true,
    "tokenSource": "config",
    "mode": "polling"
  },
  "whatsapp": {
    "configured": true,
    "statusState": "linked",
    "linked": true,
    "running": true,
    "connected": true,
    "healthState": "healthy",
    "lastDisconnect": {
      "status": 408,
      "error": "status=408 Request Time-out Connection was lost",
      "loggedOut": false
    },
    "reconnectAttempts": 1
  }
}

So the UI/status layer can claim WhatsApp is healthy while recent logs show repeated disconnects/restarts.

WhatsApp symptoms / logs

Representative logs:

[whatsapp] [default] starting provider (+91...)
[whatsapp] Listening for personal WhatsApp inbound messages.
[whatsapp] Web connection closed (status 408). Retry 1/12 in 2.4s… (status=408 Request Time-out Connection was lost)
[whatsapp] [default] channel exited: {"error":{"output":{"statusCode":408,"payload":{"message":"WebSocket Error (Opening handshake has timed out)"}}}}
[whatsapp] [default] channel exited: {"error":{"data":{"errno":-3001,"code":"EAI_AGAIN","syscall":"getaddrinfo","hostname":"web.whatsapp.com"},"output":{"statusCode":408,"payload":{"message":"WebSocket Error (getaddrinfo EAI_AGAIN web.whatsapp.com)"}}}}
[whatsapp] [default] channel exited: {"error":{"data":{"reason":"405","location":"frc"},"output":{"statusCode":405,"payload":{"message":"Connection Failure"}}}}
[whatsapp] [default] auto-restart attempt 6/10 in 164s
[whatsapp] [default] channel stop exceeded 5000ms after abort; continuing shutdown
[whatsapp] Failed hydrating participating groups on connect: 1006

The account is linked and can briefly enter a listening state, but the WebSocket connection repeatedly fails or is terminated.

Telegram symptoms / logs

Representative logs:

[telegram] [default] starting provider
[telegram] menu text exceeded the conservative 5700-character payload budget; shortening descriptions to keep 65 commands visible.
[telegram] Polling stall detected (active getUpdates stuck for 124.16s); forcing restart.
[telegram] [diag] polling cycle finished reason=polling stall detected ... durationMs=124164 ... error=Network request for 'getUpdates' failed!
[telegram] polling runner stopped (polling stall detected); restarting in 2.19s.
[telegram] [diag] closing stale transport before rebuild
[telegram] [diag] rebuilding transport for next polling cycle
[telegram] fetch fallback: enabling sticky IPv4-only dispatcher (codes=UND_ERR_CONNECT_TIMEOUT)
[telegram] fetch fallback: DNS-resolved IP unreachable; trying alternative Telegram API IP (codes=UND_ERR_CONNECT_TIMEOUT)

This makes Telegram inbound/reply behavior slow and inconsistent.

Basic network probes from WSL

Basic HTTPS probes from the same WSL environment succeed:

curl -I -L --max-time 15 https://web.whatsapp.com
# HTTP/2 200

curl -I -L --max-time 15 https://api.telegram.org
# HTTP/2 302 -> HTTP/2 200

DNS also resolves both domains from WSL:

getent hosts web.whatsapp.com
# resolves to WhatsApp CDN host

getent hosts api.telegram.org
# resolves IPv6 address

So the environment is not fully offline. The failures seem specific to long-lived WhatsApp WebSocket / Telegram long-poll traffic and/or how the channel runtime handles WSL DNS/network intermittency.

Downstream agent/model symptoms

Transport failures are compounded by agent/model failures, which likely explain the user-visible “non-coherent/inconsistent” replies:

[diagnostic] stuck session ... state=processing age=... queueDepth=0
[session-write-lock] releasing lock held for 88633ms (max=15000ms)
[agent/embedded] embedded run agent end ... error=LLM request timed out
[agent/embedded] embedded run agent end ... error=LLM request failed: network connection error
[agent/embedded] embedded run agent end ... provider=kilocode error=402

Even when a channel receives a message, the response path can stall, time out, or fall back into a provider/payment error.

What was ruled out

• WhatsApp is not simply unlinked; status says linked and connected at times.
• Telegram is not simply unconfigured; it starts in polling mode and periodically rebuilds transport.
• Basic HTTPS to web.whatsapp.com and api.telegram.org from WSL works.
• The failure is not limited to one user action; logs show recurring disconnects/stalls over time.

Possible related issues / upstream context

• #59833: Telegram polling stalls on startup in WSL2 in 2026.4.x-era builds.
• #7885: WhatsApp login on WSL2 fails with status=408 Request Time-out WebSocket Error even when curl https://web.whatsapp.com returns 200.
• #13544: WhatsApp DNS hiccup / EAI_AGAIN web.whatsapp.com and timeout reconnects.
• WhiskeySockets/Baileys#2370: WhatsApp/Baileys 405 Connection Failure during WebSocket/device handshake.

Expected behavior

• WhatsApp should remain connected once linked, or classify the channel unhealthy while it is flapping.
• Telegram polling should recover quickly from transient network failures and should not stall for 120+ seconds before restart.
• Channel status should reflect recent disconnect/retry state accurately, not show “healthy” while repeated reconnect failures are happening.
• Replies should not become delayed/incoherent due to unbounded stuck sessions or provider fallback loops.

Actual behavior

• WhatsApp repeatedly disconnects or fails to reconnect despite linked/healthy status.
• Telegram polling stalls and restarts after long delays.
• Agent/model failures and session locks compound the channel transport issues, making responses delayed or inconsistent.

Suggested investigation

• Check whether WSL2 needs special DNS/IP family handling for WhatsApp WebSocket and Telegram long-polling beyond the current sticky IPv4 fallback.
• Review WhatsApp channel health classification: a linked account with repeated 408, EAI_AGAIN, 405, and 1006 should probably not report healthy.
• Review Telegram polling watchdog behavior under WSL2 and provider/model load.
• Consider exposing recent channel transport errors in channels status so the status output matches logs.
• Consider bounding stuck agent/session/model work so channel replies do not degrade into long-running inconsistent states.

Temporary workarounds under consideration

No durable workaround has been confirmed for this exact WSL2 + 2026.4.26 setup.

Potential diagnostic workarounds to validate:

env -u HTTP_PROXY -u HTTPS_PROXY -u ALL_PROXY -u http_proxy -u https_proxy -u all_proxy \
  openclaw channels status

and forcing IPv4/DNS behavior if supported by channel runtime, since logs show Telegram trying sticky IPv4 fallback after UND_ERR_CONNECT_TIMEOUT.

the last working version [on WSL2 was 2026.4.23. It was unusuable post that @steipete