Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

After upgrading from 2026.3.22 to 2026.4.1, Telegram polling silently stalls on startup in WSL2. The bot logs
"starting provider" but never enters the getUpdates loop, so no inbound messages are received. Downgrading to 3.22
immediately fixes the issue.

Steps to reproduce

1. Install OpenClaw 2026.4.1 on WSL2 (Linux 6.6.87.2-microsoft-standard-WSL2, Node v22.22.0).
2. Configure Telegram channel with polling mode and a valid bot token.
3. Start the gateway via systemd: systemctl --user start openclaw-gateway.service
4. Send a DM to the bot from Telegram.
5. Observe no inbound message processing in journalctl or /tmp/openclaw/ logs.

Expected behavior

In 2026.3.22, the gateway logs autoSelectFamily, dnsResultOrder, registers bot commands, and immediately begins
polling. Inbound messages are received and processed normally.

Actual behavior

In 2026.4.1, the gateway logs only "[telegram] [default] starting provider (@zaqkurobot)" and stops. No
autoSelectFamily/dnsResultOrder/command registration logs appear. No getUpdates requests are made. No errors are
emitted. openclaw channels status --probe and openclaw doctor both report Telegram as "ok/works" despite polling
being dead.

OpenClaw version

2026.4.1 (da64a97)

Operating system

WSL2 - Ubuntu (Linux 6.6.87.2-microsoft-standard-WSL2)

Install method

npm global

Model

anthropic/claude-sonnet-4-6

Provider / routing chain

openclaw -> anthropic (primary), openclaw -> openrouter (fallback)

Additional provider/model setup details

No response

Logs, screenshots, and evidence

# 4.1 (broken) - only this line appears, then silence:
  [telegram] [default] starting provider 

  # 3.22 (working) - full initialization:
  [telegram] [default] starting provider 
  [telegram] autoSelectFamily=false (default-wsl2)
  [telegram] dnsResultOrder=ipv4first (default-node22)
  [telegram] rejected 91 commands (BOT_COMMANDS_TOO_MUCH); retrying with 72.
  [telegram] accepted 72 commands after BOT_COMMANDS_TOO_MUCH (started with 91; omitted 19).
  # -> polling starts, messages received normally

Impact and severity

Affected: All Telegram users on WSL2 with polling mode on 2026.4.1
Severity: High (Telegram channel completely non-functional)
Frequency: 100% reproducible (5/5 restart attempts)
Consequence: Bot cannot receive any inbound messages via Telegram

Additional information

Last known good: 2026.3.22 (4dcc39c)
First known bad: 2026.4.1 (da64a97)
Workaround: Downgrade to 2026.3.22 via npm install -g [email protected]

Suspected root cause: 4.1 changelog includes "Channels/session routing: move provider-specific session conversation
grammar into plugin-owned session-key surfaces" and multiple Telegram retry/polling refactors. The new initialization
flow may not complete under WSL2's network stack.