Description

When a session with a Telegram-style key (e.g. agent:main:telegram:group:-5166572823) is first created via the chat.send gateway RPC (not from an actual Telegram message), the session entry stores:

{
  "lastChannel": "webchat",
  "deliveryContext": { "channel": "webchat" },
  "origin": { "provider": "webchat", "surface": "webchat", "chatType": "direct" }
}

This means any agent reply is silently delivered to the webchat channel only. Since there is no webchat client listening, the reply is effectively dropped — it never reaches the Telegram group that the session key implies.

Expected Behavior

When chat.send targets a session key like agent:main:telegram:group:-5166572823, the reply should be delivered to Telegram chat -5166572823. The session key itself contains the routing information (channel=telegram, chatId=-5166572823).

Possible fix approaches:

1. Parse the session key to extract channel + chatId when lastChannel is webchat or unset
2. Have chat.send set lastChannel/lastTo based on the session key when the session has no prior channel info
3. Allow callers to pass deliveryChannel/deliveryTo in the chat.send params to explicitly specify where replies should go

Reproduction Steps

1. Configure a Telegram session key in OpenClaw (e.g. via a Telegram group)
2. Send a message to that session ONLY via chat.send (never send a real Telegram message to that group first)
3. Observe the session store entry has lastChannel: "webchat"
4. Send a chat.send message to that session:

   openclaw gateway call chat.send --params '{"message": "tell me a joke", "sessionKey": "agent:main:telegram:group:-5166572823", "idempotencyKey": "test-1"}' --json

5. Agent generates a reply but it never appears in the Telegram group

Workaround

Send at least one real Telegram message to the group first. This sets lastChannel: "telegram" and lastTo: "telegram:-5166572823" in the session entry, after which chat.send replies are correctly routed.

Environment

• OpenClaw version: latest (npm)
• Channel: Telegram
• OS: Ubuntu Linux

Use Case

This is particularly relevant for hardware integrations (e.g. smartwatch voice input via PTT) that use chat.send to inject messages into specific Telegram group sessions. The watch app allows users to switch between sessions, but sessions that were never messaged from Telegram directly have broken reply routing.