openclaw - 💡(How to fix) Fix [Bug]: `message(action=send)` without explicit `target` routes to web gateway instead of originating Telegram group chat

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

When an agent calls message(action=send) without an explicit target parameter during a session initiated from a Telegram group chat, the reply is silently routed to the web gateway Chat UI instead of back to the originating Telegram group. The inbound metadata correctly identifies the source as a Telegram group chat, but the outbound implicit target resolver does not use it. The bug is 100% reproducible in group chat sessions and does not occur in 1:1 DM sessions.

Steps to reproduce

1. Install OpenClaw 2026.5.12 via npm global on macOS.
2. Configure a Telegram bot with at least one group chat binding in openclaw.json:

   {
     "providers": {
       "telegram": {
         "token": "<BOT_TOKEN>",
         "bindings": [
           {
             "chatId": "<negative-group-chat-id>",
             "agents": ["main"],
             "requireMention": false,
             "dmPolicy": "pairing"
           }
         ]
       }
     }
   }

   No defaultTarget is configured anywhere (agent level or provider level).
3. Start the gateway. Confirm the Telegram binding loads and the bot is a member of the group.
4. Send a message to the agent from the Telegram group chat.
5. Confirm inbound metadata is correct in the session context:

   "chat_id": "telegram:-XXXXXXXXXX"
   "is_group_chat": true
   "sender": "<username>"
   "group_subject": "<group name>"

6. Have the agent call message(action=send, message="test reply") — without a target parameter. Per the tool documentation ("The target defaults to the current source conversation, so omit target unless sending elsewhere"), this should deliver to the originating Telegram group.
7. Observe: The reply does not appear in the Telegram group. Instead, it appears in the web gateway Chat UI in the browser.

Expected behavior

message(action=send) without an explicit target should resolve to the originating Telegram group chat — the same chat_id present in the inbound metadata. This is how it works in 1:1 DM sessions on the same node with the same configuration: the agent's reply is delivered back to the originating Telegram DM.

Actual behavior

The reply is silently routed to the web gateway Chat UI. The Telegram group receives nothing. No error is logged in the gateway — the send appears to "succeed" from the agent's perspective, but the message is delivered to the wrong surface (web browser instead of Telegram).

OpenClaw version

2026.5.12 (commit f066dd2)

Operating system

macOS 26.5 (Tahoe), Apple Silicon (arm64), Mac Mini M4

Install method

npm global (npm install -g openclaw)

Model

Model-independent. Reproduced with: anthropic/claude-opus-4-6 and xai/grok-4.3. The bug is in the message delivery layer, not the LLM completion path. The agent correctly invokes message(action=send) with appropriate content; the failure is in how the tool resolves the default target.

Provider / routing chain

openclaw (local gateway, loopback) -> anthropic (direct, api_key auth) openclaw (local gateway, loopback) -> xai (direct, api_key auth). No proxy, no Cloudflare AI Gateway, no OpenRouter. Telegram provider uses a single bot token (api_key auth, no OAuth).

Additional provider/model setup details

• Single Telegram bot with one or more group chat bindings in providers.telegram.bindings[].
• Each binding specifies a negative chat ID, agents: ["main"], requireMention: false, dmPolicy: "pairing".
• No defaultTarget configured at the agent, provider, or global level.
• Web gateway is enabled at default settings (gateway.bind: loopback).
• The lossless-claw plugin is active but unrelated to this issue.
• The model and LLM provider are irrelevant — the agent produces the correct tool call; the failure occurs downstream in the message tool's target resolution.

Logs, screenshots, and evidence

### Inbound — gateway correctly identifies Telegram group source


{
  "chat_id": "telegram:-XXXXXXXXXX",
  "is_group_chat": true,
  "sender_id": "XXXXXXXXX",
  "group_subject": "<group name>",
  "channel": "telegram",
  "provider": "telegram",
  "surface": "telegram"
}


### Outbound — reply appears in web gateway, not Telegram

The agent's `message(action=send)` call returns `{"ok": true}` but the message appears in the web gateway Chat UI in the browser. No corresponding Telegram API call is observed in the logs for this send. The Telegram group receives nothing.

