Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Control UI slash command autocomplete doesn't show workspace/user-invocable skills [1 pull requests, 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#59152•Fetched 2026-04-08 02:28:03
View on GitHub
Comments
0
Participants
1
Timeline
0
Reactions
0
Author
scott-xscott-x
Participants
scott-xscott-x

Root Cause

The slash menu items in the Control UI frontend are statically compiled — the dm array is hard-coded at build time and only includes built-in commands + /clear:

var dm = [...Zp().map(um).filter(...), ...em]

Zp() returns the built-in command list, and em only has /clear.

The gateway does know about user-invocable skills at runtime, but the frontend doesn't query this information to populate the autocomplete dynamically.

Fix Action

Fix / Workaround

Current Workaround

PR fix notes

PR #64736: fix(ui): load runtime command catalog for slash autocomplete

Description (problem / solution / changelog)

Summary

  • Problem: Control UI slash autocomplete and the command palette used a static built-in command list, so user-invocable workspace skills never appeared even though they worked when typed manually.
  • Why it matters: operators could not discover runtime skill commands from the web UI, and the UI command surfaces drifted from the actual gateway command registry.
  • What changed: added a read-only commands.list gateway RPC, then switched Control UI slash autocomplete, local /help, and the command palette to consume that runtime catalog with a local /clear fallback.
  • What did NOT change (scope boundary): this PR does not change Discord/Telegram/Slack native slash-command registration.

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 #59152
  • Related #63671
  • This PR fixes a bug or regression

Root Cause (if applicable)

  • Root cause: the Control UI slash menu and command palette were built from a compile-time static list instead of the runtime command registry that already knows about config-gated built-ins and user-invocable workspace skills.
  • Missing detection / guardrail: there was no gateway-facing command catalog contract and no UI regression test that asserted dynamic skill commands show up in slash discovery surfaces.
  • Contributing context (if known): a few existing type/test blockers were also preventing pnpm check and pnpm build, so this branch includes the minimal fixes needed to get the repo gates green again.

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/gateway/server-methods/commands.test.ts
  • ui/src/ui/controllers/commands.test.ts
  • ui/src/ui/chat/slash-commands.node.test.ts
  • ui/src/ui/views/command-palette.test.ts
  • ui/src/ui/chat/slash-command-executor.node.test.ts
  • Scenario the test should lock in: runtime user-invocable skill commands are present in the gateway command catalog and are consumed by Control UI slash autocomplete, local help, and the command palette while /clear still works as a UI-local fallback.
  • Why this is the smallest reliable guardrail: the bug lives at the gateway-to-Control-UI contract seam, so unit coverage on only one side would miss the drift.
  • Existing test that already covers this (if any): none.
  • If no new test is added, why not: N/A.

User-visible / Behavior Changes

  • Typing / in Control UI chat now shows runtime user-invocable workspace skills in addition to built-in slash commands.
  • Control UI local /help output now includes the same runtime-discovered commands.
  • The command palette now uses the same runtime command catalog, so slash discovery is consistent across UI surfaces.

Diagram (if applicable)

Before:
[user types /] -> [static built-in list] -> [workspace skills missing]

After:
[user types /] -> [gateway commands.list] -> [runtime command catalog] -> [built-ins + user-invocable skills]
                                                  \-> [local /clear fallback stays available]

Security Impact (required)

  • New permissions/capabilities? (Yes/No) No
  • Secrets/tokens handling changed? (Yes/No) No
  • New/changed network calls? (Yes/No) Yes
  • Command/tool execution surface changed? (Yes/No) No
  • Data access scope changed? (Yes/No) No
  • If any Yes, explain risk + mitigation: adds a new read-only operator-scoped gateway RPC (commands.list) that exposes command metadata already derivable from the runtime registry; no secrets or new execution capability are exposed.

Repro + Verification

Environment

  • OS: macOS
  • Runtime/container: local dev workspace, Node 24 / pnpm 10
  • Model/provider: N/A
  • Integration/channel (if any): Control UI webchat
  • Relevant config (redacted): workspace skills with user-invocable: true

Steps

  1. Add or enable a workspace skill with user-invocable: true.
  2. Open Control UI chat and type /.
  3. Inspect slash autocomplete, /help, and the command palette.

Expected

  • Runtime skill commands appear alongside built-ins.

Actual

  • Before this change only static built-ins appeared; runtime skill commands were missing.

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:
    • Ran pnpm test src/gateway/server-methods/commands.test.ts ui/src/ui/controllers/commands.test.ts ui/src/ui/chat/slash-commands.node.test.ts ui/src/ui/views/command-palette.test.ts ui/src/ui/app-render.helpers.node.test.ts ui/src/ui/controllers/skills.test.ts ui/src/ui/chat/slash-command-executor.node.test.ts ui/src/ui/app-chat.test.ts
    • Ran pnpm check
    • Ran npm_config_cache=$(mktemp -d /tmp/openclaw-npm-cache-XXXXXX) pnpm build
  • Edge cases checked:
    • unknown agent rejection for commands.list
    • stale command-catalog responses after agent/session switches
    • fallback to static commands when the runtime catalog is unavailable
    • local /clear remains available
  • What you did not verify:
    • manual browser clicking in a live Control UI session
    • native slash-command registration on non-web channels

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/No) Yes
  • Config/env changes? (Yes/No) No
  • Migration needed? (Yes/No) No
  • If yes, exact upgrade steps: N/A

