[FEATURE]: Comprehensive Plugin Pipeline - Middleware-Style Data Flow Control #5148
Description
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:
- Universal tool interception - MCP tools bypass plugin hooks (MCP Tool Calls Don't Trigger Plugin Hooks #2319)
- Result manipulation - Plugins can't modify tool outputs before AI sees them
- Configuration access - No read access to current tool/agent settings
- 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.