openclaw - 💡(How to fix) Fix [Bug]: Telegram forum topic names are not reliably included in agent context [2 pull requests]

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Telegram forum topic names are not reliably included in agent context, so agents can receive only a message_thread_id/topic id and block even when the topic title is the intended task context.

Steps to reproduce

1. Run OpenClaw 2026.5.19 with the Telegram provider connected to a forum-enabled Telegram supergroup and routed agent.
2. Use a forum topic whose title is needed as workflow context.
3. Send a topic-scoped native command or routed request that relies on the current Telegram topic title, without also typing the issue number or branch/topic name in the message body.
4. Inspect the resulting agent session/trajectory.

Observed local evidence, with project-specific identifiers intentionally redacted:

• OpenClaw version: OpenClaw 2026.5.19 (a185ca2).
• The session key shape included a Telegram group topic id.
• The agent trajectory trusted metadata for that turn included Telegram channel/provider/chat type but no topic_name.
• The agent replied that OpenClaw only provided the Telegram topic id, not the topic title, so it could not safely infer the intended issue/branch.
• The local topic-name cache had a matching title for the same redacted group/topic key.

Expected behavior

When OpenClaw has, creates, edits, or observes a Telegram forum topic title, agent turns in that topic should include both the topic id and topic name in trusted metadata before prompt construction. This should work for normal topic messages, native slash commands, and system/wakeup turns that reconstruct delivery context from session state.

Actual behavior

The agent can receive only the topic id/thread id, with no trusted topic_name, and then asks the user for an issue/branch/topic name even though the current Telegram topic title is the intended context.

OpenClaw version

2026.5.19 (a185ca2)

Operating system

Ubuntu 24.04

Install method

npm global under nvm, launched via systemd user service

Model

openai/gpt-5.5 (not model-specific)

Provider / routing chain

Telegram group topic -> OpenClaw gateway -> routed OpenClaw agent -> OpenAI provider

Additional provider/model setup details

The behavior is in Telegram channel metadata/session context before model execution. No provider-specific behavior is required to reproduce.

Logs, screenshots, and evidence

$ openclaw --version
OpenClaw 2026.5.19 (a185ca2)

Redacted local evidence:
- A Telegram forum-topic session had a topic-scoped session key.
- The agent-visible trusted metadata did not include topic_name.
- The agent response stated that only the Telegram topic id was available.
- The local topic-name cache had a matching title for the same redacted group/topic key.

Impact and severity

Affected: Telegram forum-topic users who use topic names as workflow context, especially issue/topic workflows.

Severity: Medium to high for mobile workflows. It blocks otherwise valid commands unless the user redundantly types the issue number or branch/topic name in the message body.

Frequency: Observed when the agent turn receives only the Telegram topic id in metadata, including native command/topic flows.

Consequence: Agents ask for clarification instead of starting the requested work, even though the Telegram topic title is the intended source of truth.

Additional information

This seems difficult to solve cleanly as an external plugin today because the available message hooks appear observational for this path; they do not provide a supported way to mutate trusted inbound context before prompt construction.

A robust core fix would likely:

• persist topic names from Telegram forum_topic_created and forum_topic_edited service messages;
• persist topic names immediately after successful createForumTopic and editForumTopic actions;
• resolve cached topic names into TopicName for normal inbound messages, native slash commands, and system/wakeup turns;
• include tests that verify topic_name survives all three paths.