Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix [Bug]: Control UI misclassifies direct Telegram sessions across agents [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#55580•Fetched 2026-04-08 01:37:42
View on GitHub
Comments
0
Participants
1
Timeline
2
Reactions
0
Author
infinitemiuinfinitemiu
Participants
infinitemiuinfinitemiu
Timeline (top)
labeled ×2

Control UI appears to group direct Telegram conversations by peer/chat target instead of by agent first, causing a direct chat that belongs to one agent to be displayed under another agent. In my setup, a Telegram direct session that belongs to Agent B is consistently shown under Agent A in Control UI, even though the underlying session store, transcript location, and route binding were corrected. This appears to be a Control UI conversation grouping/display issue, not a core sessions.list filtering issue.

Root Cause

  • Agent A’s direct Telegram session should appear under Agent A
  • Agent B’s direct Telegram session should appear under Agent B
  • Control UI should not merge or reassign direct sessions across agents just because they share the same Telegram peer/chat id If Control UI performs conversation grouping, the grouping key should include at least:
  • agentId
  • channel
  • accountId (when relevant)
  • peer/to
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Control UI appears to group direct Telegram conversations by peer/chat target instead of by agent first, causing a direct chat that belongs to one agent to be displayed under another agent. In my setup, a Telegram direct session that belongs to Agent B is consistently shown under Agent A in Control UI, even though the underlying session store, transcript location, and route binding were corrected. This appears to be a Control UI conversation grouping/display issue, not a core sessions.list filtering issue.

Steps to reproduce

  1. Configure two agents, for example: agent-a agent-b
  2. Configure both agents to have Telegram direct-session context with the same Telegram peer/chat id. Example session shapes: agent:agent-a:telegram:direct:<PEER_ID> agent:agent-b:telegram:<ACCOUNT_ID_B>:direct:<PEER_ID> Where: <ACCOUNT_ID_B> is the Telegram bot/account id for Agent B <PEER_ID> is the Telegram direct peer/chat id
  3. Ensure Agent B has a valid explicit Telegram DM route binding such as: { "type": "route", "agentId": "agent-b", "match": { "channel": "telegram", "accountId": "<ACCOUNT_ID_B>", "peer": { "kind": "dm", "id": "<PEER_ID>" } } }
  4. Open Control UI and inspect the conversation/session list for Agent A and Agent B.
  5. Observe that the direct Telegram conversation for Agent B is shown under Agent A.
  6. Optional validation already performed in my case:
  • removed stray cross-agent session key contamination
  • corrected sessionFile placement
  • restored transcript file under the correct agent directory
  • restarted gateway
  • refreshed browser
  • tested in incognito/private browser The issue still persisted.

Expected behavior

  • Agent A’s direct Telegram session should appear under Agent A
  • Agent B’s direct Telegram session should appear under Agent B
  • Control UI should not merge or reassign direct sessions across agents just because they share the same Telegram peer/chat id If Control UI performs conversation grouping, the grouping key should include at least:
  • agentId
  • channel
  • accountId (when relevant)
  • peer/to

Actual behavior

Control UI shows Agent B’s Telegram direct session under Agent A. This happens even after:

  • removing stray cross-agent session index entries
  • correcting the transcript/session file location
  • restoring the session transcript file
  • adding an explicit Telegram DM route binding for Agent B
  • restarting gateway
  • refreshing the browser
  • testing in an incognito/private window Based on investigation, the backend sessions.list logic appears to support proper agentId filtering, so the bug likely exists in the Control UI conversation/session display layer, where sessions may be grouped by fields like:
  • origin
  • deliveryContext
  • lastTo
  • lastAccountId
  • direct peer/chat target instead of grouping by agent first.

OpenClaw version

<version 2026.3.24>

Operating system

macOS 26.4

Install method

pnpm

Model

openai-gpt-4.5-mini

Provider / routing chain

Telegram direct message -> OpenClaw routing/binding -> session store -> Control UI conversation grouping

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response

extent analysis

Fix Plan

To resolve the issue of Control UI grouping direct Telegram conversations by peer/chat target instead of by agent first, we need to modify the conversation grouping logic in the Control UI.

Here are the steps:

  • Update the conversationGroupingKey function to include agentId as the primary grouping key.
  • Ensure that the channel, accountId, and peer fields are included in the grouping key when relevant.

Example code snippet:

// conversationGroupingKey function
function conversationGroupingKey(session) {
  return [
    session.agentId, // Primary grouping key
    session.channel,
    session.accountId, // Include when relevant
    session.peer, // Include when relevant
  ].join(':');
}
  • Modify the renderConversations function to use the updated conversationGroupingKey function for grouping sessions.
// renderConversations function
function renderConversations(sessions) {
  const groupedSessions = sessions.reduce((acc, session) => {
    const key = conversationGroupingKey(session);
    if (!acc[key]) {
      acc[key] = [];
    }
    acc[key].push(session);
    return acc;
  }, {});

  // Render conversations based on the grouped sessions
  Object.keys(groupedSessions).forEach((key) => {
    const sessions = groupedSessions[key];
    // Render conversation for the group
  });
}

Verification

To verify that the fix worked:

  1. Restart the gateway and refresh the browser.
  2. Open Control UI and inspect the conversation/session list for Agent A and Agent B.
  3. Ensure that each agent's direct Telegram session appears under the correct agent.
  4. Validate that the conversation grouping is correct by checking the session keys and transcript files.

Extra Tips

  • Ensure that the conversationGroupingKey function is correctly implemented and used throughout the Control UI codebase.
  • Test the fix with different scenarios, including multiple agents and Telegram direct sessions.
  • Consider adding logging or debugging statements to verify that the conversation grouping logic is working as expected.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

  • Agent A’s direct Telegram session should appear under Agent A
  • Agent B’s direct Telegram session should appear under Agent B
  • Control UI should not merge or reassign direct sessions across agents just because they share the same Telegram peer/chat id If Control UI performs conversation grouping, the grouping key should include at least:
  • agentId
  • channel
  • accountId (when relevant)
  • peer/to
#memory management#API rate limit#retriever error#indexing error#inference speed

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING