Repository navigation
[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.
Activity
github-actions commentedon Dec 5, 2025
This issue might be a duplicate or closely related to existing issues. Please check:
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 commentedon Dec 6, 2025
In #4960 it really mentions 2 asks. It appears the
--configask has gained traction. I just wanted to note that the other--system-promptask 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 commentedon Mar 23, 2026
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 }
paroque28 commentedon Mar 31, 2026
Strong +1 on this. We hit exactly the limitation described here. Event-based hooks can't intercept and transform data flowing through the pipeline.
I built claude-code-redact as a workaround: an external proxy that sits between the client and the LLM provider, redacting outgoing requests and un-redacting incoming responses. It works, but it's a workaround for the lack of middleware-style pipeline access.
The
pipeline.before/pipeline.afterpattern proposed here would allow to do this natively, no external proxy needed. Our specific need is redacting secrets/PII before they reach the provider and un-redacting the response, but the middleware pattern is general enough to support compliance logging, DLP, cost monitoring, and more.Related: #4961, #19425
OddballGreg commentedon Jun 16, 2026
A concrete, minimal use case for the "early termination" part of this, in case it helps scope a first slice.
I'm building a memory/cache plugin. On a
read/grepit sometimes already holds the answer, an indexed summary or cached result, and wants to return that instead of doing the read. Todaytool.execute.beforecan only mutate args, and the runtime callsitem.execute(...)unconditionally afterwards (inpackages/opencode/src/session/tools.ts, both the native path around L88-93 and the MCP path around L129-139), so the read always runs.tool.execute.aftercan rewrite the result, but by then the work has already happened.permission.askdenies a call but returns an error rather than a clean substitute result.The smallest version of "early termination" that would unblock this is letting
tool.execute.beforeoptionally supply a result and/or skip execution:If
skiporresultis set, build the output fromresultand bypassitem.execute(...). It stays backwards compatible since hooks that set neither behave exactly as today. The native and MCP paths return different output shapes, so both would need handling.Not trying to narrow the broader pipeline vision here, just flagging a real plugin that needs the early-termination piece, in case a minimal
beforeshort-circuit is a reasonable first step toward it.OddballGreg commentedon Jun 17, 2026
Opened a PR for the minimal early-termination slice described above: #32679. It adds an optional
resulttotool.execute.beforeso a plugin can answer a tool call itself and skip execution, wired through both the native and MCP paths. Backwards compatible. Picks up the idea from the earlier #18689 in a much smaller form, scoped just to thebeforeshort-circuit rather than the full pipeline.github-actions commentedon Aug 17, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.