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

[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'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 (MCP Tool Calls Don't Trigger 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 ([FEATURE]: Add visibility flags for merged config and system prompt #4960)
• Expose tool/agent configurations

Benefits to Existing Issues

This could help solve:

• MCP Tool Calls Don't Trigger Plugin Hooks #2319 (MCP tool coverage) - Universal pipeline includes all tool types
• Feature Request: permissions for webfetch #1727 (Webfetch permissions) - Fine-grained network control
• Session automatically compacted, destroying the entire working context #2945/[FEATURE]: Navigation to parent session from child/subagent sessions #3291 (Session management) - Better state preservation
• Add CORS middleware for Firefox localhost development compatibility #744 (CORS/network middleware) - Network-level transformations
• [FEATURE]: custom config path to also support agent definition (via markdown) #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 ([FEATURE]: Session Tainting — A Directional Safety Pattern for Agentic Work #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.

[github-actions]

This issue might be a duplicate or closely related to existing issues. Please check:

• Feature Request: Extensible Plugin System for OpenCode #753: Extensible Plugin System for OpenCode (already implemented with comprehensive plugin architecture and hooks)
• MCP Tool Calls Don't Trigger Plugin Hooks #2319: MCP Tool Calls Don't Trigger Plugin Hooks (addresses universal tool interception concern)
• [FEATURE]: Session Tainting — A Directional Safety Pattern for Agentic Work #5091: Session Tainting — Directional Safety Pattern for Agentic Work (related to data flow control and session management)
• Session automatically compacted, destroying the entire working context #2945: Session automatically compacted, destroying working context (related to state management and context preservation)
• Feature Request: permissions for webfetch #1727: Feature Request: permissions for webfetch (related to fine-grained pipeline control and network access)

Your feature request for a comprehensive plugin pipeline middleware system appears to build upon the foundation of #753. Consider reviewing how the existing plugin system can be extended to support the middleware pattern you're proposing, particularly for universal interception of all operations (including MCP tools) and configuration access.

Feel free to ignore if your request addresses specific gaps not covered by these issues.

[mlanza]

In #4960 it really mentions 2 asks. It appears the --config ask has gained traction. I just wanted to note that the other --system-prompt ask is about transparency. The exact thing that a truly open pipeline exposes. So provided the system prompts flow through such a pipeline, this issue swallows that one.

[ooohmynas]

feat: plugin pipeline short-circuit for universal tool interception

Summary
Implement middleware-style pipeline control for the plugin system via PipelineExecutor
Enable plugins to intercept and override any tool execution (including MCP tools) using short-circuit
Extend tool.execute.before hook with result field — setting it skips tool execution and returns the result directly
Handle Zod v3/v4/JSONSchema7 parameter type mismatches in tool resolution
Closes #5148

Changes
PipelineExecutor — before/after/error hooks with priority sorting and shortCircuit support
ToolSource — unified composition of built-in and MCP tools
triggerToolExecution — replaces Plugin.trigger for tool execution, wires hooks through PipelineExecutor
tool.execute.before hook — new result field: { title: string, output: string, metadata?: Record }