[FEATURE]:Allow plugins to intercept slash commands and return results directly (skip LLM), plus register custom dialogs

[graoke]

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Feature Request: Allow plugins to intercept slash commands and return results directly (skip LLM), plus register custom dialogs

Problem
Currently, plugins can hook into slash command execution via command.execute.before, but they have no way to prevent the command from being sent to the LLM after the hook runs. The only workaround is throwing an error in the hook, which is hacky and produces a poor UX.
Additionally, external plugins cannot register TUI-level palette commands with custom dialogs (like /models does with DialogModel). Dialog-based interactions — browsing, selecting, confirming — are exclusive to opencode's built-in commands.
These limitations make it unnecessarily hard to build responsive plugin experiences. For example:

• A /todo list plugin that queries a local file and displays results instantly
• A /branch switch plugin that shows a picker of git branches
• A /focus goal plugin that updates session state and shows a confirmation without waiting for an LLM round-trip

Feature 1: noReply field on command.execute.before output
Allow the command.execute.before hook to signal that the LLM call should be skipped and the hook's output parts shown directly to the user.
Current hook signature (packages/plugin/src/index.ts lines 261-264):

"command.execute.before"?: (
  input: { command: string; sessionID: string; arguments: string },
  output: { parts: Part[] },
) => Promise<void>

Proposed change — add an optional noReply field to output:

"command.execute.before"?: (
  input: { command: string; sessionID: string; arguments: string },
  output: { parts: Part[]; noReply?: boolean },
) => Promise<void>

When output.noReply = true is set by the hook, the command should:

1. Save the user message to the session (so it appears in chat history)
2. Skip the LLM loop entirely
3. Display the output.parts directly as the assistant's response (or as a toast/status)
   The noReply parameter already exists on the prompt() function (packages/opencode/src/session/prompt.ts line 1631), but there is currently no way for a plugin hook to set it.
   Implementation sketch (packages/opencode/src/session/prompt.ts around line 1984):

const hookOutput = yield* plugin.trigger(
  "command.execute.before",
  { command: input.command, sessionID: input.sessionID, arguments: input.arguments },
  { parts },
)
if (hookOutput?.noReply) {
  const result = yield* prompt({
    ...input,
    parts: hookOutput.parts,
    noReply: true,
  })
  yield* bus.publish(Command.Event.Executed, { ... })
  return result
}