Risks and Mitigations

  • Risk: the UI could drift again if future command metadata is added only on one side.
    • Mitigation: the new RPC is the shared source of truth and is covered by gateway/UI regression tests.
  • Risk: adding a new operator-read RPC broadens the control-plane surface slightly.
    • Mitigation: it is read-only, scope-gated, and only returns command metadata.

Changed files

  • ui/src/ui/app-chat.test.ts (modified, +6/-0)
  • ui/src/ui/app-chat.ts (modified, +27/-4)
  • ui/src/ui/app-gateway.node.test.ts (modified, +72/-0)
  • ui/src/ui/app-gateway.ts (modified, +18/-0)
  • ui/src/ui/app-render.helpers.node.test.ts (modified, +56/-7)
  • ui/src/ui/app-render.helpers.ts (modified, +20/-1)
  • ui/src/ui/app-render.ts (modified, +14/-5)
  • ui/src/ui/app-view-state.ts (modified, +7/-0)
  • ui/src/ui/app.ts (modified, +16/-5)
  • ui/src/ui/chat/slash-command-executor.node.test.ts (modified, +32/-0)
  • ui/src/ui/chat/slash-command-executor.ts (modified, +6/-4)
  • ui/src/ui/chat/slash-commands.node.test.ts (modified, +145/-1)
  • ui/src/ui/chat/slash-commands.ts (modified, +97/-12)
  • ui/src/ui/controllers/commands.test.ts (added, +195/-0)
  • ui/src/ui/controllers/commands.ts (added, +71/-0)
  • ui/src/ui/controllers/skills.test.ts (modified, +2/-0)
  • ui/src/ui/controllers/skills.ts (modified, +2/-0)
  • ui/src/ui/types.ts (modified, +39/-0)
  • ui/src/ui/views/chat.test.ts (modified, +44/-0)
  • ui/src/ui/views/chat.ts (modified, +48/-6)
  • ui/src/ui/views/command-palette.test.ts (added, +33/-0)
  • ui/src/ui/views/command-palette.ts (modified, +34/-19)

Code Example

var dm = [...Zp().map(um).filter(...), ...em]
RAW_BUFFERClick to expand / collapse

Problem

The Control UI (webchat) slash command autocomplete (/ triggered dropdown) only shows hard-coded built-in commands like /help, /status, /new, etc.

It does NOT show workspace skills that have user-invocable: true in their SKILL.md frontmatter — even though the gateway correctly loads those skills and they work when invoked directly via /skill <name> or by typing the full command.

Expected Behavior

When the user types / in the Control UI chat input, the autocomplete dropdown should show:

  1. All built-in slash commands
  2. All workspace skills with user-invocable: true

Current Workaround

Users can still invoke workspace skills by typing the full command (e.g., /skill office-hours), but they get no autocomplete suggestions.

Root Cause

The slash menu items in the Control UI frontend are statically compiled — the dm array is hard-coded at build time and only includes built-in commands + /clear:

var dm = [...Zp().map(um).filter(...), ...em]

Zp() returns the built-in command list, and em only has /clear.

The gateway does know about user-invocable skills at runtime, but the frontend doesn't query this information to populate the autocomplete dynamically.

Suggested Fix

Option A (easiest): Make the Control UI fetch the list of user-invocable skills from the gateway (e.g., via tools.catalog or a new skills.list endpoint) and merge them into the dm array at session start.

Option B (proper fix): Register workspace user-invocable skills as native commands on the gateway, same way Discord/Telegram native commands work, so all surfaces automatically get them without frontend changes.

Environment

  • OpenClaw version: 2026.3.22
  • Control UI (webchat)
  • Channel: Feishu webchat
  • Workspace skills with user-invocable: true (30+ skills, e.g. gstack suite)

extent analysis

TL;DR

To fix the autocomplete issue, the Control UI frontend should fetch the list of user-invocable skills from the gateway and merge them into the dm array at session start.

Guidance

  • The current implementation only includes hard-coded built-in commands in the autocomplete dropdown, which is why workspace skills are not shown.
  • To verify the fix, check that the autocomplete dropdown includes both built-in commands and workspace skills with user-invocable: true after implementing the suggested fix.
  • The gateway already knows about user-invocable skills at runtime, so the frontend just needs to query this information to populate the autocomplete dynamically.
  • Consider implementing Option A (fetching the list of user-invocable skills from the gateway) as the easiest solution, or Option B (registering workspace user-invocable skills as native commands on the gateway) for a more comprehensive fix.

Example

// Example of how to fetch user-invocable skills from the gateway and merge them into the dm array
const userInvocableSkills = await fetchSkillsFromGateway();
const dm = [...Zp().map(um).filter(...), ...em, ...userInvocableSkills];

Notes

The suggested fix assumes that the gateway provides an endpoint to fetch the list of user-invocable skills, such as tools.catalog or a new skills.list endpoint.

Recommendation

Apply workaround by implementing Option A, as it is the easiest solution to fetch the list of user-invocable skills from the gateway and merge them into the dm array at session start. This will provide a quick fix to the autocomplete issue without requiring significant changes to the gateway or frontend.

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…
#index setup#retrieval issue#search optimization#API routing#API middleware

Still need to ship something?

×6

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

Back to top recommendations

TRENDING