opencode icon indicating copy to clipboard operation
opencode copied to clipboard

[FEATURE]: Plugin package tool types should stay aligned with built-in tool capabilities

Open eXamadeus opened this issue 20 hours ago • 2 comments

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

Summary

The @opencode-ai/plugin package's tool types consistently lag behind the capabilities available to them. When new fields are added to the context passed to tools or new return type options are added to tool execution, plugin authors can't access them until someone manually updates the plugin package.

A recent "catch up" PR for ToolContext was #8269 where .ask() and .metadata() were added to the types.

Related Issues

  • #7147 - Plugin package not using latest SDK types (event types)
  • #7641 - Plugin hook types not aligned with runtime triggers (SDK v2 types)

This issue focuses specifically on tool definition types rather than event/hook types.

Current gaps

  • ToolContext is missing callID, extra, ~metadata()~, and ~ask()~ fields that built-in tools have
  • Plugin tools can only return a string, while built-in tools can return structured objects with title, metadata, and attachments

Short Term Fix

I'm gonna make a PR (#8328) to update the types 😆. The real benefit IMO, is also being able to return a structured object where plugin authors can control the title and metadata.

Proposed Long Term Solutions

  1. Generate plugin types from source: we could derive @opencode-ai/plugin types directly from packages/opencode/src/tool/tool.ts to ensure they stay in sync
  2. Shared type package: we could extract tool types into a shared package that both opencode core and plugin package import from
  3. CI check: add a check that fails when plugin package types diverge from core tool types

Option 3 is probably the easiest "win", but I think option 1 or 2 are much more valuable over time. Option 1 has the downside of adding core as a dependency for the plugin package (at least I think so...maybe there's a cleaner way).

Any of these would prevent the pattern of plugin types falling behind and requiring periodic catch-up PRs.

eXamadeus avatar Jan 14 '26 02:01 eXamadeus