Telegram stops replying then after restart answers to all questions and goes unresponsive again

[deft crane]

Hi, I'm running my openclaw bot on a wsl2 for about 2 weeks, connected Telagram as a channel.
I've been successfully using it, except for a few times I had to restart it up until yesterday evening.
Didn't quite understand what made my openclaw go crazy however at some point I noticed she's not replying to DM's or in a test Telegram (2 members, just for experiments) group I've added her to.
Tried restarting, however after restart she'll come online answer to a long list of questions that accumulated and go unresponsive again.
Tried "stop", /new, /reset in the DM chat however they just got added to the accumulated list of messages to which she replies after restart then goes unresponsive again.

What I have already tried to no avail.

1. All kinds of restart commands (I knew)
   a) openclaw gateway restart
   b) openclaw gateway stop
   openclaw gateway start
   c) openclaw gateway --force
   d) systemctl --user stop openclaw-gateway.service
   systemctl --user start openclaw-gateway.service
2. After googling the issue a bit tried deleting the sessions and the update-offset-default.json however that didnt help either
   systemctl --user stop openclaw
   rm -f ~/.openclaw/telegram/update-offset-default.json
   rm -f ~/.openclaw/agents/main/sessions/<stuck-session-id>.jsonl
   systemctl --user start openclaw
3. Updated the openclaw version (to March 2)
4. Did doctor and doctor repair which seems to have migrated legacy sessions
   openclaw doctor
   ◇ Legacy state detected
   │ - Sessions: canonicalize legacy keys in │
   │ /home/aburnazy/.openclaw/agents/main/sessions/sessions.json │
   ◇ Migrate legacy state (sessions/agent/WhatsApp auth) now?
   │ Yes
   ◇ Doctor changes
   │ Merged sessions store → /home/aburnazy/.openclaw/agents/main/sessions/sessions.json │
   │ Canonicalized 1 legacy session key(s) │
   ◇ Archive 2 orphan transcript file(s) in ~/.openclaw/agents/main/sessions?
   │ Yes
   5.Also tried deleting the messages chat

[stray osprey]

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

[deft crane]

Forgot to mention that telegram to chat works tried the command and it worked

openclaw message send --channel telegram --target <id> --message Hello

Also the same telegram chats from Dashboard UI perfectly work

[tulip matrix]

That “works after restart → replies to the whole backlog → goes silent again” pattern is almost always one of these:

1. the gateway is crashing / stuck (so Telegram updates pile up server-side), or
2. the Telegram long-poller stops due to a repeated network/API error (same effect), or
3. something else is also polling the same bot token (Telegram will 409 one of them).

To get signal fast, can you paste the output of these at the moment it’s “unresponsive” (they redact secrets; safe to share):

openclaw --version
openclaw status --all
openclaw gateway status
openclaw channels status --probe

And then grab the last errors from logs:

If you installed the systemd user service (WSL2)

journalctl --user -u openclaw-gateway.service -n 200 --no-pager

Plus: tail logs while reproducing

Run this in one terminal:

openclaw logs --follow

Then send a DM to the bot and watch what happens right when it “goes silent”.

What to look for in the logs

• Telegram getUpdates failures like fetch failed, timeouts, TLS/DNS errors.
• 409 Conflict-style messages (usually means another process/webhook is active for the same bot token).
• A run that starts but never finishes (model call hanging), which can block the per-chat queue.

If you paste those outputs/log lines, we can usually pinpoint which bucket you’re in and the exact fix (WSL2 has a couple common DNS/IPv6 gotchas, but I’d rather not guess without seeing the failure signature).

Nice—if openclaw message send … works (and Dashboard → Telegram send works), then:

• your bot token + outbound Telegram API are fine
• the problem is almost certainly inbound polling/runner (OpenClaw not receiving updates consistently), not “the agent forgot how to reply”

Next step is to catch why the Telegram poller stops.

1) When it’s “unresponsive”, run and paste

openclaw --version
openclaw channels status --probe
openclaw gateway status
openclaw status --all

2) Tail logs and reproduce once

In one terminal:

openclaw logs --follow

Then DM the bot “ping” from Telegram and watch the logs.

What we’re hunting for in the log tail:

