Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

Title
Telegram helper-agent session key mapping bug: slash:<user> keys are incorrectly projected to group:<group_id>:topic:1, causing stale model-switch artifacts

Body

Summary

I found what appears to be a session-index / restore / normalization bug affecting Telegram helper agents in OpenClaw 2026.3.28 (f9b1079).

For multiple helper agents, session store keys shaped like:

agent:<helper>:telegram:slash:<user_id>

are being written back as group topic sessions instead of real direct/slash sessions.

In other words, the key name says slash:<user_id>, but the stored content points to:

telegram:group:<group_id>:topic:1

This seems to create a stale alias/anchor that can continue participating in runtime session selection and model-switch decisions, which in my case shows up as lingering Gemini model-switch artifacts and broken fallback behavior.

Environment

• OpenClaw: 2026.3.28 (f9b1079)
• Channel: Telegram
• Scope: helper agents only
• Main agent used as control/comparison
• Investigation was read-only at first; later I also tested cleanup of stale session keys, but the issue reappeared after reload/reuse.

What I expected

For helper agents, a Telegram key like:

agent:<helper>:telegram:slash:<user_id>

should represent a direct/slash-style session for that user, or not exist at all if unused.

It should not resolve to a group topic session.

Fallback behavior should also remain independent of unrelated stale session aliases.

What actually happens

For multiple helper agents, the slash:<user_id> key exists, but its content indicates a group topic session instead:

• chatType = group
• groupId = <group_id>:topic:1
• origin.from = telegram:group:<group_id>:topic:1
• threadId = 1
• often with missing model, authProfileOverride, systemSent, or sessionFile

This makes the key look like a placeholder / alias / backfilled shell rather than a real slash/direct session.

Direct evidence

Normal helper main topic key

Example from one helper agent:

agent:cs-helper:telegram:group:<redacted_group_id>:topic:1

Representative fields:

• valid sessionId
• model = gpt-5.4
• authProfileOverride = openai-codex:default
• systemSent = true
• origin.from = telegram:group:<redacted_group_id>:topic:1
• valid sessionFile

This looks like a healthy topic session.

Broken slash key for the same helper

agent:cs-helper:telegram:slash:<redacted_user_id>

Representative fields:

• chatType = group
• groupId = <same_group_id>:topic:1
• origin.from = telegram:group:<same_group_id>:topic:1
• threadId = 1
• missing model
• missing authProfileOverride
• missing systemSent
• missing sessionFile

So the key name says slash:<user>, but the object content is actually a group topic shell.

Scope / comparison

I checked multiple helper agents and found the same pattern in:

• ops-helper
• file-helper
• cfo-helper
• rd-helper

In contrast, the main agent’s slash key looked normal:

agent:main:telegram:slash:<redacted_user_id>

with a direct-style origin like:

origin.from = telegram:<user_id>

This suggests the issue is not with Telegram slash sessions in general, but specifically with helper-agent Telegram session key normalization / restore / merge behavior.

Timing correlation

One suspicious timing window looked like this:

1. config reload
2. the fake helper slash:<user> key gets updated
3. sessions.list is queried
4. runtime logs show live model-switch behavior
5. Telegram send occurs

This does not prove causality by itself, but it strongly suggests the fake slash key is being written or refreshed in the same window as session restore / indexing / runtime selection activity.

User-facing impact

In my case, this seems to contribute to stale runtime model-switch artifacts.

I repeatedly observed logs like:

live session model switch detected before attempt: gpt-5.4 -> google-vertex/gemini-3.1-pro-preview
Live session model switch requested: google-vertex/gemini-3.1-pro-preview

even when the active helper session was otherwise expected to be on a different model path.

At the same time, google-vertex auth was failing for that helper, so the combination resulted in broken fallback behavior:

• candidate 1: google-vertex/gemini-3.1-pro-preview fails
• candidate 2: gpt-5.4 gets pulled back by live session model switch
• candidate 3: fallback model also gets pulled back
• candidate 4: another google-vertex candidate fails
• final result: all candidates fail instead of a clean fallback succeeding.

High-confidence hypothesis

A helper-agent-specific Telegram session restore / merge / normalization path is incorrectly projecting:

telegram:slash:<user_id>

onto:

telegram:group:<group_id>:topic:1

creating fake slash aliases that should not exist.

These aliases then appear to keep participating in session routing / session reuse / live model-switch decisions.

What I have already ruled out

• Not just one dirty helper session
• Not just UI display inconsistency
• Not a general Telegram slash issue, because main looks normal
• Not fixed by manually deleting one or two stale helper keys; they can reappear after later activity/reload

Suggested investigation areas

These are the places that seem worth checking:

1. helper-agent Telegram session key normalization
2. session restore / merge logic after reload
3. whether sessions.list or related UI/session enumeration has write-back side effects
4. why helper agents differ from main for Telegram slash/direct mapping

Redacted sample

{
  "key": "agent:cs-helper:telegram:slash:<redacted_user_id>",
  "chatType": "group",
  "groupId": "<redacted_group_id>:topic:1",
  "origin.from": "telegram:group:<redacted_group_id>:topic:1",
  "threadId": 1,
  "model": null,
  "authProfileOverride": null
}

Control sample:

{
  "key": "agent:main:telegram:slash:<redacted_user_id>",
  "origin.chatType": "direct",
  "origin.from": "telegram:<redacted_user_id>"
}

If useful

I can provide:

• a fully redacted evidence report
• additional redacted logs around the reload / sessions.list / live-model-switch window
• more examples across helper agents

Steps to reproduce

Run OpenClaw 2026.3.28.
Configure multiple Telegram helper agents, each serving a Telegram forum/supergroup topic (topic:1 in my case).
Keep Telegram enabled for both the main agent and helper agents.
Interact with one or more helper agents from Telegram group topics, and also let the UI/session list load normally.
Inspect the helper agents’ session store entries after reload / normal usage.
Observe that keys shaped like:
agent::telegram:slash:<user_id>

are present, but their stored content points to:

telegram:group:<group_id>:topic:1

instead of a direct/slash session.
7. In my case, this also correlates with runtime logs showing unexpected live model-switch behavior for helper agents.

Expected behavior

A key like:
agent::telegram:slash:<user_id>

should represent a real direct/slash session for that user, or should not exist if unused.

It should not be backfilled with a Telegram group topic session.

Helper-agent session indexing should keep:

direct/slash sessions
group/topic sessions

strictly separated.

Session restore / reload / UI enumeration should not create fake slash aliases that can influence later session routing or model-switch decisions.

Actual behavior

For multiple helper agents, telegram:slash:<user_id> keys are incorrectly written as group topic session shells, with fields such as chatType = group, origin.from = telegram:group:<group_id>:topic:1, and often missing normal runtime metadata like model or authProfileOverride. This appears to create stale aliases that can continue participating in helper-agent session routing and model-switch behavior.

OpenClaw version

2026.3.28

Operating system

macOS26.4

Install method

npm

Model

"openai-codex/gpt-5.4","kimi-coding/k2p5","google-vertex/gemini-3.1-pro-preview",

Provider / routing chain

Telegram -> OpenClaw gateway -> helper agent session routing -> session restore/index mapping -> model routing/fallback -> provider (google-vertex / openai-codex / kimi)

Additional provider/model setup details

Telegram group topic -> OpenClaw gateway -> helper agent (cs-helper / other helper agents) -> Telegram session key mapping / restore logic -> model routing & fallback -> google-vertex / openai-codex / kimi

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response