Summary

In Telegram group/forum-topic sessions, the default messages.groupChat.visibleReplies = "message_tool" makes normal final replies private and requires the agent to use message(action=send) for visible room output. That is fine in principle, but the message tool currently rejects valid numeric Telegram group/topic targets that the CLI accepts, so an agent can produce a correct answer but fail to deliver it visibly.

Environment

• OpenClaw: 2026.5.2 (8b2a6e5)
• Channel: Telegram group forum topic
• Source session key shape: agent:main:telegram:group:-1003577364307:topic:1189
• Session delivery context stored:
  • channel: "telegram"
  • to: "telegram:-1003577364307"
  • threadId: 1189
  • accountId: "default"

What happened

A group topic turn completed successfully and the final assistant text existed in the transcript, but it was not posted to the Telegram topic because group visible replies defaulted to message_tool_only.

The agent then tried to use the message tool to send to the same topic. Repeated attempts failed with target parsing errors, for example:

Unknown target "telegram:-1003577364307" for Telegram. Hint: <chatId>
Unknown target "-1003577364307:1189" for Telegram. Hint: <chatId>
Unknown target "-1003577364307" for Telegram. Hint: <chatId>
Unknown target "-1003577364307:topic:1189" for Telegram. Hint: <chatId>

One later attempt accidentally used the absolute numeric value without Telegram's negative group prefix and hit Telegram API directly:

Telegram send failed: chat not found (chat_id=1003577364307)
Call to 'sendMessage' failed! (400: Bad Request: chat not found)

Reproduction / contrast

The CLI dry-run accepts the expected Telegram topic forms:

openclaw message send --channel telegram --target='-1003577364307:topic:1189' --message 'dry-run route test' --dry-run --json

Result:

{
  "action": "send",
  "channel": "telegram",
  "dryRun": true,
  "handledBy": "core",
  "payload": {
    "channel": "telegram",
    "to": "telegram:-1003577364307:topic:1189",
    "via": "direct",
    "mediaUrl": null,
    "dryRun": true
  }
}

But the agent message tool with equivalent args fails before delivery:

{
  "action": "send",
  "channel": "telegram",
  "accountId": "default",
  "target": "-1003577364307:topic:1189",
  "message": "dry-run route test",
  "dryRun": true
}

Result:

Unknown target "-1003577364307:topic:1189" for Telegram. Hint: <chatId>

Also fails with separate threadId:

{
  "action": "send",
  "channel": "telegram",
  "accountId": "default",
  "target": "-1003577364307",
  "threadId": "1189",
  "message": "dry-run route test",
  "dryRun": true
}

Why this is surprising

Docs say group/channel rooms default to messages.groupChat.visibleReplies: "message_tool", requiring message(action=send) for room output. That default only works safely if the message tool can address the current source room/topic reliably.

Right now there appears to be a mismatch between CLI target normalization and the agent message tool's target resolver for Telegram numeric group/topic ids.

Expected behavior

Either:

1. The agent message tool should accept the same Telegram target forms as openclaw message send, including:
   • target: "-1001234567890" + threadId: "42"
   • target: "-1001234567890:topic:42"
   • possibly normalized telegram:-1001234567890 when it comes from session delivery context

or:

2. When a source turn is already in a Telegram group topic and group visible replies are message_tool, the runtime should provide a robust current-room/current-topic send target abstraction so the model does not have to guess Telegram target syntax.

Impact

With the current default, a normal group-topic answer can be generated but not delivered. The model then tends to try multiple target spellings, causing noisy failures and increasing the risk of accidentally dropping the -100 group prefix and sending to a wrong/nonexistent chat id.