Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix [Feature]: tiered slash-command auth — session reset vs commands.allowFrom [1 comments, 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#61707•Fetched 2026-04-08 02:55:37
View on GitHub
Comments
1
Participants
1
Timeline
2
Reactions
0
Author
eightHundredseightHundreds
Participants
eightHundredseightHundreds
Timeline (top)
commented ×1renamed ×1

Tier slash-command authorization so session commands (/new, /reset) can remain available to channel-authorized chatters while commands.allowFrom restricts only elevated/admin-style commands.

Root Cause

Tier slash-command authorization so session commands (/new, /reset) can remain available to channel-authorized chatters while commands.allowFrom restricts only elevated/admin-style commands.

RAW_BUFFERClick to expand / collapse

Summary

Tier slash-command authorization so session commands (/new, /reset) can remain available to channel-authorized chatters while commands.allowFrom restricts only elevated/admin-style commands.

Problem to solve

When commands.allowFrom is set, it is the only authorization source for slash commands and directives (docs/tools/slash-commands.md). That cleanly separates “who can chat” from “who can run commands”, but it applies uniformly to every command, including /new and /reset.

Operators often want: many users in channels.*.allowFrom for collaboration, narrow commands.allowFrom for dangerous operations (/restart, /config, /plugins, …), but still let normal users reset their own session with /new / /reset. Today, listing only admins under commands.allowFrom blocks /new for everyone else, even though they are already allowed to message the bot.

Using only channels.*.allowFrom + commands.ownerAllowFrom does not match this mental model either (ownerAllowFrom affects owner identity and many command paths beyond “session reset vs admin”).

PR #12430 (introducing commands.allowFrom) even listed /new alongside /approve, /exec as examples of restricted commands — which encodes /new as privileged; many deployments would rather treat it as baseline for anyone who may chat (with possible group-specific limits).

Proposed solution

Add explicit product support for at least two tiers of slash authorization, for example:

  1. Baseline commands (exact list TBD): always allowed for senders who already pass channel auth (commandAuthorized), e.g. /new, /reset, optionally /whoami / /status.
  2. Elevated commands: require membership in commands.allowFrom (current behavior), e.g. /restart, /config, /mcp, /plugins, …

Alternatively: keep a single commands.allowFrom but add something like commands.allowFromElevatedOnly: true or commands.baselineCommands: ["/new", "/reset"] — exact shape is for maintainers.

Alternatives considered

  • Status quo: document that operators must choose between “open chat + everyone can run all slash commands (via channel allowFrom)” vs “restricted commands + /new blocked for non-listed users”. This avoids new config but keeps the UX/security tension described above.
  • Process-only: tell users to avoid commands.allowFrom and rely on commands.restart: false, commands.config: false, etc. That reduces blast radius but does not solve coarse isAuthorizedSender gating for /new.
  • Only use ownerAllowFrom: does not cleanly express “everyone can /new, only owners can restart” without side effects on other owner-gated surfaces (as discussed in community issues around senderIsOwner / wildcards).

Impact

  • Affected: Multi-user Feishu/Slack/Discord/etc. deployments where chat is shared or allowlists include collaborators, and operators want command restrictions without blocking session reset.
  • Severity: Medium — does not block single-user setups; blocks a common “collaboration + least privilege” layout.
  • Frequency: Whenever commands.allowFrom is used as intended (#12430), operators hit the “/new is also restricted” tradeoff.
  • Consequence: Either weaker command lockdown (broader commands.allowFrom) or frustrated users who cannot /new despite being allowed to chat.

Evidence/examples

  • docs/tools/slash-commands.md: commands.allowFrom is the only command auth source when configured.
  • PR #12430: motivation and examples grouping /new with other restricted commands.
  • Prior confusion around commands.ownerAllowFrom vs senderIsOwner / wildcards (e.g. #25286, #26331) shows the authorization model is already hard to reason about; tiering should be designed to reduce—not increase—ambiguity.

Additional information

  • Implementation touchpoints likely include src/auto-reply/command-auth.ts (isAuthorizedSender) and per-command handlers that already branch on isAuthorizedSender vs senderIsOwner.
  • Group chats may need stricter defaults for baseline /new (anti-griefing) vs DMs; product should decide.

extent analysis

TL;DR

Implement a two-tiered authorization system for slash commands, allowing certain commands like /new and /reset to be accessible to users who pass channel authentication, while restricting elevated commands to users listed in commands.allowFrom.

Guidance

  • Introduce a new configuration option, such as commands.baselineCommands, to specify which commands should be allowed for users who pass channel authentication.
  • Update the isAuthorizedSender function in src/auto-reply/command-auth.ts to check for both commands.allowFrom and the new commands.baselineCommands configuration.
  • Consider adding stricter defaults for baseline commands in group chats to prevent griefing.
  • Review and update per-command handlers to branch on the new authorization logic.

Example

// src/auto-reply/command-auth.ts
function isAuthorizedSender(sender, command) {
  if (commands.baselineCommands.includes(command)) {
    return isChannelAuthorized(sender);
  } else {
    return isAllowFromAuthorized(sender);
  }
}

Notes

The implementation details may vary depending on the specific requirements and constraints of the project. It's essential to consider the potential impact on existing configurations and user experiences.

Recommendation

Apply a workaround by introducing a new configuration option, such as commands.baselineCommands, to specify which commands should be allowed for users who pass channel authentication. This approach allows for a more fine-grained control over command authorization without requiring significant changes to the existing codebase.

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…
#database connection#vector store#embedding generation#cache error#pipeline error

Still need to ship something?

×6

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

Back to top recommendations

TRENDING