Bug description

Telegram private chat topics started failing today after Telegram Bot API 10.0. Hermes receives incoming messages with a topic/thread id, but outbound replies using message_thread_id are rejected by Telegram with Bad Request: message thread not found. Hermes then falls back to sending without a thread id, so replies land in the bot's main "All Messages" chat instead of the topic.

This appears to be a Telegram server-side regression, but the current Hermes fallback makes the user-visible behavior confusing because topic replies silently bypass the topic.

External signal

A screenshot of an X/Twitter post by Sergey Ryabov (@colriot) says:

If you use @openclaw with Telegram topics all agent replies will bypass your topics and land in the main chat instead.
Telegram Bot API 10.0 (released today) broke private chat topics.
Server-side regression, no fix on the client side.
Issue: tdlib/telegram-bot-api #847 sendMessage with message_thread_id fails for private chat...

The screenshot links to GitHub issue tdlib/telegram-bot-api#847.

Steps to reproduce

1. Enable Telegram private chat topics / threaded mode for a bot.
2. Send a message to the bot from a private chat topic.
3. Observe Hermes receives the message with a session key containing the topic id, e.g.:
   • agent:main:telegram:dm:962467459:38707
4. Hermes attempts to reply using that topic id.
5. Telegram rejects the outbound send with Bad Request: message thread not found.
6. Hermes retries without message_thread_id, causing the reply to land in the parent private chat / All Messages.

Observed logs

Examples from local gateway logs on 2026-05-08:

[Telegram] Flushing text batch agent:main:telegram:dm:962467459:38707 (... chars)
gateway.run: inbound message: platform=telegram user=Deep chat=962467459 msg='...'
gateway.platforms.base: [Telegram] Sending response (... chars) to 962467459
gateway.platforms.telegram: [Telegram] Thread 38707 not found, retrying without message_thread_id

Multiple private topic ids showed the same failure:

• Main bot Ops topic: 38707
• Main bot Daily topic: 38864
• Newly created test topics: 41096, 41099, 41113, 41130
• Separate Keeper bot/profile fresh topic: 41175

The separate Keeper bot reproducing this rules out a stale topic id specific to one bot/profile.

Raw Telegram Bot API tests

Using the same bot token and chat id, raw API calls produced:

Main bot, private topic 38707

sendMessage(chat_id=..., message_thread_id=38707)
=> {"ok": false, "error_code": 400, "description": "Bad Request: message thread not found"}

Testing Telegram's private-topic field:

sendMessage(chat_id=..., direct_messages_topic_id=38707)
=> {"ok": true, ...}

Keeper bot, private topic 41175

sendMessage(chat_id=..., message_thread_id=41175)
=> {"ok": false, "error_code": 400, "description": "Bad Request: message thread not found"}

sendMessage(chat_id=..., direct_messages_topic_id=41175)
=> {"ok": true, ...}

So message_thread_id currently fails for private bot topics while direct_messages_topic_id works in raw API tests.

Expected behavior

Hermes replies should stay in the same Telegram private topic when possible.

If Telegram rejects the topic routing because of an upstream Bot API regression, Hermes should probably avoid silently falling back to the main private chat for private-topic conversations. A visible send failure is less confusing than replies leaking into All Messages.

Actual behavior

Hermes receives private-topic messages with a topic id, but outbound replies fail with message thread not found and are retried without a thread id, landing in All Messages.

Environment

• Hermes repo: NousResearch/hermes-agent
• Local commit tested: a58ee035a (Merge remote-tracking branch 'origin/main' into local/deep-deploy-supermemory-vcf)
• Platform: macOS gateway, Telegram polling mode
• Telegram Bot API: issue appears after Bot API 10.0 release on 2026-05-08
• Both a main bot and a separate Keeper bot/profile reproduce the behavior

Suggested handling

Given the apparent upstream regression:

1. Track tdlib/telegram-bot-api#847.
2. For private chats, consider sending via direct_messages_topic_id when available instead of message_thread_id.
3. If a private topic send fails, consider not falling back to All Messages automatically. Log a clear error and fail visibly, because silent fallback breaks topic isolation.
4. Keep the existing forum/supergroup message_thread_id behavior separate from private chat topic behavior.