You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[FEATURE]: support the Agent Plugins standard (agent-plugins.org) #40993
OpenCode has no support for Agent Plugins, the vendor-neutral packaging spec for bundling Agent Skills and MCP servers into a portable plugin.
Context
This is a broad, multi-vendor effort rather than any one company's format. Agent Plugins 1.0.0 was published by a TSC of Core Maintainers from Amazon, Cursor, Microsoft, OpenAI, and Vercel, and Google has since joined as a Core Maintainer.
Support already spans most major agent clients:
Vendor
Products supporting Agent Plugins
OpenAI
ChatGPT, Codex
Microsoft
VS Code, GitHub Copilot
Amazon
Kiro
Cursor
Cursor
Google
Agents CLI, Data Agent Kit
The first four rows are per the launch announcement; Google's two are per its Core Maintainer announcement above, with more of its products to follow.
OpenCode is a conspicuous omission, and it's the one place a user's skills currently don't follow them.
Both a client implementation and conformant plugins already exist to test against:
Codex implements it as of 0.147.0 (2026-08-07), via openai/codex#36544. Root plugin.json now takes precedence, with the legacy .codex-plugin/plugin.json demoted to an optional overlay.
AWS's agent-toolkit-for-aws shipped conformant manifests for all four of its plugins in #214 (2026-08-06).
Those AWS plugins install in Codex today. In OpenCode the same directories are only reachable if a user points skills.paths at them by hand, and their bundled MCP servers are not picked up at all.
Notably, OpenCode already discovers ~/.claude/skills/** and ~/.agents/skills/** and already speaks MCP. The gap is only the manifest layer that binds them into one installable, versioned unit.
Proposal
Recognize a root plugin.json as a plugin manifest, gated on $schema matching https://agent-plugins.org/schemas/1.0.0/plugin.schema.json. Codex treats a non-matching or absent $schema as "not an Agent Plugin" and falls through, which seems like the right behaviour, since it keeps unrelated plugin.json files from being misread.
Load skills/ through the existing skill discovery path.
Load mcp.json into the existing MCP server config, honouring the spec's transport rules (§7.2.1).
Optionally consume .agents/plugins/marketplace.json for discovery. Both Codex's own curated marketplace and AWS's toolkit already publish at that vendor-neutral path.
Optionally reserve a com.opencode.* (or similar) extension namespace per §8.2 for anything OpenCode-specific.
Relationship to existing issues
[FEATURE]: discover skills installed by VS Code agent plugins and Claude Code plugins #40629 asks for discovery of skills sitting inside VS Code agent-plugin and Claude Code plugin directories, by reading each client's own manifests (installed.json, cache.json, installed_plugins.json). That's a per-client compatibility shim; Agent Plugins is the standard that makes such shims unnecessary for conformant packages. The two are complementary, one covering what's already installed today and the other what gets published going forward.
feat(opencode): add unified marketplace #40085 (closed) proposed a unified OpenCode marketplace. Supporting the spec would let such a marketplace serve portable packages rather than an OpenCode-only format.
Describe the enhancement you want to request
OpenCode has no support for Agent Plugins, the vendor-neutral packaging spec for bundling Agent Skills and MCP servers into a portable plugin.
Context
This is a broad, multi-vendor effort rather than any one company's format. Agent Plugins 1.0.0 was published by a TSC of Core Maintainers from Amazon, Cursor, Microsoft, OpenAI, and Vercel, and Google has since joined as a Core Maintainer.
Support already spans most major agent clients:
The first four rows are per the launch announcement; Google's two are per its Core Maintainer announcement above, with more of its products to follow.
OpenCode is a conspicuous omission, and it's the one place a user's skills currently don't follow them.
Both a client implementation and conformant plugins already exist to test against:
plugin.jsonnow takes precedence, with the legacy.codex-plugin/plugin.jsondemoted to an optional overlay.Those AWS plugins install in Codex today. In OpenCode the same directories are only reachable if a user points
skills.pathsat them by hand, and their bundled MCP servers are not picked up at all.What the format is
Notably, OpenCode already discovers
~/.claude/skills/**and~/.agents/skills/**and already speaks MCP. The gap is only the manifest layer that binds them into one installable, versioned unit.Proposal
plugin.jsonas a plugin manifest, gated on$schemamatchinghttps://agent-plugins.org/schemas/1.0.0/plugin.schema.json. Codex treats a non-matching or absent$schemaas "not an Agent Plugin" and falls through, which seems like the right behaviour, since it keeps unrelatedplugin.jsonfiles from being misread.skills/through the existing skill discovery path.mcp.jsoninto the existing MCP server config, honouring the spec's transport rules (§7.2.1)..agents/plugins/marketplace.jsonfor discovery. Both Codex's own curated marketplace and AWS's toolkit already publish at that vendor-neutral path.com.opencode.*(or similar) extension namespace per §8.2 for anything OpenCode-specific.Relationship to existing issues
installed.json,cache.json,installed_plugins.json). That's a per-client compatibility shim; Agent Plugins is the standard that makes such shims unnecessary for conformant packages. The two are complementary, one covering what's already installed today and the other what gets published going forward.