After adding new telegram bot / new api key, openclaw doesn't receive messages

[rapid sierra]

outbound test with openclaw message send --channel telegram --target <my_telegram_id> --message "telegram outbound test" worked fine, and

TOK="$(openclaw config get channels.telegram.botToken)"
watch -n 1 "curl -s https://api.telegram.org/bot${TOK}/getUpdates?limit=1"

Also works to receive messages.

But nothing appears in the logs of openclaw logs --follow --plain --max-bytes 1000000 and similar commands, it doesn't appear like openclaw gets anything.

[severe gust]

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

[rapid sierra]

more info from my claw:

• Gateway process count is clean: only one openclaw-gateway process running.
• Telegram probe is healthy (getMe + polling mode + empty webhook URL).
• But channel runtime still shows: lastInboundAt: null (so OpenClaw has not accepted any inbound since latest restart).
• So this is no longer “is the bot up?” — it’s an inbound acceptance path problem.

[rustic sphinx]

If openclaw message send --channel telegram … works but no inbound Telegram messages ever show up in Gateway logs, it’s usually one of these:

1. The Gateway isn’t actually running the Telegram receiver (wrong config file / not restarted / channel disabled)
2. Something else is polling getUpdates (Telegram allows only one active long-poll consumer; your watch curl …getUpdates… can absolutely interfere)
3. A webhook is set (polling won’t work if a webhook is active)

Here’s the fastest debug path:

1) Stop your watch … getUpdates test (important)

While testing, do not run any other getUpdates loop in parallel.

Then restart the gateway:

openclaw gateway restart

2) Check channel probe (this usually reveals the exact failure)

openclaw channels status --probe

Paste the Telegram section output here.

Also grab:

openclaw gateway status
openclaw --version

(gateway status is key because it shows whether the service is using a different config than your CLI.)

3) Verify Telegram webhook state (should be empty for polling)

TOK="$(openclaw config get channels.telegram.botToken)"
curl -s "https://api.telegram.org/bot${TOK}/getWebhookInfo"

If it shows a non-empty "url", clear it:

curl -s "https://api.telegram.org/bot${TOK}/deleteWebhook?drop_pending_updates=true"

Then openclaw gateway restart again.

4) If it’s “receiving” but not “responding”: check pairing/allowlist

Default DM policy is often pairing, so you might need to approve:

openclaw pairing list telegram

Send the outputs from (2) and the getWebhookInfo JSON from (3) and we can pin it down quickly.

That exact combo (“probe healthy”, webhook empty, but lastInboundAt: null right after swapping to a new bot token) strongly suggests an offset mismatch:

OpenClaw persists the last seen Telegram update_id in the state dir:

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

If you previously ran a different bot on the same accountId, the stored lastUpdateId can be way higher than the new bot’s update stream (new bots start low) → OpenClaw polls with an offset “in the future” and will never receive anything.

Fix (safe + reversible)

On the gateway host:

ls -la ~/.openclaw/telegram
cat ~/.openclaw/telegram/update-offset-default.json 2>/dev/null || true

Then move it out of the way (backup) and restart:

mv ~/.openclaw/telegram/update-offset-default.json ~/.openclaw/telegram/update-offset-default.json.bak 2>/dev/null || true
openclaw gateway restart

Send a new DM to the bot and re-check:

• openclaw channels status (watch lastInboundAt)
• optionally openclaw channels logs --channel telegram for live confirmation

If your Telegram accountId isn’t default, you’ll see the actual filename in ~/.openclaw/telegram/ (same fix: move that one aside).

If this fixes it, it’s probably worth a GitHub issue: “Telegram update offset store should reset when bot token changes / bot id changes”.