openclaw - 💡(How to fix) Fix Simplify: make channels.telegram.dm.threadReplies=auto by default (based on bot has_topics_enabled boolean) [2 pull requests]

Problem

SIMPLY: I installed fresh openclaw; connected to telegram bot; enabled DM topics in it; started talk to the bot - and after a while had to troubleshoot why the heck it stops execution??? Found out that its because threadReplies=off by default and when i type in other topic - it mixes up all the topics! Disappointment immediately from new user trying something new. Non-obvious behavior

DETAILED:

Telegram DM topic support is configured at the bot level, but OpenClaw currently asks operators to choose channels.telegram.dm.threadReplies behavior manually (off, inbound, or always).

That creates avoidable configuration complexity: the operator has to know whether this Telegram bot has DM topics enabled, then duplicate that state in OpenClaw config. In practice this is the same decision Telegram already exposes through the bot capability returned by getMe.

This is especially confusing because message_thread_id in private chats can mean two different things depending on bot topic support:

• for bots with topics enabled, it can represent intentional DM topic routing;
• for bots without topics enabled, it may be incidental reply/thread metadata that should not split the DM session.

OpenClaw should not require most users to reason about this distinction manually.

Proposed solution

Add auto as the default value for Telegram DM threadReplies.

Suggested semantics:

• If Telegram getMe.has_topics_enabled === true, treat DM message_thread_id / direct-message topic metadata as intentional topic routing and behave like inbound for session-key derivation.
• If getMe.has_topics_enabled is false or absent, treat incidental DM message_thread_id as reply metadata only and behave like off for session-key derivation.
• Existing explicit values off, inbound, and always remain supported as advanced overrides.

In other words, the normal user-facing setting becomes:

{
  "channels": {
    "telegram": {
      "dm": {
        "threadReplies": "auto"
      }
    }
  }
}

And auto should be the default when the field is omitted.

Why this is better

This removes an unnecessary user-facing decision. Telegram already knows whether the bot supports DM topics, and OpenClaw can follow that capability by default instead of asking users to mirror it in config.

It also keeps the conceptual model small:

• ordinary users get auto;
• explicit values remain available only for operators who need fixed behavior.

No new concepts like flat, explicit, or a separate DM topic/session mode are needed.

Non-goals

• Do not add new user-facing concepts like flat or explicit.
• Do not infer per-user topic settings; Telegram DM topic support is bot-level, not per-user.
• Do not change Telegram group/forum topic behavior.
• Do not remove existing explicit off, inbound, or always overrides.

Migration / compatibility

• Default channels.telegram.dm.threadReplies to auto.
• Existing configs with explicit off, inbound, or always keep their current behavior.
• Documentation should present auto as the normal/default choice and describe explicit values as overrides.

Acceptance criteria

1. Bot with getMe.has_topics_enabled=true: Telegram DM topic messages route to topic/thread sessions by default.
2. Bot with getMe.has_topics_enabled=false or no capability value: Telegram DM messages with incidental message_thread_id stay in the flat DM session by default.
3. Explicit channels.telegram.dm.threadReplies values still override auto.
4. Explicit channels.telegram.direct.<chatId>.threadReplies values still override the DM default.
5. Documentation explains auto as the default behavior and keeps off / inbound / always as advanced fixed-policy overrides.

Related context

• #75975 requested that incidental Telegram DM message_thread_id should not fragment ordinary 1:1 DM sessions.
• This proposal keeps that simplification while still supporting intentional DM topics for bots that have topic support enabled.