OpenClaw 4.5 regression: Telegram approval prompts can surface in the wrong DM, leaking host-approval actions across chats

Summary

After upgrading to v2026.4.5, a host approval prompt initiated while investigating Jeffe's Telegram DM surfaced in Sarah's separate Telegram DM. Sarah is allowlisted to chat with the assistant, but she is not the initiator of the command and should not receive approval prompts for work started in Jeffe's DM.

This appears to be a Telegram DM routing/approval-context leak, not just a normal permission check.

Impact

• Host approval prompts can be delivered to the wrong Telegram DM
• A different allowlisted user may see internal diagnostic commands started from another person's conversation
• This is a cross-chat isolation failure, not just a UX issue
• It risks accidental approval/denial by the wrong person

Concrete example

Sarah received an approval prompt for this host diagnostic command:

python3 - <<'PY'
import json
p='/Users/telos/.openclaw/agents/main/sessions/sessions.json'
with open(p) as f:
 data=json.load(f)
for k,v in data.items():
 if '8439007096' in k or ('origin' in v and ('8439007096' in json.dumps(v.get('origin',{})) or '8439007096' in json.dumps(v.get('deliveryContext',{})))):
 print('KEY:', k)
 print(json.dumps(v, indent=2)[:6000])
 print('---')
PY

Approval id shown to Sarah:

• 71b2f6a2-77d7-48ee-bec0-d9c33edfcd08

That command was initiated during investigation of Jeffe's DM session, not Sarah's.

Expected behavior

• Approval prompts should only surface in the chat/session that initiated the pending command
• Allowlisted users should not see approvals for commands started from another user's DM
• Approval authority should stay bound to the originating conversation context

Actual behavior

• Approval prompt surfaced in Sarah's DM even though the command belonged to Jeffe's investigation flow
• This occurred despite Sarah not appearing to have an active Telegram DM session entry in sessions.json

Evidence

Session map evidence

Live sessions.json lookup found Jeffe's Telegram entries, but not Sarah's:

• Found:
  • agent:main:telegram:direct:8439007096
  • agent:main:telegram:slash:8439007096
• Not found:
  • 8586126983
  • 8351575041

This suggests Sarah's approval prompt did not originate from a normal Sarah-bound session entry.

Runtime behavior

• Jeffe initiated host-level diagnostics in his Telegram DM
• Sarah received the approval prompt for one of those commands
• Gateway/runtime otherwise remained operational

Suspected root cause

Likely one of the following in 4.5 Telegram approval routing:

1. approval prompts are using stale Telegram DM reply-target state
2. approval prompts are keyed too loosely by channel/account rather than originating chat/session
3. direct-message routing is leaking across allowlisted Telegram users when no active session entry exists for the recipient
4. approval UI delivery path is using the wrong conversation context after a reset/new-session/remap event

Given the parallel DM instability observed elsewhere in 4.5, this may share root cause with Telegram direct-session state handling.

Why this is serious

This is not just a delayed message problem. It crosses a trust boundary:

• one user can receive operational approval prompts created by another user's session
• the wrong person can see command details and potentially approve or deny them

Suggested repro

1. Configure Telegram with multiple allowlisted DM users
2. Start a host-approval-requiring diagnostic from Jeffe's DM
3. Have another allowlisted Telegram user with prior DM history present in the system
4. Trigger approval flow during or after DM reset/remap conditions
5. Observe whether approval prompt surfaces in the wrong DM

Suggested fix directions

1. Bind approval delivery strictly to originating sessionKey plus originating chat id
2. Refuse fallback delivery of approvals to any other DM when original chat context is missing or stale
3. Add logging that records approval id -> originating session key -> delivered chat id
4. Add regression tests for multiple allowlisted Telegram DMs with concurrent/pending approvals
5. Audit any fallback path that chooses lastChannel, lastTo, or channel-global state for approval delivery

Environment

• OpenClaw v2026.4.5
• macOS
• Telegram enabled
• Multiple allowlisted Telegram users
• Approval leak observed across separate Telegram DMs