fix(telegram): use group allowlist for native command auth in groups by edwluo · Pull Request #39267 · openclaw/openclaw

edwluo · 2026-03-07T23:42:21Z

Summary

Native slash commands (/status, /model, /new, etc.) in Telegram supergroups and forum topics reject authorized senders with "You are not authorized to use this command." even when the sender is in groupAllowFrom.
Root cause: resolveTelegramCommandAuth only passes the DM allowlist as an authorizer to resolveCommandAuthorizedFromAuthorizers, ignoring effectiveGroupAllow.
Fix: add effectiveGroupAllow as a second authorizer when the message originates from a group. resolveCommandAuthorizedFromAuthorizers uses .some(), so either DM or group allowlist matching is sufficient and matches regular message auth behavior.

What changed

src/telegram/bot-native-commands.ts

// Before: only DM allowlist
authorizers: [{ configured: dmAllow.hasEntries, allowed: senderAllowed }],

// After: DM allowlist + group allowlist for group contexts
const groupSenderAllowed = isGroup
  ? isSenderAllowed({ allow: effectiveGroupAllow, senderId, senderUsername })
  : false;
authorizers: [
  { configured: dmAllow.hasEntries, allowed: senderAllowed },
  ...(isGroup
    ? [{ configured: effectiveGroupAllow.hasEntries, allowed: groupSenderAllowed }]
    : []),
],

What did NOT change

DM command authorization
commands.allowFrom precedence behavior
evaluateTelegramGroupBaseAccess and evaluateTelegramGroupPolicyAccess

Test plan

New regression test in src/telegram/bot-native-commands.group-auth.test.ts
Verified group native command auth when sender is only in group allowlist
Verified the test uses useAccessGroups: true so it exercises the actual bug path

Reproduction

Configure a Telegram supergroup with groupAllowFrom: [userId] but no top-level allowFrom
Send /status in a forum topic or group
Before fix: "You are not authorized to use this command."
After fix: command executes normally

Context

This bug is separate from commands.allowFrom precedence drift. Earlier attempts #29230 and #30272 covered the same root cause; this PR is the active fix path for the effectiveGroupAllow group-auth bug.

Fixes #30234
Related #29135
Related #28216

greptile-apps · 2026-03-07T23:44:49Z

Greptile Summary

This PR fixes a bug where native Telegram slash commands (e.g. /status, /model) rejected authorized senders in supergroups when the sender was listed in groupAllowFrom but not in the DM-level allowFrom. The root cause was that resolveTelegramCommandAuth only passed the DM allowlist to resolveCommandAuthorizedFromAuthorizers, ignoring effectiveGroupAllow entirely for command authorization (even though the earlier evaluateTelegramGroupBaseAccess / evaluateTelegramGroupPolicyAccess calls already used it correctly).

Key changes:

bot-native-commands.ts: Appends effectiveGroupAllow as a second CommandAuthorizer entry when the message is from a group, mirroring how regular message auth works.
bot-native-commands.group-auth.test.ts: New test file for the group-auth scenario.

Issue found:

The first (positive) test case — "authorizes native commands in groups when sender is in groupAllowFrom" — uses the default useAccessGroups: false. Under that flag, resolveCommandAuthorizedFromAuthorizers takes the "configured" path: when no DM allowlist is configured, anyConfigured = false → the function returns true unconditionally, even without the fix. This means the test would have passed on the unpatched code, making it an ineffective regression guard. Adding useAccessGroups: true to that test is needed for it to actually exercise the bug path.

Confidence Score: 4/5

The implementation fix is correct and safe to merge; the test gap is a coverage concern but doesn't affect production behaviour.
The core fix in bot-native-commands.ts is logically sound and correctly mirrors existing group-auth behaviour elsewhere in the file. The only notable issue is that the primary positive test case doesn't use useAccessGroups: true, so it would have passed even on the pre-fix code — it doesn't actually guard against a regression of this specific bug. The production fix itself is correct.
src/telegram/bot-native-commands.group-auth.test.ts — the first test needs useAccessGroups: true to be a meaningful regression guard.

_{Last reviewed commit: a0abf3e}

src/telegram/bot-native-commands.group-auth.test.ts

edwluo · 2026-03-07T23:46:27Z

Good catch — updated the first test case to use useAccessGroups: true so it exercises the actual bug path. Force-pushed.

