Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix bug(telegram): main bot provider runs as accountId='default' despite token being in named account, requiring group config duplication [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#43856•Fetched 2026-04-08 00:18:31
View on GitHub
Comments
0
Participants
1
Timeline
1
Reactions
0
Author
rex05airex05ai
Participants
rex05airex05ai
Timeline (top)
unsubscribed ×1

When a Telegram bot token is stored in a named account (e.g. channels.telegram.accounts.rex-system), the running provider is labeled [default] in gateway logs and resolves group/topic policies using accountId='default' — not 'rex-system'. This means any group config stored under the named account is silently ignored during message routing, causing all group messages to be dropped with reason: not-allowed.

Root Cause

Root Cause (traced through source)

Fix Action

Workaround

Mirror the entire group config from the named account into channels.telegram.accounts.default.groups. Both must be kept in sync for changes to take effect.

Code Example

[telegram] [default] starting provider (@rene_b_ai_bot)

---

resolveChannelGroups(cfg, 'telegram', 'default')
RAW_BUFFERClick to expand / collapse

Summary

When a Telegram bot token is stored in a named account (e.g. channels.telegram.accounts.rex-system), the running provider is labeled [default] in gateway logs and resolves group/topic policies using accountId='default' — not 'rex-system'. This means any group config stored under the named account is silently ignored during message routing, causing all group messages to be dropped with reason: not-allowed.

Behavior

Gateway startup log:

[telegram] [default] starting provider (@rene_b_ai_bot)

The bot token lives in channels.telegram.accounts.rex-system.botToken. But the provider runs as [default]. When a message arrives from group -1003675844427, OpenClaw calls:

resolveChannelGroups(cfg, 'telegram', 'default')

This returns accounts['default']?.groups ?? channelConfig.groups. The default account has no groups configured, so both are undefined. Result: groupConfig = undefined, allowed = false, message dropped with reason: not-allowed.

Root Cause (traced through source)

resolveChannelGroupPolicy is called with accountId: account.accountId where account is resolved from the running provider context. The provider context uses the label 'default' (not the named account 'rex-system') when the named account's bot is treated as the primary/default provider.

The result: resolveAccountEntry(accounts, 'default') finds the default account (which has no groups), so no group config is found.

Impact

  • All group messages to the primary bot are silently blocked (reason: not-allowed)
  • Admin status in the group does NOT override this (confirmed separately)
  • The issue only manifests for the account whose token is used as the [default] provider; named accounts for other bots (coo, dev, etc.) work correctly because their accountId matches their account name

Workaround

Mirror the entire group config from the named account into channels.telegram.accounts.default.groups. Both must be kept in sync for changes to take effect.

Expected Behavior

When a bot token is found in a named account (e.g. rex-system), the provider should resolve group/topic policies using that named account's config, not the default account. Alternatively, document clearly that the primary bot always runs as default and that group config must live in the default account.

Steps to Reproduce

  1. Create a named Telegram account (e.g. rex-system) with a botToken and group config
  2. Leave the default account with no groups
  3. Add the bot to a group and send a message
  4. Observe reason: not-allowed in gateway logs despite correct group config in the named account

Environment

  • OpenClaw version: 2026.3.11 (29dc654)
  • macOS 15.3 (Darwin 25.3.0, arm64)
  • Node.js v25.8.0
  • Telegram forum supergroup with named account rex-system as main bot

extent analysis

Fix Summary

Make the Telegram provider use the named account ID (e.g. rex-system) instead of the hard‑coded "default" label when it is the primary bot.
The fix consists of:

  1. Provider bootstrap – propagate the account ID from the config into the provider context.
  2. Policy resolver – look up group policies with the provider’s accountId (fallback to "default" only when the account truly is the default).
  3. Optional config flag – allow operators to explicitly set which account should be treated as the default bot.

Step‑by‑Step Fix Plan

1. Add a primaryAccountId flag to the Telegram channel config

File: config/channels/telegram.yml (or equivalent JSON/YAML source)

channels:
  telegram:
    primaryAccountId: rex-system   # <-- new optional flag
    accounts:
      default:
        botToken: "xxxx"
      rex-system:
        botToken: "yyyy"
        groups:
          - id: -1003675844427
            allowed: true

If the flag is omitted the system falls back to the historic "default" behavior.

2. Propagate the account ID when creating the provider

File: src/gateway/providers/telegram/providerFactory.ts (or wherever createTelegramProvider lives)

import { resolveAccountEntry } from '../../config/resolver';

export function createTelegramProvider(cfg, logger) {
  // Resolve the primary account – use the new flag if present
  const primaryId = cfg.channels?.telegram?.primaryAccountId ?? 'default';
  const account = resolveAccountEntry(cfg.channels.telegram.accounts, primaryId);

  if (!account?.botToken) {
    throw new Error(`Telegram bot token missing for account "${primaryId}"`);
  }

  // Build the provider context with the *real* accountId
  const context = {
    accountId: primaryId,          // <-- NEW: keep the real ID
    botToken: account.botToken,
    // …other fields (

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#ssr#installation#tensor shape#autograd error#model loading#dependency error#configuration error#environment variable#network issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - 💡(How to fix) Fix bug(telegram): main bot provider runs as accountId='default' despite token being in named account, requiring group config duplication [1 participants]