Yeah, this looks very close to a known 2026.4.1 WSL2 Telegram startup regression: Telegram logs starting provider, never reaches getUpdates, and inbound messages donβt process. That issue was closed as fixed/implemented; the fix landed in v2026.4.5 by bounding Telegram startup calls so they canβt hang before polling begins. (api.github.com)
First thing: please paste this, with tokens redacted:
openclaw --version
openclaw gateway status
openclaw channels status --probe
openclaw channels logs --channel telegram --lines 100
openclaw status --all
If youβre on 2026.4.1β2026.4.4, update past 2026.4.5 and restart the gateway. If youβre already newer, then the likely causes shift to: gateway using a different config/env than your shell, Telegram token not visible to the service, channels.telegram.enabled/token config, webhook mode accidentally enabled, or a duplicate poller/token conflict. Telegram uses bot token config/env and does not use openclaw channels login telegram; long polling is the default unless webhookUrl is set. (docs.openclaw.ai)
Donβt paste the bot token here. π¦