[FEATURE]: Plugin-Provided Autocomplete

[V1RE]

Feature hasn't been suggested before.

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

Describe the enhancement you want to request

Describe the enhancement you want to request

Problem

Currently, the TUI autocomplete only supports built-in triggers:

• @ for files and agents
• / for slash commands

There's no way for plugins to contribute completion items. This limits plugins that could benefit from autocomplete, such as:

• Issue trackers (beads, linear, jira) - completing issue IDs
• Database tools - completing table/column names
• Project-specific references - completing custom identifiers

Proposed Solution

Add a new plugin hook "autocomplete.provide" that allows plugins to:

1. Register custom trigger characters (e.g., # for issues)
2. Provide completion items when their trigger is activated
3. Optionally handle their own filtering (vs. default fuzzysort)

API Design

// Provider configuration
interface AutocompleteProvider {
  trigger: string      // "@", "#", or prefix like "bd-"
  fuzzy?: boolean      // Use fuzzysort (default: true)
}

// Completion item
interface AutocompleteItem {
  display: string      // Dropdown text
  value?: string       // Text to insert
  description?: string // Secondary text
}

// Hook signature
interface Hooks {
  "autocomplete.provide"?: (
    input: { trigger: string; query: string },
    output: { provider?: AutocompleteProvider; items: AutocompleteItem[] }
  ) => Promise<void>
}

Example Usage

// Beads issue tracker plugin
export const BeadsPlugin: Plugin = async (ctx) => ({
  "autocomplete.provide": async (input, output) => {
    output.provider = { trigger: "#", fuzzy: true }
    if (input.trigger !== "#") return
    
    const issues = await fetchIssues(ctx)
    for (const issue of issues) {
      output.items.push({
        display: `${issue.id}: ${issue.title}`,
        value: issue.id,
        description: issue.status,
      })
    }
  },
})

User types #bd- → sees dropdown with matching issues → selects → bd-a1b2 inserted.

Behavior

• Trigger conflict: First plugin to register a trigger wins
• Prefix triggers: Support both single-char (#) and prefix (bd-) triggers
• Filtering: OpenCode applies fuzzysort by default; plugins can disable and filter themselves
• Insertion: Selected item's value (or display) is inserted at cursor

Implementation Scope

Package	Changes
@opencode-ai/plugin	Add hook types
packages/opencode/src/server/server.ts	Add /autocomplete/* endpoints
packages/opencode/src/cli/cmd/tui/context/sync.tsx	Store providers
packages/opencode/src/cli/cmd/tui/component/prompt/autocomplete.tsx	Handle custom triggers
SDK	Regenerate from OpenAPI

Benefits

1. Extensibility: Plugins can provide contextual completions
2. Better UX: Users get autocomplete for plugin-specific identifiers
3. Consistent patterns: Uses existing hook/trigger architecture
4. Non-breaking: Existing @ and / behavior unchanged

Use Cases

• Issue trackers: beads, Linear, Jira, GitHub Issues
• Documentation: Notion pages, Confluence docs
• Databases: Table/column names for SQL tools
• Custom references: Project-specific IDs, ticket numbers

---

Happy to implement this if the design looks good. Let me know if you'd prefer different trigger behavior or API shape.

[github-actions[bot]]

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

• #5305: [FEATURE]: Plugin Hook for Instant TUI Commands - Similar plugin extensibility request for command/trigger registration
• #2185: Hooks for commands (Plugin Commands) - Earlier feature request for plugin command hooks
• #5148: [FEATURE]: Comprehensive Plugin Pipeline - Middleware-Style Data Flow Control - Broader plugin system extensibility request that would enable custom autocomplete

All these requests aim to extend the plugin system to support new types of plugin-provided functionality beyond current event hooks. The autocomplete feature request may benefit from insights in these related discussions.

Feel free to ignore if your specific autocomplete use case addresses unique requirements not covered in these issues.

[rekram1-node]

I think @thdxr had some ideas but this is definitely something we want