Bug type

Behavior bug (incorrect CLI diagnostic / UX)

Summary

The narrow fix from #64732 (commit 82a8006f77) added the singular tool token to the reserved-non-plugin list, but the generic non-plugin classification layer that the issue's own Codex review recommended was not implemented. As a result, any unknown CLI subcommand still hits the missing-plugin fallback and emits the misleading "add to plugins.allow" guidance — even for clearly nonsensical tokens that could not possibly be plugin IDs.

This wastes operator time chasing nonexistent plugins. I just spent a Claude Code session being told to add approval (singular — there is no such bundled plugin) to my allowlist; cross-checking the bundled dist/extensions/ directory and openclaw plugins list --json confirmed no such plugin exists. The error message is the only signal, and it's actively misleading.

Steps to reproduce

On a 2026.5.7 install with a populated plugins.allow:

$ openclaw nonexistent-fake-command --help
[openclaw] Failed to start CLI: Error: The `openclaw nonexistent-fake-command` command is unavailable because `plugins.allow` excludes "nonexistent-fake-command". Add "nonexistent-fake-command" to `plugins.allow` if you want that bundled plugin CLI surface.
    at runCli (file:///.../dist/cli/run-main.js:460:46)
    at async runMainOrRootHelp (file:///.../dist/entry.js:468:3)
    at async file:///.../dist/entry.js:438:55

The same error fires for openclaw approval, openclaw foo, openclaw qzlmop, etc. — anything not in the registered command set or manifest aliases.

Expected behavior

Truly unknown tokens (no bundled plugin, no manifest alias, no reserved-non-plugin entry) should fall through to a Commander-style "unknown command" diagnostic with a "did-you-mean" suggestion against the registered command set, not suggest adding the token to plugins.allow.

This matches what #64732's review explicitly called the "best possible solution":

Add an explicit CLI command classification layer before plugin allowlist diagnostics: framework/core/reserved non-plugin names should never suggest adding themselves to plugins.allow, manifest CLI aliases should resolve to the owning plugin ID, runtime slash aliases should explain chat-only usage or point to the related CLI command, and truly unknown commands should fall through to Commander-style unknown-command handling.

Actual behavior

The token is normalized as a plugin ID candidate and resolveMissingPluginCommandMessage() (see src/cli/run-main-policy.ts:155 per the #64732 review) returns the misleading allowlist guidance. The reserved-non-plugin set added in 82a8006f77 only covers tool; everything else still gets routed into this fallback.

Impact

• Operators with strict plugins.allow configs (recommended for supply-chain hardening, per bundledDiscovery: "compat" + explicit allowlist) see this error frequently as they explore the CLI surface.
• The error directly suggests modifying a security-relevant config (plugins.allow) to "fix" something that is not actually a plugin allowlist problem. This is the worst possible failure mode for a security knob: a misleading prompt to weaken it.
• Diagnostic time is spent verifying whether the suggested plugin actually exists (it usually doesn't).

OpenClaw version

2026.5.7 (eeef486)

Operating system

Arch Linux

Install method

npm global

Suggested fix

Implement the classification layer #64732's review described, in priority order:

1. Truly unknown primary tokens (no plugin, no manifest alias, no reserved entry) → Commander unknown-command output with did-you-mean against the registered command set.
2. Manifest alias tokens → resolve to owning plugin ID and emit guidance pointing at that plugin ID, not the alias.
3. Reserved non-plugin tokens → already handled for tool post-82a8006f77; this list will need to grow as new reserved tokens appear, but should be the smallest of the three branches.

The current narrow fix to add tokens to the reserved list one at a time will not scale and was already flagged in the original review as not the best solution.

Related

• #64732 (closed) — canonical tracker, narrow fix only covered tool
• #77183 (closed) — same misleading-error pattern for lcm
• #65319 (open) — adjacent slash-alias case for /lossless
• #64242, #64779 — earlier alias-diagnostics fixes (manifest-owned commands)

Trailers per Linux kernel coding-assistant policy:

Signed-off-by: Lance [email protected] Assisted-by: Claude-Code:claude-opus-4-7