openclaw - 💡(How to fix) Fix Telegram forum topic replies can jump to General/wrong topic despite topic-qualified session

Summary

Telegram forum topic replies can still be delivered to the forum group's General topic / wrong topic even though inbound routing is topic-aware and the session key includes the correct :topic:<id> suffix.

This affects multiple Telegram forum groups/topics. The model run is started under the correct topic-qualified session key, but the visible Telegram reply may appear outside that topic, causing the conversation to jump to General / lose context.

Environment

• OpenClaw: 2026.5.7 (eeef486)
• Runtime: macOS / LaunchAgent gateway
• Channel: Telegram group/supergroup forum topics
• Gateway config path: ~/.openclaw/openclaw.json

Config attempted

Relevant Telegram config is explicitly topic-aware and also uses reply threading as a fallback:

channels: {
  telegram: {
    replyToMode: "all",
    threadBindings: { spawnSessions: false },
    groups: {
      "<forum-group-a>": {
        groupPolicy: "open",
        requireMention: false,
        topics: {
          "36": { agentId: "agent-a", requireMention: false },
          "854": { agentId: "agent-a", requireMention: false }
        }
      },
      "<forum-group-b>": {
        groupPolicy: "open",
        requireMention: false,
        topics: {
          "1": { agentId: "agent-b", requireMention: false },
          "74": { agentId: "agent-c", requireMention: false }
        }
      },
      "<forum-group-c>": {
        groupPolicy: "open",
        requireMention: false,
        topics: {
          "35": { agentId: "agent-a", requireMention: false },
          "90": { agentId: "agent-c", requireMention: false }
        }
      }
    }
  }
}

I also tried adding missing topic entries and disabling channels.telegram.threadBindings.spawnSessions; this did not stop replies from jumping topics.

Evidence from logs

The gateway correctly sees topic-qualified sessions, for example:

active=agent:agent-a:telegram:group:<forum-group-a>:topic:36(...)
active=agent:agent-c:telegram:group:<forum-group-b>:topic:74(...)

Recent log examples:

2026-05-14T19:54:26+02:00 work=[active=agent:agent-c:telegram:group:<forum-group-b>:topic:74(...)|agent:agent-a:telegram:group:<forum-group-a>:topic:36(...)]
2026-05-14T19:59:34+02:00 work=[active=agent:agent-a:telegram:group:<forum-group-a>:topic:36(...)]

Despite that, user-visible replies are reported in Telegram as appearing in General / another topic instead of the source topic.

replyToMode: "all" was added globally as a mitigation, but it still did not reliably keep replies in-topic.

Expected behavior

For Telegram forum/supergroup topics:

• if inbound message has message_thread_id = N, all assistant replies, stream previews/edits, typing, final sends, tool-result sends, and delivery fallbacks should target the same topic N;
• topic-qualified session keys (...:topic:N) should always imply message_thread_id: N on Telegram sends, except the documented General topic threadId=1 special case;
• replyToMode: "all" should not lose the topic placement.

Actual behavior

• The agent/session is topic-qualified correctly.
• Visible Telegram replies still sometimes appear in General / wrong topic across several forum groups/topics.
• Context then appears lost because the user continues in the topic while the bot has answered elsewhere.

Possible area to inspect

This looks like a send/delivery path issue rather than inbound routing:

• final assistant send may not always include message_thread_id even when session key is topic-qualified;
• stream preview/edit path may differ from final send path;
• reply fallback may not preserve forum topic when message_thread_id is absent;
• queued/deferred channel reloads may keep old Telegram runtime snapshots longer than expected, but the issue persisted after config changes were detected.

Related

This may be related to prior Telegram topic/threading work, but this report is specifically about group forum topics still jumping to General/wrong topics despite topic-qualified sessions and replyToMode: "all".