Summary

This commit broke Telegram Webhook incoming messages on startup. It causes a reproducible 1-2 minute pause in message handling at startup AND it may actually corrupt and lose portions of messages as well (still trying to validate):

3cbcba1

It looks like that commit first went out in 2026.2.13

Steps to reproduce

1. Configure Telegram
2. Configure Webhook for Telegram
3. Load this in a browser with your bot token for telegram: https://api.telegram.org/bot<BOT_TOKEN>/getWebhookInfo
4. Load your webhook public URL (just a GET is fine - we just want to confirm we get a 404 and not a 502 after restart)
5. Do a /restart in a telegram chat
6. Wait until your public webhook gives a 404 (couple seconds) for a GET
7. Immediately send a message in Telegram to the bot
8. Refresh the getWebhookInfo page to view the non-zero queued message count

Expected behavior

1. Message should arrive at openclaw immediately in this case
2. Disable the webhook mode and repeat the steps with polling - the message will arrive immediately and typing will be observed along with a quick response

Actual behavior

1. Nothing happens for 1-2 minutes
2. After the 1-2 minutes, the message arrives and typing starts to appear and response happens within a few seconds

OpenClaw version

2026.2.23

Operating system

macOS 26.2

Install method

npm global / pnpm gateway:watch

Logs, screenshots, and evidence

• Demonstrates immediate message receipt on startup with polling
• Demonstrates 1 minute delayed receipt on startup with webhook
• Demonstrates that removing the guard fixes the issue and messages arrive immediately on startup with webhook

Direct link: https://youtu.be/ixwb-LzCh1c

Impact and severity

Affected: Telegram Webhook users
Severity: Annoying + Possible Message Loss / Corruption
Frequency: Always (on Startup)
Consequence: Delays / Useless Troubleshooting / Possible Message Corruption

Additional information

To make the issue go away:

1. Open telegram/webhook.ts
2. Comment out the guard init and the other lines that reference guard. - Clean easy to do in 1 minute
3. Repeat steps - Issue no longer happens

What I think is happening:

1. I have run this in a debugger and the guard is registering on data and on end events as well as the on data and on end events in the grammy http handler
2. This is either:
   1. Completely forbidden and we need to change the grammy registration to callback instead of http and eliminate the duplicate readers - in this case we likely are getting message loss / corruption when the guard swallows and discards the message before grammy can read it and/or we get interleaved reading where some is read by one and some by the other
   2. Completely allowed and it's just a startup condition due to the grammy listeners not being registered before we start listening on our port