• network/poll errors like fetch failed, timeouts, TLS/DNS issues to api.telegram.org
• 409 Conflict (usually means something else is consuming updates, or webhook vs polling conflict)
• the Telegram runner exiting / restarting in a loop

3) Two very common root causes (WSL2-specific)

If logs show fetch failed / intermittent Telegram API failures, WSL2 often has flaky IPv6/DNS. A good “try this” mitigation is forcing IPv4-first behavior for Telegram:

In ~/.openclaw/openclaw.json (JSON5), add:

{

  channels: {
    telegram: {
      network: {
        autoSelectFamily: false,
        dnsResultOrder: "ipv4first",
      },
    },
  },
}

Then restart the gateway.

But before changing anything, paste the outputs/log snippet—those usually make it immediately obvious which case you’re in.

[deft crane]

1. When it’s “unresponsive”, run and paste
   openclaw --version
   openclaw channels status --probe
   openclaw gateway status
   openclaw status --all

here's the summary of the commands I ran
OpenClaw status summary

• Version: 2026.3.2
• OS: WSL2 Linux
• Node: 22.22.0
• Config: ~/.openclaw/openclaw.json

Telegram

• Enabled / configured / running
• Mode: polling
• Bot: @marta_clawd_bot
• Probe: works

Gateway

• Running as systemd service
• Listening on 127.0.0.1:18789
• RPC probe: ok
• Dashboard: http://127.0.0.1:18789/
• Bind: loopback only (local clients only)

Agents

• 3 total
• 1 active
• 1 bootstrapping
• 10 sessions
• main present / active
• codex bootstrap absent
• gemini bootstrap absent

Noted issues

• Gateway service config looks outdated / non-standard
• Service uses Node from nvm, which may break after upgrades
• System-wide Node 22+ not found for migration away from version managers
• Port 18789 already in use by the running openclaw-gateway service
• Tailscale: off / not installed

Suggested next step

• Run: openclaw doctor
• Or auto-fix: openclaw doctor --repair

[tulip matrix]

Good data point: if CLI openclaw message send … and Dashboard → Telegram send both work even while “the bot is silent”, then Telegram outbound is healthy. So we can ignore bot token / Telegram API send issues and focus on inbound polling + run execution.

From your openclaw status summary, two things stand out:

1. Telegram: “polling / running / probe works”
2. Gateway systemd service config looks outdated + uses Node from nvm

A) Fix the “outdated systemd + nvm” warning first (it’s a real footgun on WSL2)

Systemd services often don’t play nicely with nvm over time (PATH changes, node path moves, restarts come up in a weird env). Since status explicitly flags it, I’d do:

openclaw doctor --repair
openclaw gateway restart

Then re-check:

openclaw gateway status
openclaw channels status --probe

B) If it still goes silent: we need the log lines when it happens

Please run this and leave it open:

openclaw logs --follow --json --limit 500

Then DM the bot “ping” from Telegram and paste the first suspicious block around the time it stops responding.

What we’re looking for in the logs is one of these signatures:

• inbound updates are not arriving (poll loop died / stuck)

• inbound updates arrive, but are dropped (auth/allowlist/mention gating will log a reason)
• inbound updates arrive, run starts, but the LLM call hangs/fails (you’ll see model errors / retries)

If you paste that snippet, we can tell which branch it is and give a concrete fix (WSL2 DNS/IPv6 and “another process polling the same bot” are common, but the logs make it obvious).

[deft crane]

A) unistalled nvm installed node 22.22 from source, warning went away
Issue still persists - the bot comes online after restart but after sending a bunch of messages for old questions goes silent
B) The logs dont show updates when I send a message to my telegram

[tulip matrix]

If you DM the bot and literally nothing new appears in logs, that’s a strong hint that OpenClaw is not receiving Telegram updates at all (not “receiving but refusing to answer”).

Given it does catch up right after a restart, the two most common causes are:

1. Telegram webhook or a second poller steals updates (another app/process using the same bot token), or
2. the Telegram polling loop is erroring out but the errors aren’t in the file log you’re watching (often only visible in systemd journal).

1) Check webhook / “someone else owns updates”

Run and paste the Telegram section:

