OpenClaw Telegram Bug on Windows: Long-Polling May Stall and Some Allowlisted Users Don’t Get Replies (v2026.3.23-2)

A newly reported Windows 11 issue suggests Telegram long-polling can become unstable: OpenClaw can see messages in Telegram Bot API getUpdates, yet does not consistently process them into replies.

In the report, User A sometimes receives replies, while User B frequently receives nothing, even though User B’s messages are visible in the update stream.

Source:

Issue report: openclaw/openclaw#54560

What the report observed (symptoms)

The reporter validated several basics first:

the bot token works (getMe succeeds)
getChat works for the affected private chat
messages from the affected user appear in getUpdates

But OpenClaw behavior is inconsistent:

OpenClaw sometimes sends replies (example log lines like telegram sendMessage ok ...)
another allowlisted user can repeatedly get no replies
logs mention events like:
- polling stall detected (no getUpdates for some period; forcing restart)
- polling runner stop timed out (after ~15s)

Environment in the report:

OpenClaw: 2026.3.23-2
OS: Windows 11

Quick checks to confirm you’re seeing the same class of failure

You’re likely dealing with the same problem if all of the following are true:

You are using Telegram polling (not a different delivery mode).
You can verify the user’s messages appear in Telegram updates.
OpenClaw logs show intermittent polling stalls / forced restarts.
At least one allowlisted user is affected, even though allowlist is correct.

To make it less ambiguous, test with a tight loop:

Ask two different allowlisted users to send a simple message (like “ping”) within 30 seconds.
Immediately check gateway logs for:
- update received / routed events
- any filtering decisions (allowlist)
- message-to-session routing
If the update appears upstream but no downstream processing or reply happens, that strongly points to a polling/runner or routing issue (not a Telegram token problem).

High-impact causes to rule out (common operational pitfalls)

These are not confirmed as the root cause of #54560—but they are common enough that it is worth ruling them out quickly.

1) Two gateways (or two Telegram providers) competing for the same token

Telegram polling is sensitive to multiple consumers:

If two OpenClaw instances poll the same bot token, you can see “random” missing replies.

What to do:

Ensure only one gateway instance is running.
Ensure only one Telegram provider config is active.
Restart cleanly after confirming you’ve stopped other copies.

2) Local state corruption or a stuck runner that doesn’t shut down cleanly

The issue report mentions clearing local Telegram state under ~/.openclaw/telegram and still seeing instability.

If you see “runner stop timed out” repeatedly, the process may be stuck in a way that a normal restart doesn’t fully recover.

What to do:

stop the gateway
confirm the process is truly gone (no lingering node process)
start again and retest

3) Windows networking / long-poll edge cases

Long-polling on Windows can be more fragile in practice due to:

VPN/proxy interception
aggressive firewall/endpoint protection
network sleep / laptop power management

Mitigations to try:

test on a stable network (no VPN, no captive portal)
disable sleep while testing
temporarily allowlist the gateway process in firewall/security software

Who is most affected by this Windows Telegram polling bug

This issue matters most for three groups:

Operators who depend on Telegram as a primary alert or command channel, because intermittent non-replies are easy to miss until an important message is dropped.
Teams allowing multiple humans through one bot, because “user A works, user B fails” is exactly the kind of pattern that wastes time on wrong allowlist theories.
Anyone still running polling on native Windows for convenience, because the easiest-looking setup can become the least predictable under long-poll stalls.

Practical mitigation: move Telegram polling off Windows

If Telegram is business-critical, the most pragmatic mitigation is to run the gateway (or at least the Telegram provider) on a Linux host:

a small VPS
WSL2 on the same machine (if stable in your environment)
a home server / NAS

This reduces the probability of Windows-specific long-poll instability.

Search-intent checklist: what users usually mean when they search this problem

In practice, users rarely search for the full issue title.

They usually search symptoms such as:

OpenClaw Telegram no reply on Windows
Telegram getUpdates works but bot does not answer
OpenClaw polling stall detected Telegram
allowlisted user gets no reply Telegram OpenClaw
runner stop timed out Telegram polling

If you are landing here from one of those searches, the shortest decision tree is:

If getUpdates does not show the message at all
- this is upstream Telegram delivery, token, webhook/polling mode, or network setup—not this exact bug shape.
If getUpdates shows the message but OpenClaw never routes it
- inspect polling stalls, allowlist handling, and duplicate gateway instances first.
If one user works and another user does not
- compare chat type, allowlist identity, and whether a second instance is consuming the same bot token.
If replies resume after restart but then break again
- treat it as runner stability or Windows long-poll fragility until proven otherwise.

That symptom-first framing is often faster than starting from configuration files.

When this article is probably NOT your problem

This page is likely the wrong match if:

you are using Telegram webhooks, not polling
no user messages appear in getUpdates
every user fails equally and immediately after a token rotation
the bot cannot send messages at all, even in a known-good chat

In those cases, start with token validity, delivery mode, webhook conflicts, and general provider configuration before assuming you hit the Windows polling pattern described here.

3-step operator summary

If you only have two minutes, do this in order:

verify the missing user's message actually appears in getUpdates
verify there is only one active gateway consuming that bot token
verify whether the problem disappears when you move polling off native Windows

If step 1 fails, it is not this article's problem shape. If step 2 fails, fix the duplicate consumer first. If only step 3 changes the outcome, treat Windows polling stability as the leading operational suspect.

Common containment questions

When should you stop debugging allowlist syntax and suspect polling stability first

If the affected user clearly appears in getUpdates, the allowlist is already configured to include them, and the failure comes and goes after restarts, that is a strong sign to inspect polling stalls before spending more time rewriting allowlist entries.

What is the fastest low-risk mitigation if the issue is hurting production use

Move the Telegram provider off native Windows first. That is usually lower risk than continuing to tune long-poll behavior on a machine with sleep, VPN, firewall, or endpoint security variables in the mix.

What to include when filing or updating the bug

The fastest path to a fix is a clean, minimal evidence bundle:

exact OpenClaw version (openclaw --version output)
OS + whether it is native Windows, WSL2, or a remote host
whether you run multiple instances
sanitized log excerpts covering:
- Telegram provider startup
- getUpdates polling loop (including the “stall detected” line)
- the time window when User B sends a message
- whether OpenClaw logs show allowlist acceptance for that user

Turn Telegram polling traffic into a Windows stability checklist

If you arrived because Telegram polling is unstable on Windows and an allowlisted user may receive odd replies, do not only restart the bot. Split the issue across four boundaries: whether polling offsets stay continuous, whether allowlist matching targets the right user, whether the Windows process is interrupted by sleep or network switching, and whether duplicate messages come from replayed old polling results.

The minimal checklist includes one polling-offset log, the active allowlist config, Windows power and network state, and the update id for the odd reply. That routes Telegram incident traffic toward Windows deployment, polling recovery, and permission-boundary intent instead of leaving it at intermittent delivery symptoms.

Source

openclaw/openclaw#54560