Skip to content

Reply routes to webchat instead of originating Telegram channel #13332

@code-compliant

Description

@code-compliant

Bug Description

When a message is sent via Telegram DM, the agent's reply is sometimes delivered to the webchat UI on the host machine instead of back to Telegram. The user only sees the response if they happen to be at the machine with the webchat open.

Subsequent Telegram messages in the same session cause replies to route correctly to Telegram again, suggesting the webchat "claims" the reply surface when it was the most recently active client.

Expected Behaviour

Per the Channel Routing docs:

OpenClaw routes replies back to the channel where a message came from. The model does not choose a channel; routing is deterministic and controlled by the host configuration.

A Telegram-originated message should always receive its reply on Telegram, regardless of whether webchat is open or was recently active.

Steps to Reproduce

  1. Have Telegram channel enabled and webchat accessible on the host
  2. Open the webchat UI in a browser (attaches to agent:main:main)
  3. Send a message via Telegram DM
  4. Observe: reply appears in webchat, not in Telegram
  5. Send a second message via Telegram
  6. Observe: reply now correctly appears in Telegram

Environment

  • OpenClaw 2026.2.6-3
  • Single agent (agent:main:main)
  • Telegram channel enabled, webchat on localhost
  • No multi-agent or bindings config
  • Gateway mode: local, bind: loopback

Configuration (relevant)

{
  "channels": {
    "telegram": {
      "enabled": true,
      "dmPolicy": "pairing",
      "streamMode": "partial"
    }
  },
  "gateway": {
    "mode": "local",
    "bind": "loopback"
  }
}

Analysis

The webchat and Telegram DMs share the same main session key (agent:main:main). It appears that the most recently active client (webchat vs Telegram) may be incorrectly used as the reply target, overriding the per-message channel origin.

Suggested Fix

Reply routing should be pinned to the inbound message's channel, not the most recently active client on the shared session.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingstaleMarked as stale due to inactivity

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions