Summary
Running OpenClaw v2026.5.2 (commit 8b2a6e5). Issue #62306 was closed as fixed on 2026-04-26, but the underlying cross-chat contamination still occurs when a single Telegram bot serves multiple Telegram users in separate DMs.
A reply intended for User A surfaces inside User B's DM thread when:
- A subagent spawned during User A's turn finishes after User B has sent a message,
- Or the main agent reuses
deliveryContext cached on agent:main:main from the most-recently-touched chat.
The fix from #62306 appears to address Control UI / webchat session-history persistence but does not isolate deliveryContext per chat_id / sender_id for the Telegram channel.
Steps to reproduce
- Configure one Telegram bot bound to a single OpenClaw main agent.
- From User A's DM, ask the agent something that spawns a subagent (or starts a long-running tool call).
- While that work is in flight, switch to User B's DM and send any message to the same bot.
- When the subagent completion / async result lands, observe that part of User A's content (or completion announce) is delivered into User B's DM, or the agent's reply to one user references content that belongs to the other user's transcript.
Expected
Each Telegram chat_id is its own delivery scope. No content from another chat_id should ever surface in the current reply, regardless of which session was last active.
Actual
The agent's deliveryContext on agent:main:main holds the last-touched chat across all users. Subagent completion events and queued message merges resolve against this shared context, so:
- Subagent results delivered to the wrong user's DM.
- Replies in the new user's DM contain references / quoted text from the prior user's conversation.
Environment
- OpenClaw 2026.5.2 (8b2a6e5)
- Channel:
telegram (bot mode, polling)
- Single main agent serving multiple unrelated Telegram users via DM
- Subagents spawned via
sessions_spawn (default isolated context)
- No
runtime=subagent overrides
Workaround in use
Strict per-reply check of inbound chat_id / sender_id at the prompt layer, refusing to reference any content not tagged with the current chat_id. Mitigates symptoms but does not fix the underlying delivery-context sharing.
Notes
Summary
Running OpenClaw v2026.5.2 (commit 8b2a6e5). Issue #62306 was closed as fixed on 2026-04-26, but the underlying cross-chat contamination still occurs when a single Telegram bot serves multiple Telegram users in separate DMs.
A reply intended for User A surfaces inside User B's DM thread when:
deliveryContextcached onagent:main:mainfrom the most-recently-touched chat.The fix from #62306 appears to address Control UI / webchat session-history persistence but does not isolate
deliveryContextperchat_id/sender_idfor the Telegram channel.Steps to reproduce
Expected
Each Telegram
chat_idis its own delivery scope. No content from anotherchat_idshould ever surface in the current reply, regardless of which session was last active.Actual
The agent's
deliveryContextonagent:main:mainholds the last-touched chat across all users. Subagent completion events and queued message merges resolve against this shared context, so:Environment
telegram(bot mode, polling)sessions_spawn(default isolated context)runtime=subagentoverridesWorkaround in use
Strict per-reply check of inbound
chat_id/sender_idat the prompt layer, refusing to reference any content not tagged with the currentchat_id. Mitigates symptoms but does not fix the underlying delivery-context sharing.Notes
deliveryContextcache key by(channel, chat_id)rather than by agent identity.