### Workaround — explicit target delivers correctly


message(action=send, target="telegram:-XXXXXXXXXX", message="test")
→ {"ok": true, "messageId": "XXXXX", "chatId": "-XXXXXXXXXX"}
→ Message appears in the correct Telegram group.


### Direct API — bot permissions confirmed


curl -s -X POST "https://api.telegram.org/bot<TOKEN>/sendMessage" \
  -d '{"chat_id": "-XXXXXXXXXX", "text": "direct test"}'
# Returns: {"ok": true, "result": {"message_id": XXXXX}}

Impact and severity

• Affected: All Telegram group chat sessions where the agent uses message(action=send) without an explicit target. 1:1 DM sessions are not affected.
• Severity: High — completely blocks agent-to-group messaging via the standard tool interface. Agents appear unresponsive in Telegram groups unless their system prompt includes a workaround with hardcoded target IDs.
• Frequency: 100% reproducible. Every message(action=send) without target in a group chat session on this node hits this bug. Tested across multiple models, multiple gateway restarts, a full OS reboot, and multiple days.
• Consequence: Users in Telegram groups receive no reply from the agent. The message is silently misrouted to the web gateway where it may go unseen. There is no error surfaced to the user or the agent — both believe the message was sent successfully.

Additional information

• Regression status: Unknown. No confirmed "last known good" version has been identified where implicit group chat targeting worked correctly on this node. The bug may predate 2026.5.12 but this is the only version tested on this specific node.
• Workaround: Add a mandatory rule to the agent's system prompt or workspace config requiring target="telegram:<chat-id>" on every message(action=send) call in group chat sessions. This is reliable but manual, fragile, and not discoverable by new users.
• Possible root cause area: The implicit target resolver (the code path that determines where to send when target is omitted) appears to fall back to the web gateway session instead of reading the originating Telegram group chat ID from the inbound deliveryContext or session metadata. The inbound path correctly captures the group chat ID, but the outbound path does not consume it. The divergence between DM behavior (works) and group chat behavior (broken) suggests the resolver may have a code path specific to group chats that fails to propagate the source chat ID.
• Not a config issue: openclaw.json has been exhaustively audited — correct bindings, no defaultTarget, no OAuth, no proxy routing, no stale entries.
• Not a permissions issue: Bot has confirmed group membership; direct API sends succeed.
• Not a model issue: Reproduced with multiple LLM providers.
• Not a transient issue: Survives gateway restarts and OS reboots.

Key diagnostic evidence

1. Inbound metadata is correct. The session context block injected into the agent's prompt shows the correct Telegram group chat_id, is_group_chat: true, correct sender_id, and correct group_subject. The gateway correctly identifies the source on the inbound path.

2. The tool call omits target. The agent calls message(action=send) with only message and action — relying on the documented default behavior. No explicit target or channel is specified.

3. The reply appears in the web gateway. The message shows up in the browser-based Chat view of the OpenClaw web UI. It does not appear in the Telegram group.

4. DMs work correctly. The same agent, same config, same message(action=send) without target — resolves correctly and delivers to the originating Telegram DM in 1:1 sessions.

5. Explicit target works. Adding target="telegram:<correct-group-id>" to the same message(action=send) call delivers the message to the correct Telegram group every time. This confirms the bot has correct permissions, group membership, and network connectivity to Telegram.

6. Direct Telegram Bot API calls work. Sending via curl to https://api.telegram.org/bot<TOKEN>/sendMessage with the correct group chat_id succeeds and returns a valid message_id. The bot is a confirmed member of the group with send permissions.

7. Model-independent. Reproduced with anthropic/claude-opus-4-6 and xai/grok-4.3. The bug is in the message delivery/routing layer, not the LLM completion path.

8. Survives gateway restarts and OS reboots. Reproduced across multiple gateway restarts (including kill -9 and full macOS reboot). Not a transient state issue.

9. Config audited. No defaultTarget set at any level. Telegram binding is correct (verified chatId, agents, requireMention, dmPolicy). No OAuth or proxy routing configured. No groupPolicy override. The web gateway is enabled (as it is by default) but should not intercept Telegram-sourced sessions.