Native slash commands (/status, /model, etc.) in Telegram supergroups and forum topics reject authorized senders with "not authorized" even when the sender is in groupAllowFrom. The bug is in resolveTelegramCommandAuth — the final commandAuthorized check only passes DM allowFrom as an authorizer, so senders who are authorized via groupAllowFrom get rejected. Regular messages don't have this problem because they go through evaluateTelegramGroupPolicyAccess which correctly uses effectiveGroupAllow. Add effectiveGroupAllow as a second authorizer when the message comes from a group. resolveCommandAuthorizedFromAuthorizers uses .some(), so either DM or group allowlist matching is sufficient. Fixes #28216 Fixes #29135 Fixes #30234

Remove explicit tuple type annotations on mock.calls.filter() callbacks that conflicted with vitest's mock call types. Co-Authored-By: Claude Opus 4.6 <[email protected]>

vincentkoc · 2026-03-08T00:43:25Z

Rebased onto current main and tightened the coverage before merge.

What changed on top of the existing fix:

kept the scope on Telegram native command auth in groups checks DM allowlist instead of groupAllowFrom #30234 only; no commands.allowFrom work from Telegram native command handler ignores commands.allowFrom in group chats #28216 folded in
added a forum-topic regression check so auth rejection replies stay in the originating topic thread
added the changelog entry in the active 2026.3.7 fixes block

Re-ran:

bunx vitest run src/telegram/bot-native-commands.group-auth.test.ts src/telegram/bot-native-commands.session-meta.test.ts src/telegram/bot-native-commands.plugin-auth.test.ts

…penclaw#39267) * fix(telegram): use group allowlist for native command auth in groups Native slash commands (/status, /model, etc.) in Telegram supergroups and forum topics reject authorized senders with "not authorized" even when the sender is in groupAllowFrom. The bug is in resolveTelegramCommandAuth — the final commandAuthorized check only passes DM allowFrom as an authorizer, so senders who are authorized via groupAllowFrom get rejected. Regular messages don't have this problem because they go through evaluateTelegramGroupPolicyAccess which correctly uses effectiveGroupAllow. Add effectiveGroupAllow as a second authorizer when the message comes from a group. resolveCommandAuthorizedFromAuthorizers uses .some(), so either DM or group allowlist matching is sufficient. Fixes openclaw#28216 Fixes openclaw#29135 Fixes openclaw#30234 * fix(test): resolve TS2769 type errors in group-auth test Remove explicit tuple type annotations on mock.calls.filter() callbacks that conflicted with vitest's mock call types. Co-Authored-By: Claude Opus 4.6 <[email protected]> * test(telegram): cover topic auth rejection routing * changelog: note telegram native group command auth fix --------- Co-authored-by: Claude Opus 4.6 <[email protected]> Co-authored-by: Vincent Koc <[email protected]>

SanderHelgesen · 2026-03-11T06:48:45Z

Still reproducing on 2026.3.8 with groupPolicy: "open" and no groupAllowFrom set.

Config:

{
  "channels": {
    "telegram": {
      "groupPolicy": "open",
      "groups": {
        "-100xxx": {
          "requireMention": false,
          "topics": { ... }
        }
      }
    }
  }
}

Native commands (/status, /elevated, /commands) in forum topics still return "You are not authorized to use this command." — the fix seems to only resolve the case where groupAllowFrom is explicitly configured. When groupPolicy: "open" is used without an allowlist, the group authorizer has configured: false and resolveCommandAuthorizedFromAuthorizers still denies.

Paired DM user (owner) is authorized for everything in DMs and regular group messages work fine — only native slash commands are rejected.

+1 on reopening or tracking separately.

…penclaw#39267) * fix(telegram): use group allowlist for native command auth in groups Native slash commands (/status, /model, etc.) in Telegram supergroups and forum topics reject authorized senders with "not authorized" even when the sender is in groupAllowFrom. The bug is in resolveTelegramCommandAuth — the final commandAuthorized check only passes DM allowFrom as an authorizer, so senders who are authorized via groupAllowFrom get rejected. Regular messages don't have this problem because they go through evaluateTelegramGroupPolicyAccess which correctly uses effectiveGroupAllow. Add effectiveGroupAllow as a second authorizer when the message comes from a group. resolveCommandAuthorizedFromAuthorizers uses .some(), so either DM or group allowlist matching is sufficient. Fixes openclaw#28216 Fixes openclaw#29135 Fixes openclaw#30234 * fix(test): resolve TS2769 type errors in group-auth test Remove explicit tuple type annotations on mock.calls.filter() callbacks that conflicted with vitest's mock call types. Co-Authored-By: Claude Opus 4.6 <[email protected]> * test(telegram): cover topic auth rejection routing * changelog: note telegram native group command auth fix --------- Co-authored-by: Claude Opus 4.6 <[email protected]> Co-authored-by: Vincent Koc <[email protected]>