Feature 2: Plugin API for registering palette commands with custom dialogs
Allow external plugins (loaded via opencode.json's plugin field) to register TUI-level palette commands that open custom dialogs — the same capability that built-in commands like /models (DialogModel) and /sessions (DialogSession) have.
Currently, api.keymap.registerLayer() is only accessible to internal system plugins. External plugins only have access to server-side hooks. There's no bridge for an external plugin to say "I want this slash command to open a dialog."
Possible approaches:
(a) Expose api.ui.dialog.replace() and api.keymap.registerLayer() to external plugins, so they can register commands with custom dialog components (even if limited to simple form/select/list components).
(b) Add a new hook (e.g., "command.dialog") that receives the command name and arguments, and returns a dialog descriptor that the TUI can render:

"command.dialog"?: (
  input: { command: string; arguments: string },
  output: { dialog: { type: "select" | "confirm" | "prompt"; options?: string[]; message: string } },
) => Promise<void>

(c) Allow plugins to provide pre-built dialog components via a plugin manifest, loaded and rendered by the TUI at runtime.
Use Cases

1. Instant feedback commands: /f-goal (set a focus goal) → plugin saves to file, shows "✅ Goal: old → new" in the UI immediately, no LLM wait
2. Selection dialogs: /branch → plugin lists git branches, shows a selectable list, user picks one, plugin checks it out
3. Status queries: /status → plugin reads working tree state, renders a compact summary in a dialog
4. Toggle switches: /debug on → plugin toggles a config flag, shows confirmation toast
5. Composable workflows: /deploy staging → plugin runs pre-checks, shows progress, all without consuming LLM context window
   Why this matters
   These changes would unlock a new class of low-latency, utility-focused plugins that don't need LLM involvement for simple CRUD operations. This is especially valuable for:

• Power users who want fast, keyboard-driven workflows
• Plugin authors who want to build responsive tools
• Reducing token waste on trivial commands
  Prior art
• opencode-shell-commands plugin uses ! prefix to run shell commands and skip the LLM entirely, but requires users to write separate shell scripts alongside their command definitions, making it inconvenient for plugin distribution
• PR feat(plugin commands): allows for code execution on plugin registered slash commands #4411 requested plugin-registered executable commands (closed in favor of command.execute.before + subsequent hooks)
• Issue feat: Add noReply option to command.execute.before hook #9306 requested a noReply option (closed as completed, but the feature appears not to have been released or was only partially implemented)
• Issue [FEATURE]: Plugin Hook for Instant TUI Commands #5305 requested a plugin hook for instant TUI commands

[github-actions]

This issue might be a duplicate of (or closely related to) existing issues. Please check:

• [FEATURE]: Plugin Hook for Instant TUI Commands #5305: [FEATURE]: Plugin Hook for Instant TUI Commands — overlaps with your Feature 2 (registering palette commands with custom dialogs from external plugins)
• [FEATURE]: allow chat.message hook to skip the assistant turn (noReply) #26022: [FEATURE]: allow chat.message hook to skip the assistant turn (noReply) — overlaps with your Feature 1 (noReply / skip LLM after hook)
• [FEATURE]: make command palette extensible for external and user-defined actions #18514: [FEATURE]: make command palette extensible for external and user-defined actions — also related to Feature 2

If these cover the same ground, consider adding your details there or linking them. If your request is meaningfully different, a brief note explaining the distinction would help maintainers triage.

[graoke]

This issue might be a duplicate of (or closely related to) existing issues. Please check:

• [FEATURE]: Plugin Hook for Instant TUI Commands #5305: [FEATURE]: Plugin Hook for Instant TUI Commands — overlaps with your Feature 2 (registering palette commands with custom dialogs from external plugins)
• [FEATURE]: allow chat.message hook to skip the assistant turn (noReply) #26022: [FEATURE]: allow chat.message hook to skip the assistant turn (noReply) — overlaps with your Feature 1 (noReply / skip LLM after hook)
• [FEATURE]: make command palette extensible for external and user-defined actions #18514: [FEATURE]: make command palette extensible for external and user-defined actions — also related to Feature 2

If these cover the same ground, consider adding your details there or linking them. If your request is meaningfully different, a brief note explaining the distinction would help maintainers triage.

PR #9267 (feat(hook): command execute before hook) is already merged. It introduces the command.execute.before hook that lets plugins intercept slash commands and modify output.parts. However, it only solves half the problem:

• ✅ Plugin can intercept /command and replace output.parts
• ❌ No way to skip the LLM call after the hook — output only has { parts: Part[] }, no noReply field
• ❌ No API for external plugins to register palette commands with custom dialogs
  So the hook exists, but plugins still cannot return results directly to the UI without an LLM round-trip. The only workaround is throwing an error in the hook, which produces a bad UX. The noReply field on output (and optionally a dialog API) are what's still needed to make this work cleanly.

[graoke]

This issue might be a duplicate of (or closely related to) existing issues. Please check:

• [FEATURE]: Plugin Hook for Instant TUI Commands #5305: [FEATURE]: Plugin Hook for Instant TUI Commands — overlaps with your Feature 2 (registering palette commands with custom dialogs from external plugins)
• [FEATURE]: allow chat.message hook to skip the assistant turn (noReply) #26022: [FEATURE]: allow chat.message hook to skip the assistant turn (noReply) — overlaps with your Feature 1 (noReply / skip LLM after hook)
• [FEATURE]: make command palette extensible for external and user-defined actions #18514: [FEATURE]: make command palette extensible for external and user-defined actions — also related to Feature 2

If these cover the same ground, consider adding your details there or linking them. If your request is meaningfully different, a brief note explaining the distinction would help maintainers triage.

What it does:

• Adds an optional noReply flag to the command schema
• When set, the command dispatch forwards noReply: true to prompt(), which already has a short-circuit guard at if (input.noReply === true) return message
  This directly addresses Feature 1 of our issue — allowing command.execute.before to skip the LLM round-trip.
  What it does NOT cover:
• Registering custom dialogs for external plugins (Feature 2) — no existing PR or issue for this
• Any changes to the plugin hook interface itself — it's a command schema change, not a hook API change
  So the situation is:
• Feature 1 (noReply) ✅ has an open PR (feat(command): add noReply flag to skip LLM dispatch for display-only commands #27521), needs attention to get merged.
• Feature 1 (show information in tui)❌ The PR stops at "don't call the LLM," but the parts the hook produces still disappear into the session as a user message rather than surfacing as visible command output.
• Feature 2 (dialog API for plugins) ❌ still no implementation anywhere.

[draxxris]

How does Opencode DCP handle this? It has many local slash commands

[graoke]

How does Opencode DCP handle this? It has many local slash commands

Layer 1: Command registration — .md files in ~/.config/opencode/command/
Each .md file registers a slash command.
Layer 2: Interception — command.execute.before hook in the plugin

'command.execute.before': async (input, output) => {

}

The hook runs after the command template is resolved but before the message is sent to the LLM.

[Svtter]

Real-world use case: toggle auto-review without LLM round-trip

I'm building opencode-review, a plugin that runs automated code reviews when a session goes idle. It has a /review:auto slash command to toggle auto-review on/off.

Current problem: The command does literally one thing — flip a boolean — but it must spin up an LLM agent to do it. The flow is:

User types: /review:auto off
  → command.execute.before hook (can't cancel)
  → LLM agent receives a prompt: "if args contain 'off', call toggle_auto_review(enabled: false)"
  → LLM calls the toggle tool
  → Tool sets autoEnabled = false

This wastes tokens and adds ~1-2s latency for what should be an instant operation. It also feels fragile — the LLM might misunderstand the instruction or do something unexpected.

What I need: A way for the command.execute.before hook to:

1. Parse the argument (on/off)
2. Set the state directly
3. Return a response to the user
4. Skip the LLM call entirely

Workaround I'm considering: Use command.execute.before to do the actual toggle work, then replace output.parts with a simple instruction so the LLM just echoes the result. Still wastes a call but at least the logic is deterministic.

Would love to see the noReply / cancelled flag merged. Happy to help test if needed.

[graoke]

Real-world use case: toggle auto-review without LLM round-trip

I'm building opencode-review, a plugin that runs automated code reviews when a session goes idle. It has a /review:auto slash command to toggle auto-review on/off.

Current problem: The command does literally one thing — flip a boolean — but it must spin up an LLM agent to do it. The flow is:

User types: /review:auto off
  → command.execute.before hook (can't cancel)
  → LLM agent receives a prompt: "if args contain 'off', call toggle_auto_review(enabled: false)"
  → LLM calls the toggle tool
  → Tool sets autoEnabled = false

This wastes tokens and adds ~1-2s latency for what should be an instant operation. It also feels fragile — the LLM might misunderstand the instruction or do something unexpected.

What I need: A way for the command.execute.before hook to:

1. Parse the argument (on/off)
2. Set the state directly
3. Return a response to the user
4. Skip the LLM call entirely

Workaround I'm considering: Use command.execute.before to do the actual toggle work, then replace output.parts with a simple instruction so the LLM just echoes the result. Still wastes a call but at least the logic is deterministic.

Would love to see the noReply / cancelled flag merged. Happy to help test if needed.

I'd love to see the noReply / cancelled flag merged too. And it would be better if opencode can provide some tools that can be used in a hook – for example, showing a dialog, or showing a message in the TUI.

I currently use an unconventional approach to skip the LLM call entirely:

1. hook
2. do something (in your case: set the state directly)
3. then throws an exception. -- That works. You could try it.

And how do you respond – opencode seems do not provide ways for a plugin to show messages to tui