openclaw channels capabilities --channel telegram

That probe includes webhook info. If it shows a webhook set, polling will eventually stop working.

You can also check directly with Telegram (run locally; don’t paste your token):

curl -sS "https://api.telegram.org/bot$TELEGRAM_BOT_TOKEN/getWebhookInfo"

If url is non-empty, clear it:

curl -sS "https://api.telegram.org/bot$TELEGRAM_BOT_TOKEN/deleteWebhook?drop_pending_updates=false"

Then restart the gateway and test again.

Also: double-check you don’t have any other service running with the same bot token (another OpenClaw profile, a test script, a different bot framework, etc.). Telegram only allows one “update consumer” at a time.

2) Watch the service logs (often where the polling errors are)

While the bot is “silent”, run:

journalctl --user -u openclaw-gateway.service -f

Then DM the bot. If polling is failing (409 conflict, fetch failed, DNS/TLS), it’ll usually show up here even if openclaw logs --follow stays quiet.

Quick clarifier

When you say “logs don’t show updates”, is that:

• openclaw logs --follow --json … (file logs over RPC), or
• journalctl … (systemd logs)?

If you tell me which one is quiet (or paste 20–30 lines around the silent period), I can point you to the exact failure signature.

[deft crane]

what does this mean?

aburnazy@DESKTOP-C7KGS5K:~$ openclaw channels capabilities --channel telegram

🦞 OpenClaw 2026.3.2 (85377a2) — If it works, it's automation; if it breaks, it's a "learning opportunity."

Telegram default
Support: chatTypes=direct,group,channel,thread polls reactions threads media nativeCommands blockStreaming
Actions: send, broadcast, react, delete, edit, topic-create
Bot: @marta_clawd_bot (8598849032)
Flags: joinGroups=true readAllGroupMessages=true inlineQueries=false
aburnazy@DESKTOP-C7KGS5K:~$

[tulip matrix]

That output is just a capabilities / probe report for your Telegram bot account. It means:

• OpenClaw can talk to Telegram’s API with that token (it can fetch bot info)
• Telegram reports some bot-side flags:
  • joinGroups=true → the bot is allowed to be added to groups
  • readAllGroupMessages=true → privacy mode is not restricting group visibility (good)
  • inlineQueries=false → inline mode not enabled (irrelevant here)
• The Support: line is OpenClaw’s feature support list for Telegram (DMs, groups, threads, reactions, media, etc.)
• It does not prove inbound updates are currently flowing, only that the bot/token is valid and reachable.

Since your actual symptom is “after a while it stops receiving new messages”, the next 2 checks are:

1) Confirm no webhook is set (webhook steals updates from polling)

Run this locally (don’t paste the token; paste the output):

curl -sS "https://api.telegram.org/bot$TELEGRAM_BOT_TOKEN/getWebhookInfo"

If it prints a non-empty "url": "https://..." then that’s the smoking gun: Telegram will deliver updates to that webhook instead of your polling bot.

2) Watch the systemd journal while you send a DM

openclaw logs --follow tails the gateway file log, but Telegram polling errors often show up in the service output. Do:

journalctl --user -u openclaw-gateway.service -f

Then DM the bot “ping” and see if you get errors like getUpdates failures, 409 Conflict, fetch failed, DNS/TLS issues, etc.

Paste:

• the getWebhookInfo output, and

• ~20 lines from journalctl around when you send a message and it doesn’t show up

…and we can pin down whether this is webhook conflict, a second poller, or a WSL2 network/DNS issue.

[deft crane]

aburnazy@DESKTOP-C7KGS5K:~/.openclaw$ curl -sS "https://api.telegram.org/bot$TELEGRAM_BOT_TOKEN/getWebhookInfo" | jq
{
"ok": true,
"result": {
"url": "",
"has_custom_certificate": false,
"pending_update_count": 64,
"allowed_updates": [
"message",
"edited_message",
"channel_post",
"edited_channel_post",
"inline_query",
"chosen_inline_result",
"callback_query",
"shipping_query",
"pre_checkout_query",
"poll",
"poll_answer",
"my_chat_member",
"chat_join_request",
"chat_boost",
"removed_chat_boost",
"message_reaction",
"business_connection",
"business_message",
"edited_business_message",
"deleted_business_messages",
"purchased_paid_media"
]
}
}

