[FEATURE]: Comprehensive Plugin Pipeline - Middleware-Style Data Flow Control

[mlanza]

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

OpenCode's current plugin system provides event hooks but lacks comprehensive pipeline access comparable to middleware patterns like Ring (Clojure) or Rack (Ruby) and dozens in JS land. This restricts plugins from:

1. Universal tool interception - MCP tools bypass plugin hooks (#2319)
2. Result manipulation - Plugins can't modify tool outputs before AI sees them
3. Configuration access - No read access to current tool/agent settings
4. Pipeline control - Can't implement sophisticated security or transformation policies

Security is my chief concern. If I can’t see and intercept every part of the pipeline — including the pieces that stay tucked away — it’s difficult to build trust. When the whole system is open to inspection, trust comes much easier, because the platform hands some control back to us.

Proposed Solution

Extend plugin system to expose the pipeline and permit middleware. As I explained in my request for modal dialogs (#5147), human-in-the-loop interactions are pipeline based, not event based. Better security, too, is pipeline based. You need to influence what's flowing through the system, not just react to it.

With an extensible middleware architecture and modals, you have a solid backbone which permits an overwhelming number of feature requests to fall out of core and back to the community. That's been my goal with these recent requests: to shift more and more of the feature burden to the community. My thought is every penny spent here is a dime in savings.

Universal Pipeline Hooks

export const PipelinePlugin = async ({ project, client, $, directory, worktree }) => {
  return {
    // Universal interception for ALL operations
    pipeline: {
      before: async (context) => {
        // Intercept any operation (tools, sessions, config)
        // Modify inputs, add auth, implement policies
      },
      after: async (context, result) => {
        // Transform outputs, filter content, add metadata
      },
      error: async (context, error) => {
        // Error handling, recovery, logging
      }
    }
  }
}

The above is purely suggestive of the idea.

Configuration Access

• Expose read-only access to the opencode configuration object after all merges (#4960)
• Expose tool/agent configurations

Benefits to Existing Issues

This could help solve:

• #2319 (MCP tool coverage) - Universal pipeline includes all tool types
• #1727 (Webfetch permissions) - Fine-grained network control
• #2945/#3291 (Session management) - Better state preservation
• #744 (CORS/network middleware) - Network-level transformations
• #3432 (Agent definitions) - Access to AGENTS.md configurations

Implementation Pattern

Similar to established middleware patterns:

• Chain of responsibility for plugin composition
• Request/response transformation capabilities
• Early termination for security policies
• Context preservation across pipeline stages

Use Cases Enabled

• Session tainting (#5091) with complete data flow control
• Security policies for network access and data exfiltration
• Content filtering and sanitization
• Advanced logging and audit trails
• Custom approval workflows beyond basic permissions This approach transforms OpenCode plugins from event handlers into powerful middleware capable of sophisticated data flow control, enabling an ecosystem of advanced security, monitoring, and transformation tools.

My several requests are all in service to writing plugins to service my own needs. My goal is to, as much as possible, do that, but it depends on the core you expose (#753).

I'll continue to say it: this is an amazing product. It's only because I'm chomping at the bit to jump in and develop my own features I've been so aggressive with requests. I want to build on opencode. I just want to do it by extension.