Description

Telegram DM replies intermittently fail to deliver because OpenClaw caches lastThreadId from incoming messages in the session store, then includes message_thread_id when sending replies. Telegram rejects these with "message thread not found".

Context

• This is a 1:1 DM with a bot (not a group/forum)
• The bot chat does NOT have Topics enabled (it's a regular DM — no option to enable/disable Topics)
• Yet incoming messages from Telegram carry a message_thread_id field
• OpenClaw caches this as lastThreadId in sessions.json
• Subsequent replies include message_thread_id → Telegram API rejects them

Relation to #11620

The fix in #11620 ("recover proactive sends when stale topic thread IDs are used by retrying without message_thread_id") only covers proactive sends (cron announces, sub-agent results). It does NOT cover normal session replies in the main DM session.

Steps to Reproduce

1. Set up a Telegram bot DM
2. Send messages — observe lastThreadId appearing in sessions.json under the main session
3. Some replies will fail to deliver to Telegram (visible in OpenClaw web dashboard but never arrive in Telegram)
4. Manually deleting lastThreadId from sessions.json + gateway restart temporarily fixes it, but it gets re-cached from the next incoming message

Observed Session Store

{
  "agent:main:main": {
    "lastThreadId": 1651,
    "lastTo": "telegram:911251122",
    "lastChannel": "telegram"
  }
}

Expected Behavior

• For 1:1 bot DMs, message_thread_id from incoming messages should NOT be cached/used for replies
• OR the retry-without-threadId logic from [Bug]: Telegram message tool fails with "message thread not found" after Topics/Forum mode was toggled #11620 should also apply to regular session replies, not just proactive sends

Environment

• OpenClaw: 2026.2.9
• Telegram Bot API
• Chat type: private (1:1 DM with bot)

Workaround

Manually delete lastThreadId from sessions.json and restart gateway. But it gets re-cached from the next incoming message.