#Bug: Telegram long-polling receives no inbound messages

1 messages · Page 1 of 1 (latest)

magic ruin
#

Bug: Telegram long-polling receives no inbound messages

OpenClaw version: 2026.2.14 (just updated),
openclaw doctor shows Telegram OK,
openclaw status --deep shows Telegram OK,
Outbound sendMessage works,
getUpdates via curl (with gateway stopped) returns messages correctly,
getUpdates via curl (with gateway running) returns 409 (confirming gateway IS polling),
But zero Telegram messages ever reach the agent,
No errors, no policy blocks, nothing in logs,
Discord and WhatsApp work perfectly on the same setup,
Tried 3 different bot tokens, same result
I was previously able to connect it to my telegram, but moved to my VPS server, could that be the issue?

knotty compassBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> âś… Mark Solution

river hedgeBOT
#

Moving to a new VPS can absolutely cause this — not because Telegram “binds” to a server, but because OpenClaw’s DM access state (pairing/allowlist) and some Telegram state are stored on disk under ~/.openclaw/… on the machine running the gateway.

Given your symptoms (sendMessage works, gateway is definitely polling, but agent never sees inbound), the two most common causes are:

1) DM pairing / allowlist state didn’t come with you (most likely)

Telegram DMs default to dmPolicy: "pairing". If you moved hosts, you likely lost the previous approvals.

Run:

openclaw pairing list telegram
  • If you see a pending code, approve it:
# 
openclaw pairing approve telegram <CODE>

Notes from the docs:

  • pairing state lives under ~/.openclaw/credentials/ (telegram-pairing.json + telegram-allowFrom.json)
  • the bot only sends the pairing prompt roughly once per hour per sender, and pending requests are capped (so spamming messages won’t necessarily keep re-triggering the prompt)

Docs: https://docs.openclaw.ai/channels/pairing and https://docs.openclaw.ai/channels/troubleshooting

2) You’re testing in a group, but mention-gating/privacy is dropping messages

By default OpenClaw expects mentions in groups (requireMention: true), and Telegram bots may not even receive non-command group messages with Privacy Mode on.

Quick checks:

  • Try DMing the bot directly (simplest).
  • In a group, explicitly mention the bot (@botusername) or temporarily run /activation always in that chat.
  • If you want all group messages, disable BotFather privacy mode (/setprivacy) and re-add the bot to the group.
#

Docs: https://docs.openclaw.ai/channels/telegram

If both of those look fine: check the Telegram polling offset file (rare but real)

OpenClaw persists the last processed Telegram update_id to:

  • ~/.openclaw/telegram/update-offset-default.json (or update-offset-<accountId>.json)

If that file somehow contains a huge lastUpdateId, the gateway will poll “past” all real updates and you’ll see exactly “polling, no inbound”.

Can you paste:

  • output of openclaw pairing list telegram
  • output of openclaw channels status --probe
  • and the contents of ~/.openclaw/telegram/update-offset-*.json (if it exists)

That should narrow it down to one of the above in one round-trip.

magic ruin
#
  1. No pending telegram pairing requests.
    root@srv1379492:~# 2)Telegram default: enabled, configured, running, mode:polling, bot:@NYXOPENCLAWBOT, token:config, works 3) -bash: /root/.openclaw/telegram/update-offset-default.json: Permission denied
river hedgeBOT
#

That Permission denied is just because you executed the JSON file (bash tries to run it as a program). You want to print it:

cat /root/.openclaw/telegram/update-offset-default.json
# or, if you’re using a different state dir/profile:
cat "${OPENCLAW_STATE_DIR:-$HOME/.openclaw}/telegram/update-offset-default.json"

Why I’m asking: this is a very likely root cause

OpenClaw persists the last seen Telegram update_id in that file. It’s keyed by accountId (e.g. default) — not by bot token.

So if you:

  • moved hosts,
  • or swapped bot tokens (you said you tried 3),
  • or previously ran with a different bot that had a much higher update_id,

…then the stored lastUpdateId can be ahead of the new bot’s updates, and OpenClaw will silently skip everything as “old” (update_id <= lastUpdateId). At info-level logging you’ll see basically nothing, but polling still happens (and your curl getUpdates shows 409, consistent with gateway polling).

#

Quick fix (safe; just makes a backup)

Stop gateway, move the offset file out of the way, restart:

openclaw gateway stop

mv "${OPENCLAW_STATE_DIR:-$HOME/.openclaw}/telegram/update-offset-default.json" \
   "${OPENCLAW_STATE_DIR:-$HOME/.openclaw}/telegram/update-offset-default.json.bak.$(date +%s)" 2>/dev/null || true

openclaw gateway start

Then DM the bot again.

If you paste the cat …/update-offset-default.json contents here (it’s just a number), I can confirm immediately if it’s the culprit.

(Migration footgun reference, since you moved to a VPS: https://docs.openclaw.ai/install/migrating)

magic ruin
#

root@srv1379492:~# cat /root/.openclaw/telegram/update-offset-default.json
{
"version": 1,
"lastUpdateId": 718297291

river hedgeBOT
#

That lastUpdateId: 718297291 is almost certainly the smoking gun.

OpenClaw persists the last seen Telegram update_id per Telegram accountId (default), not per bot token. So if you switched tokens / moved installs / tried 3 different bots, you can easily end up with an offset that’s “in the future” for the bot you’re currently using — and then every inbound update gets silently skipped (update_id <= lastUpdateId). Polling still happens (hence your 409), but nothing reaches pairing/agent.

Fix (fastest)

openclaw gateway stop

STATE="${OPENCLAW_STATE_DIR:-$HOME/.openclaw}"
mv "$STATE/telegram/update-offset-default.json" \
   "$STATE/telegram/update-offset-default.json.bak.$(date +%s)"

openclaw gateway start

Then DM the bot again (you should immediately see either a pairing prompt or your agent respond).

#

Make it not happen again

If you plan to swap between multiple Telegram bot tokens on the same machine, don’t reuse the same “telegram default” account/state:

  • use separate channels.telegram.accounts.<accountId> per bot or
  • run each gateway instance with a different --profile / OPENCLAW_STATE_DIR

Otherwise they’ll keep sharing update-offset-<accountId>.json and you’ll hit this again.

If after resetting the offset you still get nothing, paste:

  • openclaw status
  • openclaw logs --follow while sending a DM (might need logging.level: "debug" to show skip reasons)