[tulip matrix]

That getWebhookInfo output is the biggest clue yet:

• "url": "" → no webhook is set (so polling should work)
• "pending_update_count": 64 → Telegram currently has 64 updates queued up waiting to be consumed via getUpdates

So right now OpenClaw is not draining updates (either it’s not polling anymore, or it’s stuck processing one update and never advances the offset).

0) First sanity check: are we querying the same bot token OpenClaw uses?

Run (and compare to what OpenClaw printed earlier: @marta_clawd_bot (8598849032)):

curl -sS "https://api.telegram.org/bot$TELEGRAM_BOT_TOKEN/getMe" | jq '.result.username, .result.id'

If it doesn’t match, your $TELEGRAM_BOT_TOKEN env var is pointing at a different bot than the one OpenClaw is running.

1) Grab the smoking gun from the gateway service logs

This usually shows the real error (409 conflict, fetch failed, crash while handling an update, etc.):

journalctl --user -u openclaw-gateway.service -n 300 --no-pager

Paste the part around any telegram, getUpdates, grammy, fetch failed, 409, stack trace, etc.

2) Quick “unstick” + diagnosis: inspect the next pending update

If you want to see what kind of update is blocking things, do this with the gateway stopped (to avoid getUpdates conflicts):

openclaw gateway stop
curl -sS "https://api.telegram.org/bot$TELEGRAM_BOT_TOKEN/getUpdates?limit=5" | jq '.result[] | {update_id, keys: (keys)}'

That will show what update types are queued (message, reaction, chat_member, boost, etc.). If there’s some weird update type that’s crashing the runner, it’ll show up here.

Then restart:

openclaw gateway start

Important: Telegram starts dropping old updates once the queue gets too large (you’re already at 64), so it’s worth grabbing the journal output soon.

If you paste:

1. getMe output (username/id), and
2. the journalctl … -n 300 tail,
   we can usually pinpoint the exact failure (and if it’s a new update type crash, that’s GitHub-issue-worthy with a minimal repro).

[deft crane]

1. here's the last logs (i've sent a few messages to DM chat in that while)
   aburnazy@DESKTOP-C7KGS5K:~/.openclaw$ journalctl --user -u openclaw-gateway.service -f
   Mar 05 11:52:18 DESKTOP-C7KGS5K node[635878]: 2026-03-05T07:52:18.107Z [telegram] sendMessage ok chat=392191801 message=1965
   Mar 05 11:52:23 DESKTOP-C7KGS5K node[635878]: 2026-03-05T07:52:23.924Z [telegram] sendMessage ok chat=392191801 message=1966
   Mar 05 11:52:27 DESKTOP-C7KGS5K node[635878]: 2026-03-05T11:52:27.398+04:00 [hooks/session-memory] Session context saved to ~/.openclaw/workspace/memory/2026-03-05-greetings.md
   Mar 05 11:52:40 DESKTOP-C7KGS5K node[635878]: 2026-03-05T07:52:40.983Z [telegram] sendMessage ok chat=392191801 message=1968
   Mar 05 11:52:43 DESKTOP-C7KGS5K node[635878]: 2026-03-05T07:52:43.768Z [telegram] sendMessage ok chat=392191801 message=1969
   Mar 05 11:52:48 DESKTOP-C7KGS5K node[635878]: 2026-03-05T07:52:48.907Z [telegram] sendMessage ok chat=392191801 message=1970
   Mar 05 11:53:15 DESKTOP-C7KGS5K node[635878]: 2026-03-05T07:53:15.144Z [ws] ⇄ res ✓ chat.history 50ms conn=44b851ed…c208 id=839930ab…9699
   Mar 05 11:55:02 DESKTOP-C7KGS5K node[635878]: 2026-03-05T07:55:02.356Z [ws] ⇄ res ✓ logs.tail 52ms conn=44b851ed…c208 id=5f1d9abc…9e80
   Mar 05 11:59:37 DESKTOP-C7KGS5K node[635878]: 2026-03-05T07:59:37.349Z [ws] ⇄ res ✓ node.list 52ms conn=44b851ed…c208 id=f6c92233…86d2
   Mar 05 12:02:34 DESKTOP-C7KGS5K node[635878]: 2026-03-05T08:02:34.353Z [ws] ⇄ res ✓ status 73ms conn=44b851ed…c208 id=95894c7d…2644

