Bug Description

In Telegram supergroups, Hermes currently treats any inbound message_thread_id as a distinct session dimension. In practice, Telegram can attach message_thread_id to group messages even when operators did not explicitly create forum topics. This causes one logical group conversation to split into multiple gateway sessions unexpectedly.

The result is confusing behavior such as:

• /model changed in one visible group conversation but later messages execute in a different session
• collaborators in the same group cannot reliably continue each other's context
• a single group accumulates multiple session keys that look like separate threads even though users did not intentionally create topics

Why this is a problem

Current session key construction in gateway/session.py always appends thread_id for non-DM messages when present. That means Telegram's inbound message_thread_id becomes a hard session boundary even when the operator wants "one shared session per group".

For operators using Hermes as a collaborative group bot, this is surprising and breaks expected UX.

Evidence / Observed Behavior

In one Telegram supergroup, the same chat produced these session keys over time:

• agent:main:telegram:group:-1003952440142:5203187663
• agent:main:telegram:group:-1003952440142:8206193897
• agent:main:telegram:group:-1003952440142:46
• agent:main:telegram:group:-1003952440142:56
• agent:main:telegram:group:-1003952440142:80
• agent:main:telegram:group:-1003952440142:205

The :46, :56, :80, :205 entries are not user IDs. They came from inbound Telegram message_thread_id values stored as source.thread_id.

The corresponding session origins show examples like:

• user_id=8206193897, thread_id=56
• user_id=8206193897, thread_id=46
• user_id=5203187663, thread_id=80
• user_id=5203187663, thread_id=205

Notably, these session records had chat_topic: null, so this does not look like Hermes successfully mapping named configured topics. It looks like raw Telegram thread/message-thread identifiers being treated as session partitions.

Relevant Code Path

Telegram adapter:

• gateway/platforms/telegram.py
  • reads message.message_thread_id
  • stores it as source.thread_id

Session routing:

• gateway/session.py
  • build_session_key() always appends thread_id when present

Expected Behavior

Hermes should offer an explicit way to ignore Telegram group message_thread_id for session routing when operators want one shared session per parent group.

At minimum, there should be a config option along the lines of:

group_sessions_per_user: false
telegram_ignore_group_thread_id_for_sessions: true

or

group_threads_share_parent_session: true

so that all messages in the same Telegram group resolve to the parent group session, even if Telegram includes message_thread_id.

Actual Behavior

If Telegram includes message_thread_id, Hermes creates or routes to a separate session for that thread ID. This can happen even when users did not knowingly create topics, causing session fragmentation and model/session mismatch.

Suggested Solution

Any of these would help:

1. Add a config toggle to ignore thread_id for Telegram group session key construction.
2. Restrict thread-based session splitting to explicitly configured / known forum topics.
3. Add a fallback mode where group-level session routing wins unless the operator explicitly opts into per-thread sessions.

Version / Environment

Observed on:

• Hermes Agent v0.8.0 (2026.4.8)
• Telegram gateway
• Group/supergroup sessions

Additional Context

This is different from existing Telegram routing issues that are specifically about sending replies back into the right thread. The problem here is inbound session fragmentation: Telegram's message_thread_id becomes a session boundary too aggressively.