Summary

In a multi-account Telegram setup, running /reset from a non-default bot sends the "New session started" confirmation message to the default Telegram account instead of the account that received the command.

Steps to reproduce

1. Configure multiple Telegram accounts:

"telegram": {
  "accounts": {
    "default": { "botToken": "...", "name": "Sugi" },
    "gsw": { "botToken": "...", "name": "Sugi GSW" }
  }
}

2. Bind a separate agent to the non-default account:

"bindings": [
  { "agentId": "gsw", "match": { "channel": "telegram", "accountId": "gsw" } }
]

3. Send /reset to the gsw Telegram bot (as an allowlisted user)

4. Observe where the "New session started · model: X" confirmation appears

Expected behavior

The reset confirmation should be delivered through the gsw Telegram bot (the same bot that received the /reset command).

Actual behavior

The reset confirmation is delivered through the default Telegram bot, appearing in the wrong chat.

Note: The actual session reset works correctly (only the target agent's session is reset). The bug is specifically in the confirmation message delivery routing.

Environment

• Clawdbot version: 2026.1.24-3
• OS: macOS (Darwin 25.2.0 arm64)
• Install method: npm global

Related Issues

• Telegram multi-account bindings not routing to correct agent #803 — Telegram multi-account bindings not routing to correct agent (fixed by PR Telegram: fix webhook multi-account routing (respect bindings.accountId) #821)
• Bug: Subagent announce delivery fails with wrong WhatsApp account (multi-account routing) #1058 — Subagent announce delivery fails with wrong WhatsApp account (fixed by threading accountId)

This appears to be the same class of bug as #1058 — the accountId from the incoming command context is not being threaded through to the confirmation message delivery.

Notes

• Inbound message routing works correctly (messages to gsw bot route to agent:gsw:* sessions)
• The confirmation shows the correct agent's model (e.g., claude-sonnet-4-5 for gsw), but is delivered to wrong bot
• Likely fix location: wherever /reset command confirmation is sent, it needs to respect the incoming accountId