2. sanity check, yes we are sane
   curl -sS "https://api.telegram.org/bot$TELEGRAM_BOT_TOKEN/getMe" | jq '.result.username, .result.id'

3. telegram:
   Mar 05 11:52:40 DESKTOP-C7KGS5K node[635878]: 2026-03-05T07:52:40.983Z [telegram] sendMessage ok chat=392191801 message=1968
   Mar 05 11:52:43 DESKTOP-C7KGS5K node[635878]: 2026-03-05T07:52:43.768Z [telegram] sendMessage ok chat=392191801 message=1969
   Mar 05 11:52:48 DESKTOP-C7KGS5K node[635878]: 2026-03-05T07:52:48.907Z [telegram] sendMessage ok chat=392191801 message=1970
   Mar 05 11:53:15 DESKTOP-C7KGS5K node[635878]: 2026-03-05T07:53:15.144Z [ws] ⇄ res ✓ chat.history 50ms conn=44b851ed…c208 id=839930ab…9699
   Mar 05 11:55:02 DESKTOP-C7KGS5K node[635878]: 2026-03-05T07:55:02.356Z [ws] ⇄ res ✓ logs.tail 52ms conn=44b851ed…c208 id=5f1d9abc…9e80
   Mar 05 11:59:37 DESKTOP-C7KGS5K node[635878]: 2026-03-05T07:59:37.349Z [ws] ⇄ res ✓ node.list 52ms conn=44b851ed…c208 id=f6c92233…86d2
   Mar 05 12:02:34 DESKTOP-C7KGS5K node[635878]: 2026-03-05T08:02:34.353Z [ws] ⇄ res ✓ status 73ms conn=44b851ed…c208 id=95894c7d…2644
   Mar 05 12:21:36 DESKTOP-C7KGS5K node[635878]: 2026-03-05T08:21:36.774Z [health-monitor] [telegram:default] health-monitor: restarting (reason: stale-socket)

others empty:
aburnazy@DESKTOP-C7KGS5K:~/.openclaw$ journalctl --user -u openclaw-gateway.service -n 300 --no-pager | grep -C 3 getUpdates
aburnazy@DESKTOP-C7KGS5K:~/.openclaw$ journalctl --user -u openclaw-gateway.service -n 300 --no-pager | grep -C 3 gramm
aburnazy@DESKTOP-C7KGS5K:~/.openclaw$ journalctl --user -u openclaw-gateway.service -n 300 --no-pager | grep -C 3 "fetch\sfailed"
aburnazy@DESKTOP-C7KGS5K:~/.openclaw$ journalctl --user -u openclaw-gateway.service -n 300 --no-pager | grep -C 3 409
aburnazy@DESKTOP-C7KGS5K:~/.openclaw$

4. pending updates
   openclaw gateway stop
   curl -sS "https://api.telegram.org/bot$TELEGRAM_BOT_TOKEN/getUpdates?limit=5" | jq '.result[] | {update_id, keys: (keys)}'

[tulip matrix]

This is super helpful. Two key observations:

1. Your journal tail shows only outbound Telegram sends ([telegram] sendMessage ok …).
2. Telegram itself says there are 64 pending updates waiting to be consumed (pending_update_count: 64).

That means: Telegram is holding messages for your bot, but OpenClaw is not draining them via getUpdates (or it’s stuck before it can advance the offset).

Next: we need to know why polling is stuck

1) Grab a bigger slice of the service logs (the error is usually earlier)

-f only shows new lines; the actual failure often happened minutes ago. Please run:

journalctl --user -u openclaw-gateway.service -n 500 --no-pager

Then search inside that output for any of these (even one line helps):

• getUpdates
• 409
• Conflict
• 429
• Too Many Requests
• fetch failed
• telegram

If you want a quick filter:

