Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix Plugin slash-command autocomplete drops namespace prefix on accept [2 comments, 3 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
anthropics/claude-code#54829•Fetched 2026-04-30 06:34:46
View on GitHub
Comments
2
Participants
3
Timeline
6
Reactions
0
Author
MarbTrekMarbTrek
Participants
0xbrainkid0xbrainkidgithub-actions[bot]github-actions[bot]MarbTrekMarbTrek
Timeline (top)
labeled ×4commented ×2

The slash-command autocomplete UI shows the fully-qualified form for namespaced plugin skills (e.g. /shared:publish-package), but selecting that entry via tab/enter inserts the unprefixed form (/publish-package) into the chat input. The displayed form and inserted form should match.

Root Cause

The unprefixed form is inserted. This happens to work today only because no other installed plugin exposes a publish-package skill that would shadow the namespaced one. The moment two plugins expose a same-named skill, the unprefixed form becomes ambiguous and the namespaced form is the only correct way to invoke a specific one — but autocomplete still inserts without the prefix, so users can't easily disambiguate via the UI.

RAW_BUFFERClick to expand / collapse

Description

The slash-command autocomplete UI shows the fully-qualified form for namespaced plugin skills (e.g. /shared:publish-package), but selecting that entry via tab/enter inserts the unprefixed form (/publish-package) into the chat input. The displayed form and inserted form should match.

Repro

  1. Install a plugin that exposes namespaced skills (in this repo's case, our internal shared plugin exposes /shared:publish-package, /shared:wire-tier1, etc.)
  2. In the chat input, type /sh
  3. Autocomplete surfaces — the highlighted entry shows /shared:publish-package
  4. Press tab or enter to accept the highlighted entry
  5. The chat input is filled with /publish-package — the shared: prefix is dropped.

Expected

The chat input should be filled with the exact form shown in autocomplete: /shared:publish-package.

Actual

The unprefixed form is inserted. This happens to work today only because no other installed plugin exposes a publish-package skill that would shadow the namespaced one. The moment two plugins expose a same-named skill, the unprefixed form becomes ambiguous and the namespaced form is the only correct way to invoke a specific one — but autocomplete still inserts without the prefix, so users can't easily disambiguate via the UI.

Why it matters

Namespacing exists specifically to disambiguate across plugins. Stripping the prefix on accept defeats the namespacing mechanism — a user who chose the namespaced entry from autocomplete is signaling "I want this exact one," and that signal is being discarded.

Environment

  • OS: Windows 11 Pro 10.0.26200
  • Claude Code: latest as of 2026-04-29

extent analysis

TL;DR

The autocomplete UI for namespaced plugin skills should insert the fully-qualified form, including the namespace prefix, to maintain disambiguation across plugins.

Guidance

  • Verify that the autocomplete logic correctly handles namespaced skills by checking the code responsible for inserting the selected entry into the chat input.
  • Review the plugin registration process to ensure that namespaced skills are properly registered with their fully-qualified names.
  • Consider modifying the autocomplete insertion logic to preserve the namespace prefix when a namespaced skill is selected.
  • Test the fix with multiple plugins exposing same-named skills to ensure the namespaced form is correctly inserted and invoked.

Example

No code snippet is provided due to lack of specific implementation details.

Notes

The issue may be specific to the shared plugin or the autocomplete implementation, and further investigation is needed to determine the root cause.

Recommendation

Apply a workaround to modify the autocomplete insertion logic to preserve the namespace prefix, as upgrading to a fixed version is not mentioned as an option. This will ensure that users can correctly disambiguate between same-named skills from different plugins.

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…
#model loading#dependency error#configuration error#environment variable#network issue

Still need to ship something?

×6

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

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix Plugin slash-command autocomplete drops namespace prefix on accept [2 comments, 3 participants]