anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 02:05:26 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

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

New Issue
Open
opened 2026-02-16 17:39:43 -05:00 by yindo · 2 comments
yindo commented 2026-02-16 17:39:43 -05:00
Owner
Copy Link
Copy Source

Originally created by @mlanza on GitHub (Dec 5, 2025).

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 (#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.

Originally created by @mlanza on GitHub (Dec 5, 2025). ### 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 ```js 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.
yindo added the discussion label 2026-02-16 17:39:43 -05:00
yindo commented 2026-02-16 17:39:43 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Dec 5, 2025):

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

  • #753: Extensible Plugin System for OpenCode (already implemented with comprehensive plugin architecture and hooks)
  • #2319: MCP Tool Calls Don't Trigger Plugin Hooks (addresses universal tool interception concern)
  • #5091: Session Tainting — Directional Safety Pattern for Agentic Work (related to data flow control and session management)
  • #2945: Session automatically compacted, destroying working context (related to state management and context preservation)
  • #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.

@github-actions[bot] commented on GitHub (Dec 5, 2025): This issue might be a duplicate or closely related to existing issues. Please check: - #753: Extensible Plugin System for OpenCode (already implemented with comprehensive plugin architecture and hooks) - #2319: MCP Tool Calls Don't Trigger Plugin Hooks (addresses universal tool interception concern) - #5091: Session Tainting — Directional Safety Pattern for Agentic Work (related to data flow control and session management) - #2945: Session automatically compacted, destroying working context (related to state management and context preservation) - #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.
yindo commented 2026-02-16 17:39:43 -05:00
Author
Owner
Copy Link
Copy Source

@mlanza commented on GitHub (Dec 6, 2025):

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.

@mlanza commented on GitHub (Dec 6, 2025): 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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label discussion
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#3346
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?