Summary

Adding any named Telegram account can silently drop the implicit/default Telegram account from runtime polling.

Affected behavior

In a config with a top-level Telegram bot token, adding channels.telegram.accounts.fusion plus a telegram:fusion binding caused the default Telegram provider to disappear after restart. openclaw config validate, openclaw agents list, and post-restart agent smoke all stayed green, but openclaw channels status --probe no longer showed the default Telegram account.

Minimal repro

1. Start with a config that has top-level channels.telegram.botToken and no channels.telegram.accounts section.
2. Add a named account:

channels: {
  telegram: {
    accounts: {
      fusion: {
        name: "Fusion",
        enabled: false,
        dmPolicy: "allowlist",
        allowFrom: ["6056248133"],
        groupPolicy: "allowlist",
        contextVisibility: "allowlist_quote",
        streaming: { mode: "partial" },
        execApprovals: {
          enabled: true,
          approvers: [6056248133],
          target: "dm"
        }
      }
    }
  }
}
bindings: [
  { agentId: "fusion", match: { channel: "telegram", accountId: "fusion" } }
]

3. Restart Gateway.
4. openclaw channels status --probe shows the named account, but the default Telegram account is missing.
5. Adding channels.telegram.accounts.default: { name: "Jarvis", enabled: true } restores the default polling provider.

Root cause

dist/account-selection-Bvg_hTfj.js lines 15–58 show listConfiguredAccountIds() enumerating cfg.channels.telegram.accounts keys and combineAccountIds() only returning [DEFAULT_ACCOUNT_ID] when the configured+additional account set is empty.

Because any named account makes the set non-empty, the implicit default is no longer injected.

Impact

This is silent and destructive-by-default:

• config validation passes
• agent list/binding checks pass
• smoke tests on the new account can pass
• the existing default Telegram bot can stop polling without an obvious error

Expected

Either:

• explicit named account additions should preserve the default account automatically, or
• this behavior should be documented/promoted loudly enough that adding a named account cannot accidentally kill the default channel

Notes

This helper pattern appears to be shared at the account-listing layer, so the issue may affect other account-aware channels too (e.g. Signal / iMessage / Slack-family account helpers that use createAccountListHelpers / listCombinedAccountIds).