[FEATURE]: Plugin Support for Modal Human-in-the-loop Interactions

[mlanza]

Feature hasn't been suggested before.

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

Describe the enhancement you want to request

OpenCode has a robust modal dialog system for built-in permission checks, but plugins cannot access this UI capability. I am a proponent of implementing my own feature request if it can be done with a plugin, but that hinges on access to the right hooks and junction points.

I plan on implementing #5091, but I lack the ability to present the user with a modal dialog and collect information in a text field. Or at minimum, to track a button click response to data flowing through the system.

Proposed Solution

Expose existing modal infrastructure to plugins:

// New plugin hook
"ui.modal.show": async (options) => ModalResponse
// New SDK method
await client.ui.modal({
  title: "Gated Review",
  event: /webfetch/, //regex to match event name(s) to intercept
  load: function(event, config) {
    //.. build the form with access to overall system config
    const fields = [{
      type: "textarea",
      key: "content",
      value: data.payload,
      readonly: true
    },
    {
      type: "text", 
      key: "hash",
      value: null,
      placeholder: "Enter 5-character hash to approve",
      required: true
    }];
    return {fields, buttons: ["Approve", "Deny", "Cancel"]};
  },
  validate: async function(fields, button, config){
    if (button === "Cancel") return;
    //..
    return fields.hash.length === 5 ? null : [{field: "hash", message: "Hash must be 5 chars."}];
  },
  cancel: async function(button) {
    //allow the user to abort
    return button === "Cancel";
  },
  result: async function(fields, button, config) {
    //you decide the end result of the interaction, augment the event
    return {...};
  }
})

The above is mostly suggestive. It models a basic TUI-style form, enough for textboxes, textareas, checkboxes, dropdowns, and buttons. It allows one to capture most things from the user while maintaining the current UX. The validation can be as simple as you like, even just a TUI notification about the problem(s). An MVP, nothing glamorous.

The above suggests intercepting events, because that's what opencode has right now, but the reality is control over pipelines (#5148) is an order of magnitude more useful. Several such results might be tacked onto any one event.

The value proposition hinges on meaningful human-in-the-loop interactions over data flowing through the system. So the same general approach gets applied to pipelines. In the AI era, this is going to meaningful and wanted by people who don't want to cede absolute control to agents.

My hope here isn’t to dictate direction but to help shape a strategy which allows you to offload your work. If the extension points become a bit more consistent and sturdy, a lot of the downstream feature pressure could shift naturally to the community. That’s really the spirit behind these requests—fewer burdens on your team and an extensible architecture for everyone else to build on. And I'm thinking you're not going to accept PRs which involve core architectural decisions; you're going to want to retain control over that.

I notice my mind keeps drifting back to that question: “is there a way to let the plugin system carry this instead of the core?” Not because I think I have the answers, just because, in a busy project, that sort of architectural off-ramp feels like the kind of thing I’d quietly lean on to keep the noise manageable.

Alignment with Existing Issues

• Builds on Implement permissions in TUI #239: Extends existing permission UI system to plugins
• Complements Feature Request: Add "ask before editing files" mode #935: Enables custom "ask before" workflows for plugins
• Addresses Feature request: let plugins detect if they are in an interactive session #3201: Provides interactive capability when in TUI session

Implementation Benefits

• Leverages existing infrastructure: Reuses proven modal system
• Consistent UX: Same look/feel as built-in permissions
• Minimal surface area: Exposes existing capability rather than building new
• Broad applicability: Useful in other contexts

Use Cases Enabled

• Interactive verifications
• Custom tool approval workflows
• Plugin configuration dialogs
• Multi-step user interactions
• Error recovery and retry flows

This approach is highly aligned with OpenCode's architecture and addresses a clear gap without reinventing existing functionality. The aim of returning control to the community is to have us implement features ourselves. Even if this is implemented as an MVP and not super robust, it'd be a start I could build on.