journalctl --user -u openclaw-gateway.service -n 500 --no-pager | grep -iE "telegram|getupdates|conflict|429|too many|fetch failed|error|exception"

2) Check whether OpenClaw is blocked on a “bad” pending update (safe test)

Stop the gateway briefly so there’s no getUpdates conflict:

openclaw gateway stop
curl -sS "https://api.telegram.org/bot$TELEGRAM_BOT_TOKEN/getUpdates?limit=5" \
  | jq '.result[] | {update_id, kind: (keys - ["update_id"])[0]}'

• If this prints updates → OpenClaw truly wasn’t consuming them.
• If this returns a 409 Conflict even though OpenClaw is stopped → something else on your machine/network is polling the same bot token.

Then start again:

openclaw gateway start

Optional but pragmatic: clear the backlog to avoid “restart spam → silent”

Right now you have 64 queued updates, which can cause a burst of replies on restart (and potentially trigger rate limits / long backoffs). If you’re OK dropping the backlog and just want it responsive again:

curl -sS "https://api.telegram.org/bot$TELEGRAM_BOT_TOKEN/deleteWebhook?drop_pending_updates=true" | jq

(Despite the name, it also drops the pending update queue even when webhook is empty.)

If you paste:

• the filtered journalctl output, and
• the {update_id, kind} list from getUpdates (no message text needed),
  we can narrow it to: rate-limit backoff, crash on a specific update type, or a second poller.

That last line is very telling:

[health-monitor] [telegram:default] health-monitor: restarting (reason: stale-socket)

So OpenClaw itself thinks Telegram polling has entered the “zombie long‑poll” state (socket looks alive, but no inbound data flows), and it’s trying to restart the Telegram runner.

Combined with pending_update_count: 64, we know Telegram has plenty of updates waiting — OpenClaw just isn’t successfully draining them.

Missing piece: what did getUpdates return after openclaw gateway stop?

You ran:

openclaw gateway stop
curl -sS "https://api.telegram.org/bot$TELEGRAM_BOT_TOKEN/getUpdates?limit=5" \

 | jq '.result[] | {update_id, keys: (keys)}'

Can you paste the output of that command?

Two important interpretations:

• If it prints updates (you’ll see keys like ["update_id","message"]) → OpenClaw really is not consuming them.
• If it returns an error 409 Conflict even though the gateway is stopped → something else is polling that token or the gateway didn’t actually stop cleanly and a zombie poller is still alive.

Quick check for the “still polling even after stop” case

Right after openclaw gateway stop, run:

pgrep -af openclaw || true

pgrep -af "node.*openclaw" || true

If you still see a gateway process, that would explain the “stale-socket restart doesn’t recover” behavior.

If you just want it responsive now

Since the backlog burst on restart is likely making things worse, you can drop the queued updates and start fresh:

curl -sS "https://api.telegram.org/bot$TELEGRAM_BOT_TOKEN/deleteWebhook?drop_pending_updates=true" | jq
openclaw gateway start

(You’ll lose those 64 queued messages, but it prevents the “reply to a ton of old stuff → stall again” loop.)

Once you paste the getUpdates {update_id, keys} output, we can decide whether this is:

• a zombie poller that won’t die cleanly on WSL2, or
• a Telegram runner bug where it stops calling getUpdates after some condition (which is likely GitHub-issue territory, and your stale-socket log line is exactly the breadcrumb maintainers need).

[deft crane]

For everyone's benefit my issue has been resolved by this single cakk that dropped messages from telegram side.

Thanks @tulip matrix

curl -sS "https://api.telegram.org/bot$TELEGRAM_BOT_TOKEN/deleteWebhook?drop_pending_updates=true" | jq

[tulip matrix]

Yep — that did it because Telegram had a big backlog (pending_update_count), and the gateway was effectively stuck in the “catch up on ancient updates → stall again” loop.

deleteWebhook?drop_pending_updates=true clears Telegram’s pending update queue even when url is empty, so the bot can start fresh and respond to new messages normally. Tradeoff: it drops those queued messages (which in your case was exactly what you wanted).

Glad you posted the fix back. If this solved it, please right‑click the solution message → Apps → ✅ Mark Solution so Answer Overflow indexes it for the next person.