[FEATURE]: Plugin API for custom status bar widgets

[excess122]

Feature Request

Verification

• I have searched existing issues and confirmed this feature hasn't been suggested before

Note: Similar requests exist (#8619 ui.statusLine hook, #18969 ui.footer hook). This issue consolidates and extends those ideas with a concrete proposed API for status bar widgets.

Summary

Allow plugins to register custom widgets in the TUI status bar area, enabling use cases like terminal pets, pomodoro timers, build status indicators, etc.

Motivation

OpenCode's plugin system is powerful for backend logic (event hooks, custom tools, env injection), but there is currently no way for plugins to render custom UI elements in the TUI.

A common use case is displaying persistent status information — for example:

• A terminal pet that reacts to coding activity
• Build/test status indicators
• Pomodoro/focus timers
• Custom metrics (lines written, commits today, etc.)

Proposed API

export const MyPlugin: Plugin = async (ctx) => {
  return {
    "tui.statusbar.widget": {
      id: "my-widget",
      position: "right",
      render: () => "pet Lv.5 | streak: 7d",
      interval: 5000,
    },
  }
}

Alternatives Considered

• Running a separate terminal program in a split pane (works but feels disconnected)
• Modifying OpenCode source directly (not maintainable)

Additional Context

The Bubble Tea framework (used by OpenCode's TUI) supports composable models, so this could potentially be implemented as a composable component in the status bar area.

Several users in the community have expressed interest in customizing the TUI appearance and adding persistent UI elements.

[github-actions]

This issue doesn't fully meet our contributing guidelines.

What needs to be fixed:

• The title should start with [FEATURE]: (e.g., [FEATURE]: Plugin API for custom status bar widgets)
• The feature request template requires a verification checkbox confirming the feature hasn't been suggested before — this is missing

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]: Native StatusLine Hook for Plugins (Context-Free Display) #8619: Native StatusLine Hook for Plugins — requests a persistent status display area in the TUI for plugins, including a proposed tui.statusLine hook
• [FEATURE]: add tui.footer.items plugin hook for persistent status display #18969: Add tui.footer.items plugin hook for persistent status display — directly requests plugin-injected footer/status items with ordering and styling
• [FEATURE]: Additional TUI Slots for Plugins #20504: Additional TUI Slots for Plugins — requests new plugin render slots in the TUI including footer areas
• [FEATURE]: Plugin API for TUI customization #17492: Plugin API for TUI customization — broader request for plugin hooks into footer/header/sidebar

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

[github-actions]

Thank you for updating the issue! It now meets our contributing guidelines — the title has the [FEATURE]: prefix, the verification checkbox is checked, and the request includes clear motivation and a concrete proposed API. The needs:compliance label has been removed.

[ozgurcd]

Adding a concrete use case to support this request: code intelligence provider status in the right panel.

The problem

When a developer uses an MCP-based static analysis tool like gograph, opencode has no visibility into whether the tool's index is fresh. The agent silently queries a stale graph and produces wrong results — and the developer has no way to know without leaving opencode.

LSP servers already solve this for language servers: their status appears in the right panel. The same treatment is missing for tools that build local indexes outside of LSP.

Concrete use case

gograph is a Go AST analysis tool that already ships as a working MCP server (gograph mcp). When configured in opencode.json, all its tools are available to the LLM. The missing piece is a freshness indicator visible in the TUI:

Code Intelligence
  gograph   ready   75 files · 622 symbols · built 4m ago

If the graph is stale:

  gograph   STALE   3 source files changed since last build

Proposed minimal contract

A provider exposes a small JSON payload (via stdout, a local socket, or a named pipe — whatever fits the plugin model):

{
  "name": "gograph",
  "kind": "code-intelligence",
  "status": "ready | stale | building | error",
  "details": {
    "indexed_files": 75,
    "symbols": 622,
    "last_built": "2026-06-06T15:00:00Z",
    "stale_files": 0
  }
}

The panel row is driven entirely by this payload — no opencode-side special-casing per tool.

Why this strengthens the existing status bar widget request

A generic "register a status bar widget" API is powerful but abstract. A code intelligence provider interface gives it a concrete, motivating use case with an immediate reference implementation ready to ship. The gograph side of this is a single gograph status --serve subcommand — minimal surface area.

Happy to collaborate on the design if there is appetite for this direction.