…penclaw#39267) * fix(telegram): use group allowlist for native command auth in groups Native slash commands (/status, /model, etc.) in Telegram supergroups and forum topics reject authorized senders with "not authorized" even when the sender is in groupAllowFrom. The bug is in resolveTelegramCommandAuth — the final commandAuthorized check only passes DM allowFrom as an authorizer, so senders who are authorized via groupAllowFrom get rejected. Regular messages don't have this problem because they go through evaluateTelegramGroupPolicyAccess which correctly uses effectiveGroupAllow. Add effectiveGroupAllow as a second authorizer when the message comes from a group. resolveCommandAuthorizedFromAuthorizers uses .some(), so either DM or group allowlist matching is sufficient. Fixes openclaw#28216 Fixes openclaw#29135 Fixes openclaw#30234 * fix(test): resolve TS2769 type errors in group-auth test Remove explicit tuple type annotations on mock.calls.filter() callbacks that conflicted with vitest's mock call types. Co-Authored-By: Claude Opus 4.6 <[email protected]> * test(telegram): cover topic auth rejection routing * changelog: note telegram native group command auth fix --------- Co-authored-by: Claude Opus 4.6 <[email protected]> Co-authored-by: Vincent Koc <[email protected]> (cherry picked from commit 02eef1d)

openclaw-barnacle bot added channel: telegram Channel integration: telegram size: S labels Mar 7, 2026

This was referenced Mar 7, 2026

Telegram: slash commands return 'not authorized' in forum topic chats #29135

Closed

Telegram native command auth in groups checks DM allowlist instead of groupAllowFrom #30234

Closed

greptile-apps bot reviewed Mar 7, 2026

View reviewed changes

src/telegram/bot-native-commands.group-auth.test.ts Show resolved Hide resolved

edwluo force-pushed the fix/telegram-group-command-auth branch from a0abf3e to beaf15b Compare March 7, 2026 23:46

vincentkoc self-assigned this Mar 8, 2026

edwluo and others added 4 commits March 7, 2026 16:41

fix(test): resolve TS2769 type errors in group-auth test

eea6a67

Remove explicit tuple type annotations on mock.calls.filter() callbacks that conflicted with vitest's mock call types. Co-Authored-By: Claude Opus 4.6 <[email protected]>

test(telegram): cover topic auth rejection routing

4d34abe

changelog: note telegram native group command auth fix

18f0a7a

vincentkoc force-pushed the fix/telegram-group-command-auth branch from d26991a to 18f0a7a Compare March 8, 2026 00:43

Merge branch 'main' into fix/telegram-group-command-auth

9775b12

vincentkoc merged commit 02eef1d into openclaw:main Mar 8, 2026
27 of 28 checks passed

This was referenced Mar 8, 2026

Telegram native command handler ignores commands.allowFrom in group chats #28216

Closed

fix(telegram): honor commands.allowFrom in native command auth #39310

Merged

github-actions bot mentioned this pull request Mar 8, 2026

📡 Upstream Digest — 2026-03-08 01:21 UTC curtismercier/openclaw-mods#206

Open

github-actions bot mentioned this pull request Mar 8, 2026

上游更新: v2026.3.7 — 19 P0 + 122 P1 待合并 jiulingyun/openclaw-cn#486

Open

alexey-pelykh mentioned this pull request Mar 10, 2026

Cherry-pick: upstream src misc updates (21 commits) remoteclaw/remoteclaw#876

Closed

4 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix(telegram): use group allowlist for native command auth in groups#39267

fix(telegram): use group allowlist for native command auth in groups#39267
vincentkoc merged 5 commits intoopenclaw:mainfrom
edwluo:fix/telegram-group-command-auth

edwluo commented Mar 7, 2026 •

edited by vincentkoc

Loading

Uh oh!

greptile-apps bot commented Mar 7, 2026

Uh oh!

Uh oh!

edwluo commented Mar 7, 2026

Uh oh!

vincentkoc commented Mar 8, 2026

Uh oh!

Uh oh!

SanderHelgesen commented Mar 11, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

edwluo commented Mar 7, 2026 • edited by vincentkoc Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

What changed

What did NOT change

Test plan

Reproduction

Context

Uh oh!

greptile-apps bot commented Mar 7, 2026

Greptile Summary

Confidence Score: 4/5

Uh oh!

Uh oh!

edwluo commented Mar 7, 2026

Uh oh!

vincentkoc commented Mar 8, 2026

Uh oh!

Uh oh!

SanderHelgesen commented Mar 11, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

edwluo commented Mar 7, 2026 •

edited by vincentkoc

Loading