Summary

On my local OpenClaw setup, the Telegram bot becomes unresponsive after running for a while. The behavior looks like a combination of:

• the main Telegram session growing until it hits context overflow,
• long-running child processes staying attached to the gateway,
• Telegram polling/send operations intermittently failing and not recovering cleanly.

This eventually results in the bot no longer replying in Telegram until I manually intervene.

Version / Environment

• OpenClaw: 2026.4.15 (041266a)
• Install source: global npm package [email protected]
• OS: Linux ser160761344703 5.15.0-173-generic #183-Ubuntu SMP Fri Mar 6 13:29:34 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux
• Channel: Telegram

Relevant config

Telegram channel config at the time of reproduction:

"channels": {
  "telegram": {
    "enabled": true,
    "dmPolicy": "pairing",
    "execApprovals": {
      "enabled": false
    },
    "allowFrom": ["182211955"],
    "groupPolicy": "allowlist",
    "streaming": {
      "mode": "partial"
    },
    "timeoutSeconds": 60,
    "network": {
      "autoSelectFamily": false,
      "dnsResultOrder": "ipv4first"
    }
  }
}

I had also increased concurrency from 1 to 2 to reduce blocking:

• acp.maxConcurrentSessions = 2
• agents.defaults.maxConcurrent = 2
• agents.defaults.subagents.maxConcurrent = 2

Observed behavior

After the bot runs for a while and handles more Telegram messages/tasks:

1. The main session continues reusing agent:main:main
2. The session eventually becomes very large and logs context overflow
3. Telegram polling starts stalling and restarting
4. Telegram send/edit API calls begin failing with network errors
5. From the user perspective, the bot just stops replying

Evidence

1. Main Telegram session hits context overflow

From /tmp/openclaw/openclaw-2026-04-18.log:

2026-04-18T09:07:47.220+00:00 [context-overflow-diag] sessionKey=agent:main:main provider=cliproxy/gpt-5.4 ... error=Context overflow: estimated context size exceeds safe threshold during tool loop.
2026-04-18T09:07:47.226+00:00 context overflow detected (attempt 1/3); attempting auto-compaction for cliproxy/gpt-5.4

The stored session file showed the main Telegram conversation reusing agent:main:main, and before recovery it had grown to roughly 295-325 messages.

2. Workspace bootstrap contributes significant context repeatedly

2026-04-18T09:07:48.201+00:00 workspace bootstrap file MEMORY.md is 34488 chars (limit 12000); truncating in injected context (sessionKey=agent:main:main)

This warning repeated many times for the same main session.

3. Telegram polling stalls and restart loop

2026-04-18T09:13:03.931+00:00 [telegram] Polling stall detected (no completed getUpdates for 95.72s); forcing restart.
2026-04-18T09:13:18.947+00:00 [telegram] Polling runner stop timed out after 15s; forcing restart cycle.
2026-04-18T09:13:18.958+00:00 Telegram polling runner stopped (polling stall detected); restarting in 2.1s.
2026-04-18T09:13:36.077+00:00 [telegram][diag] rebuilding transport for next polling cycle

4. Telegram reply operations then fail outright

2026-04-18T09:20:16.371+00:00 telegram editMessage failed: Network request for 'editMessageText' failed!
2026-04-18T09:20:23.354+00:00 telegram sendMessage failed: Network request for 'sendMessage' failed!
2026-04-18T09:20:23.360+00:00 telegram final reply failed: HttpError: Network request for 'sendMessage' failed!

These errors repeated several times in a row.

5. Gateway accumulated long-running child processes before recovery

Before I manually recovered it, systemctl --user status openclaw-gateway.service showed:

• gateway memory around 2.1G
• task count around 138
• a long-running register_bot.py child plus multiple Chrome child processes attached under openclaw-gateway

After killing the stuck browser/capture child processes and restarting the gateway, memory dropped back to ~289M and the task count returned to normal.

Recovery I had to do manually

To recover, I had to:

1. kill the stuck long-running browser/capture child processes
2. detach/reset the bloated agent:main:main session from the session store
3. restart openclaw-gateway.service

After that, the gateway returned to a healthy memory/task count and Telegram could start fresh again.

Expected behavior

• Long-running Telegram usage should not permanently poison the shared agent:main:main session.
• If a Telegram-linked session grows too large, I would expect a safer fallback such as automatic session rotation/new session creation.
• Polling/send failures should recover more robustly without ending in a permanently silent bot.
• Long-running child processes should not be able to leave the Telegram channel effectively unusable.

Suspected areas

Not sure where the root fix belongs, but likely related to one or more of:

• Telegram session reuse policy for direct chats (agent:main:main growing indefinitely)
• context-overflow recovery not strong enough for channel-bound long-lived sessions
• Telegram polling transport recovery after repeated network failures
• cleanup/isolation of long-running child processes triggered from Telegram conversations

If useful, I can provide more local logs or the affected session metadata, but the snippets above were the key signals I observed while diagnosing and recovering the issue locally.