[FEATURE]: make command palette extensible for external and user-defined actions

[anduimagui]

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

Describe the enhancement you want to request

The command palette in Opencode Desktop is now centralized behind a better registration seam, but it is still effectively closed over a fixed set of built-in commands. I would like the app command palette to support external and user-defined actions so local workflows do not require a core app change every time.

Examples of actions this should unlock:

• open the current project in VS Code
• open notes/docs in Obsidian
• reveal the current project in Finder
• run a project-specific local script
• trigger other local tools or shell-based workflows

This would make the command palette a real extensibility surface for user workflows, team conventions, and future integrations.

First step already landed

The first step for this work is already in place in:

• PR: refactor(app): move command palette to dedicated module #18365

That PR extracts layout command registration into packages/app/src/pages/layout/commands.tsx and adds focused tests around that registration seam, which seems like the right foundation for follow-up extensibility work.

Existing architecture / prior decisions in the repo

There does not seem to be a formal ADR/RFC for this yet, but the current codebase already points in this direction:

• the app command system already uses a registry model via command.register(key, cb)
• command metadata is already modeled as data (id, title, description, category, keybind, slash)
• the app already supports context-aware commands through disabled state
• command registration is already distributed by feature area (layout, session, etc.) rather than kept in one monolithic list
• the wider product already has config-driven extensibility elsewhere:
  • TUI/CLI custom commands via command config and .opencode/commands/
  • plugin loading via config.plugin and .opencode/plugins/

So this request is mainly about bringing the app command palette in line with extensibility patterns that already exist elsewhere in opencode.

Prior art

Other platforms treat the command palette as a primary extension surface:

• VS Code lets extensions contribute commands declaratively and register handlers programmatically, with category/title metadata and conditional visibility or enablement.
• Obsidian plugins register commands directly, including conditional commands that only appear or run when required context exists.
• Zed treats the command palette as a primary action surface while keeping extension capabilities behind explicit, scoped registration models.

The common pattern is:

• commands are first-class extension units
• command metadata is separate from execution
• commands can be context-aware
• platforms often start with a narrow, explicit model before expanding to broader automation

Proposed direction

Add an extensible command registration layer that allows the app command palette to surface commands beyond the built-in layout/app actions.

A command shape like this would likely be enough to start:

• id
• title
• optional description
• optional category
• optional icon or source
• optional keywords
• optional context requirements
• an executable action

Initial action types could stay intentionally narrow:

• app/URL links (vscode://, obsidian://, file URLs, app deep links)
• local app launch with arguments
• shell commands later, only behind an explicit safety model

Goals

• keep built-in commands working as they do today
• preserve a clear, testable seam between command definition and command execution
• support external/custom commands without editing the core command list every time
• allow commands to consume current app context when available
• make commands discoverable and well-labeled in the palette
• leave room for a future plugin/integration system without requiring that full system up front

Open questions

• should custom commands live in user config, workspace config, or both?
• should commands support template variables like {project_path} or {session_id}?
• should missing-context commands be hidden or shown disabled?
• should we start with app links only, or allow local process launch too?
• if shell execution is supported later, what confirmation/permission model is required?

[anduimagui]

The first step for this work is already in place in refactor(app): move command palette to dedicated module:

• PR: refactor(app): move command palette to dedicated module #18365

That PR extracts layout command registration into packages/app/src/pages/layout/commands.tsx and adds focused tests around that registration seam.

Prior decisions / existing architecture

• The app command system already uses a registry model via command.register(key, cb) in packages/app/src/context/command.tsx.
• Command metadata is already modeled as first-class data (id, title, description, category, keybind, slash).
• The app already supports context-aware commands through disabled state.
• Command registration is already distributed by feature area (layout, session, etc.) rather than maintained in one monolithic list.
• The broader product already has config-driven extensibility elsewhere:
  • TUI/CLI custom commands via command config and .opencode/commands/
  • plugin loading via config.plugin and .opencode/plugins/

[github-actions]

This issue doesn't fully meet our contributing guidelines.

What needs to be fixed:

• The title should start with [FEATURE]: for feature requests (current title uses feat(app):)
• Please use the Feature Request issue template, which includes a required verification checkbox confirming the feature hasn't been requested before

Please edit this issue to address the above within 2 hours, or it will be automatically closed.

---

This issue might be a duplicate of existing issues. Please check:

• [FEATURE]:feat(app): support custom slash commands from .opencode/commands in GUI #17048: Support for surfacing custom slash commands from .opencode/commands in the GUI/app — closely related to making app commands extensible from user config

If you believe this was flagged incorrectly, please let a maintainer know.

[github-actions]

Thanks for updating the issue! It now meets our contributing guidelines. We appreciate the detailed write-up.