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

• 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?