openclaw - ✅(Solved) Fix agents bind fails for unconfigured bundled channels (setup-runtime gap) [1 pull requests, 1 comments, 2 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#62508Fetched 2026-04-08 03:03:23
View on GitHub
Comments
1
Participants
2
Timeline
7
Reactions
0
Timeline (top)
mentioned ×3subscribed ×3commented ×1

Root Cause

Three locations in /Users/peter/openclaw/src/plugins/loader.ts:

  1. loader.ts:613-633 (shouldLoadChannelPluginInSetupRuntime) — routes unconfigured channels to setup-runtime mode
  2. loader.ts:1349-1361 — per-plugin full vs setup-runtime decision
  3. loader.ts:1560-1583 (setup-runtime branch) — only registers a channel if resolveSetupChannelRegistration(mod) returns a top-level .plugin field

The bug: Telegram (and most modern bundled channels) now use defineBundledChannelSetupEntry from extensions/telegram/setup-entry.ts, which produces { kind: "bundled-channel-setup-entry", loadSetupPlugin: () => ... } — there is no .plugin field. So resolveSetupChannelRegistration returns {}, the plugin record is added with no channel registration, and getActivePluginChannelRegistry().channels never sees telegram.

Chain of calls: agents bindparseBindingSpecs (src/commands/agents.bindings.ts:288-326) → normalizeChannelId (src/channels/plugins/registry.ts:89-91) → normalizeAnyChannelId (src/channels/registry.ts:80-86) → findRegisteredChannelPluginEntrygetActivePluginChannelRegistry() → empty → "Unknown channel".

Fix Action

Workaround

Users can work around this by configuring the channel first before binding:

# Option 1: Add channel via CLI
openclaw channels add telegram

# Option 2: Set environment variable
export TELEGRAM_BOT_TOKEN="your-bot-token"

Then openclaw agents bind --bind telegram works correctly.

PR fix notes

PR #66843: fix(config): restore Telegram native commands under auto defaults

Description (problem / solution / changelog)

Summary

  • Problem: Telegram native slash commands stopped registering when commands.native and commands.nativeSkills were left on the default "auto" behavior.
  • Why it matters: the Telegram / menu became empty and native command handling stopped working even though the Telegram plugin still advertised native command auto support.
  • What changed: src/config/commands.ts now normalizes provider IDs through the plugin-registry path before resolving native command and native skill auto defaults, and src/config/commands.test.ts adds a regression test for that path.
  • What did NOT change (scope boundary): this does not add a Telegram-specific hardcode, does not change config defaults, and does not modify command implementations.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor required for the fix
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Closes #66756
  • Related #62508
  • This PR fixes a bug or regression

Root Cause (if applicable)

  • Root cause: resolveNativeCommandsEnabled() and resolveNativeSkillsEnabled() normalized provider IDs through ../channels/registry.js, while plugin lookup used the plugin-registry path. In the affected bundle, that normalization path failed to recognize Telegram, so auto resolution returned false too early.
  • Missing detection / guardrail: there was no regression test for a provider that is resolvable by the plugin registry but missed by the narrower normalization path.
  • Contributing context (if known): this surfaced as a Telegram regression on 2026.4.14, where native command auto support still existed in the plugin but command registration fell through to disabled. This is distinct from the Telegram command-sync/cache symptom family addressed in other work such as #66730; this PR fixes the config-side auto-default resolution path in src/config/commands.ts.

Regression Test Plan (if applicable)

  • Coverage level that should have caught this:
    • Unit test
    • Seam / integration test
    • End-to-end test
    • Existing coverage already sufficient
  • Target test or file: src/config/commands.test.ts
  • Scenario the test should lock in: when a provider is present in the plugin registry and its commands and skills are auto-enabled there, resolveNativeCommandsEnabled() and resolveNativeSkillsEnabled() should stay enabled under globalSetting: "auto".
  • Why this is the smallest reliable guardrail: the bug is in config-resolution logic, so a focused unit regression catches it without needing a full Telegram runtime harness.
  • Existing test that already covers this (if any): none found
  • If no new test is added, why not: N/A

User-visible / Behavior Changes

Telegram native slash commands stay enabled under the default auto path for affected providers instead of being incorrectly disabled.

Diagram (if applicable)

Before:
Telegram provider -> registry normalization misses provider -> auto resolves false -> native commands do not register

After:
Telegram provider -> plugin-registry normalization resolves provider -> auto resolves true -> native commands register

Security Impact (required)

  • New permissions/capabilities? (Yes)
  • Secrets/tokens handling changed? (No)
  • New/changed network calls? (No)
  • Command/tool execution surface changed? (Yes)
  • Data access scope changed? (No)
  • If any Yes, explain risk + mitigation:
    • This restores intended native command and native skill exposure for providers that already advertise auto support.
    • It does not add new command implementations or widen data access.
    • Risk is limited by aligning normalization with the same plugin-registry-backed path already used for plugin lookup.

Repro + Verification

Environment

  • OS: macOS for local validation, with the original user-visible regression reported on Telegram in OpenClaw 2026.4.14
  • Runtime/container: source checkout plus local installed OpenClaw bundle analysis
  • Model/provider: N/A
  • Integration/channel (if any): Telegram
  • Relevant config (redacted): commands.native: "auto", commands.nativeSkills: "auto"

Steps

  1. Leave native commands and native skills on auto.
  2. Use the affected bundle where Telegram is missing from the older normalization path.
  3. Observe Telegram native command auto resolution fall back to disabled even though the plugin registry still exposes Telegram native auto support.

Expected

  • Telegram native commands remain enabled when the plugin registry marks them auto-enabled.

Actual

  • Auto resolution returned false early, which disabled Telegram native commands.

Evidence

Attach at least one:

  • Failing test/log before + passing after
  • Trace/log snippets
  • Screenshot/recording
  • Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

  • Verified scenarios:
    • confirmed the affected normalization path could miss Telegram while plugin auto support still existed
    • ran the targeted regression test:
      • corepack pnpm exec vitest run --config test/vitest/vitest.runtime-config.config.ts src/config/commands.test.ts
      • result: 1 file passed, 9 tests passed
    • ran:
      • corepack pnpm build
      • corepack pnpm check
      • corepack pnpm check:docs
  • Edge cases checked:
    • both resolveNativeCommandsEnabled()
    • and resolveNativeSkillsEnabled()
  • What you did not verify:
    • a fully green pnpm test run on this host, because the repo-wide suite surfaced unrelated failures outside touched files (for example src/gateway/control-ui.http.test.ts, src/agents/tools/image-tool.test.ts, extensions/signal/src/install-signal-cli.test.ts) and also hit a worker OOM during the broader run
    • end-to-end Telegram verification on this source branch

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

  • Backward compatible? (Yes)
  • Config/env changes? (No)
  • Migration needed? (No)
  • If yes, exact upgrade steps:

Risks and Mitigations

  • Risk:
    • providers previously dropped by the narrower normalization path will now inherit plugin-registry auto defaults
    • Mitigation:
      • that is the intended behavior,
      • the fix keeps normalization aligned with plugin lookup,
      • and the regression test covers both native commands and native skills

AI Assistance

  • AI-assisted: Yes
  • Tooling used: OpenClaw / Codex-assisted workflow
  • Testing degree: targeted regression validated locally; broader local gate attempted (build, check, and check:docs passed, repo-wide test was not green on this host outside the touched files)
  • I understand what the code does: Yes
  • Prompts/session logs: available on request
  • codex review --base origin/main: attempted via npm exec @openai/codex -- review --base origin/main, but local Codex auth on this host returned 401 Unauthorized

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • src/config/commands.test.ts (modified, +29/-0)
  • src/config/commands.ts (modified, +1/-2)

Code Example

$ openclaw agents bind --bind telegram
[plugins] feishu_chat: Registered ...
[plugins] feishu_im: Registered ...
[plugins] feishu_oauth: Registered ...
Unknown channel "telegram".

---

# Option 1: Add channel via CLI
openclaw channels add telegram

# Option 2: Set environment variable
export TELEGRAM_BOT_TOKEN="your-bot-token"
RAW_BUFFERClick to expand / collapse

Bug Summary

openclaw agents bind --bind telegram fails with "Unknown channel "telegram"" when the Telegram channel is not pre-configured, even though Telegram is a bundled channel that should work in setup-runtime mode.

Reproduction

On OpenClaw 2026.4.2 (and likely later versions):

$ openclaw agents bind --bind telegram
[plugins] feishu_chat: Registered ...
[plugins] feishu_im: Registered ...
[plugins] feishu_oauth: Registered ...
Unknown channel "telegram".

Exit code 0 (silent failure). Only Feishu plugins load because local config only has Feishu configured.

Root Cause

Three locations in /Users/peter/openclaw/src/plugins/loader.ts:

  1. loader.ts:613-633 (shouldLoadChannelPluginInSetupRuntime) — routes unconfigured channels to setup-runtime mode
  2. loader.ts:1349-1361 — per-plugin full vs setup-runtime decision
  3. loader.ts:1560-1583 (setup-runtime branch) — only registers a channel if resolveSetupChannelRegistration(mod) returns a top-level .plugin field

The bug: Telegram (and most modern bundled channels) now use defineBundledChannelSetupEntry from extensions/telegram/setup-entry.ts, which produces { kind: "bundled-channel-setup-entry", loadSetupPlugin: () => ... } — there is no .plugin field. So resolveSetupChannelRegistration returns {}, the plugin record is added with no channel registration, and getActivePluginChannelRegistry().channels never sees telegram.

Chain of calls: agents bindparseBindingSpecs (src/commands/agents.bindings.ts:288-326) → normalizeChannelId (src/channels/plugins/registry.ts:89-91) → normalizeAnyChannelId (src/channels/registry.ts:80-86) → findRegisteredChannelPluginEntrygetActivePluginChannelRegistry() → empty → "Unknown channel".

Workaround

Users can work around this by configuring the channel first before binding:

# Option 1: Add channel via CLI
openclaw channels add telegram

# Option 2: Set environment variable
export TELEGRAM_BOT_TOKEN="your-bot-token"

Then openclaw agents bind --bind telegram works correctly.

Proposed Fix Options

Option 1 (loader fix): Teach resolveSetupChannelRegistration to recognize the new { kind: "bundled-channel-setup-entry", loadSetupPlugin } shape AND call getBundledChannelSetupPlugin(id) from src/channels/plugins/bundled.ts:318-339. Crosses src/pluginssrc/channels boundary the repo CLAUDE.md polices. ~30-50 lines + contract test updates.

Option 2 (routing fix, cleaner): Replace normalizeChannelId(channelRaw) at agents.bindings.ts:303 with a new helper that first tries normalizeChatChannelId from src/channels/ids.ts (manifest-only lookup via BUNDLED_CHAT_CHANNEL_ENTRIES, no plugin runtime registration needed), then falls back to normalizeChannelId for external plugin channels. ~25 lines + a unit test.

Related

  • c01bfcbc12 fix: load CLI plugin registry for channel-aware commands (#1338) — shipped in 2026.4.2, only handles plugin loading
  • f9e9d4e357 fix(cli): preload plugins for local agent runs
  • fae4492d92 fix: re-pin channel registry after deferred plugin reload
  • Issue #31379 — same family but unresolved

@gumadeiras (plugins/CLI maintainer) — which fix shape do you prefer? Happy to submit a PR once maintainers weigh in.

@joshp123 @obviyus (telegram maintainers) — FYI on the setup-runtime registration gap for bundled channels.

extent analysis

TL;DR

The most likely fix for the "Unknown channel 'telegram'" error is to update the resolveSetupChannelRegistration function to recognize the new { kind: "bundled-channel-setup-entry", loadSetupPlugin } shape or to replace normalizeChannelId with a new helper that first tries normalizeChatChannelId for bundled channels.

Guidance

  • Verify that the Telegram channel is not pre-configured before attempting to bind it using openclaw agents bind --bind telegram.
  • Consider configuring the channel first using openclaw channels add telegram or setting the TELEGRAM_BOT_TOKEN environment variable as a workaround.
  • To fix the issue, update the resolveSetupChannelRegistration function to recognize the new shape or replace normalizeChannelId with a new helper that first tries normalizeChatChannelId for bundled channels.
  • Test the fix by attempting to bind the Telegram channel after applying the update.

Example

No code snippet is provided as the issue is related to a specific implementation detail in the OpenClaw codebase.

Notes

The fix may require updates to the contract tests and may have implications for the src/plugins and src/channels boundaries.

Recommendation

Apply the workaround by configuring the channel first or update the resolveSetupChannelRegistration function to recognize the new shape, as this seems to be a more straightforward fix.

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…

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 - ✅(Solved) Fix agents bind fails for unconfigured bundled channels (setup-runtime gap) [1 pull requests, 1 comments, 2 participants]