claude-code - 💡(How to fix) Fix Feature: Native plugin UI dialogs (like /mcp) for third-party plugins

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…

Claude Code has a polished native UI dialog for /mcp — users can browse, select, and interact with MCP servers without any AI response. Third-party plugins have no equivalent. They are limited to systemMessage injection and Claude chat responses, which forces every plugin interaction through the AI layer even when it's unnecessary.

Root Cause

  • Token efficiency — UI tasks (pick a service, browse topics) don't need AI. Routing them through Claude wastes context and adds latency.
  • Plugin quality ceiling — right now all plugins feel like "AI wrappers". Native UI primitives would enable plugins that feel like real tools.
  • Consistency/mcp, /help, /config all have native UI. Third-party plugins should have the same capability.
  • Ecosystem growth — developer tools (doc browsers, API explorers, schema viewers) are natural Claude Code plugins but can't be built well today.

Fix Action

Fix / Workaround

  • quickdocs — example plugin blocked by this limitation
  • Current workaround: hook + skill + Claude response (3-layer hack for what should be 1 native call)

Code Example

{
  "dialog": {
    "type": "list",
    "title": "Select a service",
    "items": [
      { "label": "Stripe — Payment APIs", "value": "stripe" },
      { "label": "Vercel — Frontend cloud", "value": "vercel" }
    ],
    "onSelect": "bash /path/to/plugin/hooks/on-select.sh"
  }
}

---

{
  "commands": {
    "/docs": {
      "steps": [
        { "type": "list", "source": "bash plugin/hooks/list-services.sh" },
        { "type": "list", "source": "bash plugin/hooks/list-topics.sh --service=$SELECTION" }
      ],
      "onComplete": "inject-context"
    }
  }
}

---

{
  "userMessage": "Here are your docs:\n\n...",
  "suppressAiResponse": true
}
RAW_BUFFERClick to expand / collapse

Summary

Claude Code has a polished native UI dialog for /mcp — users can browse, select, and interact with MCP servers without any AI response. Third-party plugins have no equivalent. They are limited to systemMessage injection and Claude chat responses, which forces every plugin interaction through the AI layer even when it's unnecessary.

Problem

Today, plugins can only interact with users via:

  • systemMessage — silent context injection (user sees nothing directly)
  • Skill + Claude response — AI processes and responds (slow, wastes tokens, feels wrong for pure UI tasks)

This makes it impossible to build plugins with clean, immediate UI like:

  • Documentation browsers (/docs → pick service → pick topic → docs injected)
  • Service pickers, config wizards, command palettes
  • Anything that should be instant and deterministic, not AI-generated

Real example: I built quickdocs — a documentation fetcher that injects official docs into Claude context. The CLI has a great arrow-key interactive picker. Inside Claude Code, the best I can do is a skill that asks Claude to show a numbered list and wait — which still goes through the AI, wastes tokens, and feels sluggish compared to /mcp.

Proposed Solution

Expose a plugin UI primitive — a simple dialog/picker that plugins can trigger natively, similar to how /mcp works internally.

Option A: dialog hook output type

Allow hooks to return a dialog response that Claude Code renders natively:

{
  "dialog": {
    "type": "list",
    "title": "Select a service",
    "items": [
      { "label": "Stripe — Payment APIs", "value": "stripe" },
      { "label": "Vercel — Frontend cloud", "value": "vercel" }
    ],
    "onSelect": "bash /path/to/plugin/hooks/on-select.sh"
  }
}

Option B: Plugin-registered slash commands with native rendering

Allow plugins to register slash commands that render a native UI step before passing to Claude:

{
  "commands": {
    "/docs": {
      "steps": [
        { "type": "list", "source": "bash plugin/hooks/list-services.sh" },
        { "type": "list", "source": "bash plugin/hooks/list-topics.sh --service=$SELECTION" }
      ],
      "onComplete": "inject-context"
    }
  }
}

Option C: Minimal — just expose a userVisible output from hooks

Hooks currently inject systemMessage (silent). Add a userMessage field that renders directly in the chat UI without requiring a Claude response:

{
  "userMessage": "Here are your docs:\n\n...",
  "suppressAiResponse": true
}

Why This Matters

  • Token efficiency — UI tasks (pick a service, browse topics) don't need AI. Routing them through Claude wastes context and adds latency.
  • Plugin quality ceiling — right now all plugins feel like "AI wrappers". Native UI primitives would enable plugins that feel like real tools.
  • Consistency/mcp, /help, /config all have native UI. Third-party plugins should have the same capability.
  • Ecosystem growth — developer tools (doc browsers, API explorers, schema viewers) are natural Claude Code plugins but can't be built well today.

References

  • quickdocs — example plugin blocked by this limitation
  • Current workaround: hook + skill + Claude response (3-layer hack for what should be 1 native call)

extent analysis

TL;DR

Exposing a plugin UI primitive, such as a native dialog or picker, would allow third-party plugins to interact with users more efficiently and effectively.

Guidance

  • Consider implementing one of the proposed solutions: dialog hook output type, plugin-registered slash commands with native rendering, or exposing a userVisible output from hooks.
  • Evaluate the trade-offs between these options, including complexity, flexibility, and potential use cases.
  • Assess the potential impact on token efficiency, plugin quality, and ecosystem growth.
  • Review the example plugin, quickdocs, to understand the current limitations and potential benefits of a native UI primitive.

Example

{
  "dialog": {
    "type": "list",
    "title": "Select a service",
    "items": [
      { "label": "Stripe — Payment APIs", "value": "stripe" },
      { "label": "Vercel — Frontend cloud", "value": "vercel" }
    ],
    "onSelect": "bash /path/to/plugin/hooks/on-select.sh"
  }
}

This example illustrates the proposed dialog hook output type, which could enable plugins to render native UI components.

Notes

The best approach will depend on the specific requirements and constraints of the Claude Code platform and its ecosystem. It is essential to carefully evaluate the potential benefits and challenges of each proposed solution.

Recommendation

Apply a workaround by exposing a userVisible output from hooks, as this seems to be the most minimal and straightforward solution to improve the plugin UI experience. This approach would allow plugins to render direct user messages without requiring a Claude response, enhancing token efficiency and plugin quality.

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…

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 Feature: Native plugin UI dialogs (like /mcp) for third-party plugins