[FEATURE]: Plugin/Agent/Skills/etc marketplace

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

Master issue for a unified OpenCode marketplace / registry / package distribution system.

This should cover discovery, installation, update, removal, provenance, trust, and management for shareable OpenCode ecosystem assets, including:

plugins/extensions
agents/subagents
skills
MCP servers
commands
packaged config/tool bundles

The marketplace should be broad enough to support official, community, private, and decentralized sources. Possible sources include GitHub repos, Claude/Copilot-style marketplace files, Open VSX-like registries, MCP registries/hubs, self-hosted/private registries, and curated community catalogs.

Related requests include plugin marketplace, skills marketplace, agent marketplace, MCP registry integration, package-manager style installs, and UI/CLI flows for browse/search/install/update/remove.

Duplicate / related issues:

Please take a look here :#28383

yesterday I though I need marketplace same as the vscode one, so I made a quick port of vscode's marketplace as opencode plugin. But then I realised I didn't need it. So I didn't even test it. But it might be useful reference for someone. https://github.com/Alino/opencode-marketplace

We need this ASAP!! Thats the one feature keeping masses from migrating to OpenCode!!!

Is this feature being developed yet?

This would unlock smoother skill sharing with non-technical teammates. Please consider this!

Still waiting for the Same ,
I will make the newbie users really appreciate and make full use of the Opencode GO subscription,
Something like Codex app where we can add skills, plugins, mcp servers and connectors for various platforms like Cloudflare, Netlify, Figma, Gmail, Docs etc etc etc.
Plus inbuilt Browser Use.

Excited, I'm trying to get a repo to support Claude Code, Codex and OpenCode plugins. both CC and Codex can support install plugins directly from git, but not OpenCode.
I have to make custom adapters/wrappers for its plugin to load runtime from skills which are installed separately via. npx sills

A lot of hurdles

Any news?

I have a working example that might be helpful for this discussion:

https://github.com/medjmal54/frontend-skill

This is an open-source, modular frontend engineering skill built specifically for OpenCode. It's not a single prompt. It includes workflows and references for creating frontend products, SaaS or dashboard applications, CRUD and navigation systems, design direction avoiding generic design patterns, motion systems, high-craft immersive experiences, 3D elements, accessibility, performance optimization, auditing and productization.

The repository is already set up as an OpenCode skill and can be installed on its own.

I’d be happy to contribute this as a real-world community skill once the marketplace or registry system's available.

In particular, I’m interested in helping test or shape:

GitHub-based skill discovery
skill installation and update flows
metadata and schema for skills
provenance and trust information
community skill distribution

I’m ready to adapt the repository to match whatever format or metadata the final system ends up requiring.

Thanks for collecting all of these in one place. This is a feature request and tracking issue, not a bug report: it doesn't describe broken behaviour, so there's nothing for me to reproduce. I've recorded it as a feature request, and the linked issues (#7467, #23800, #18697, #3087, #16012, #28383 and the rest) can be followed here as the main thread for marketplace and registry work.

Following #60816, I'd like to agree on the V2 design here. The small local-agent Core slice is now available for design review in draft #60821.

Proposed ownership:

Schema owns the external local-agent catalog manifest, using the current agent-config schema. The provisional discriminator is opencode.marketplace/experimental.
Core owns the registry model, installed snapshots and short-lived process-local plans. Apply consumes the captured snapshot with a registry revision check rather than rereading the catalog.
The draft proposes one SQLite registry row. This persistence choice and its migration remain pending design agreement; the draft should not land before that agreement.
Installed packages are global to the server. A follow-up would register the service in Instance and project its documents into Location config through explicit experimental opt-in, respecting global: false and leaving user JSONC unchanged.
Package agents use marketplace/<package-key>/<local-name> IDs. Catalog names cannot contain /, and same-named agents in different packages remain distinct. A test using the actual config-agent plugin verifies existing built-in and user prompts, models and permissions are preserved.

Are global installed state plus Location-specific config projection the intended ownership model, and is the proposed local-agent registry a suitable first persistence boundary?

After agreement, I'd send the Location integration, experimental HTTP API/generated clients, CLI, App, TUI and docs as focused follow-ups. HTTPS/SSH/private GitLab, other package kinds, foreign-manifest adapters, profiles and locks would follow separately.

The draft is 10 files and 610 added lines. Its latest revision passes 66 Marketplace/config-agent/migration tests, official Core typecheck and full lint/typechecks. The branch is marketplace-agents.

I also audited the earlier OpenAPI concern: all 138 existing paths and 489 schemas, including key order, are unchanged. git diff --minimal reports 3,865 additions and zero deletions; the standard diff misaligns the repeated JSON. The API follow-up will include that additive-contract check.

Hi all,

I'm writing on behalf of the Eclipse Foundation, which hosts the AI Registry. It's an open, vendor-neutral registry where organizations publish which MCP servers, skills, plugins and other similar artefacts they approve. The goals in this issue overlap with what it does, especially provenance, trust and support for private or decentralized sources, so maybe this is interesting to you

OpenCode can be an organization in the registry. The OpenCode team could publish its own curated list ("what we recommend") as approval files in a git repository, without running any infrastructure. Any company or team adopting OpenCode can do the same for its own developers: register as an organization, approve what it allows, and point OpenCode at its list. Users then get an allowlist that means "only what my organization approved", instead of matching on names or domains.

OpenCode can be a tool in the registry, with its own install configs. Organizations can (automatically) attach tool-specific install configuration to each approval, such as OpenCode's own MCP config format, arguments or environment variables. With an opencode tool entry, OpenCode reads tools/opencode.json and gets exactly what organizations approved for OpenCode, ready to install the OpenCode way. We'd be happy to set that up.

Claude-style marketplace files work as they are. The issue already lists "Claude/Copilot-style marketplace files" as a source. The registry publishes approved plugins in that format, one file overall and one per organization (e.g. https://ai.open-vsx.org/api/v1/orgs/gitlab/marketplace.json), each entry pinned to a full commit SHA. A foreign-manifest adapter for that format would give OpenCode per-organization plugin catalogs for free.

Integrity and updates. MCP servers are referenced by their ID in the official MCP Registry. Skills and plugins come with a content hash and the commit it was computed from, plus the hash of what the source currently ships. A client can verify an install and see when an approval has fallen behind upstream, which could feed into the locks step on your roadmap.

The client guide is at https://ai.open-vsx.org/docs/clients. Feeds and schemas are open and need no account. Adaptations based on your feedback are possible, even hosting a own UI with the same data.

If there is interest, we'd be glad to help with the adapter design, the tool entry, or an OpenCode organization repository to start from. Feel free to ping me here or open an issue over there.

Thanks for the suggestion. This isn't something we plan to build, so closing to keep the tracker focused.

Thanks for the suggestion. This isn't something we plan to build, so closing to keep the tracker focused.

Any word on why? It's a sad, since this RFE has quite a lot of votes.

Navigation Menu

Repository navigation

[FEATURE]: Plugin/Agent/Skills/etc marketplace #28696

Feature hasn't been suggested before.

Describe the enhancement you want to request

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[FEATURE]: Plugin/Agent/Skills/etc marketplace #28696

Description

Feature hasn't been suggested before.

Describe the enhancement you want to request

Activity

alexandre-leng commented on May 22, 2026

Alino commented on May 28, 2026

bal381959 commented on Jun 11, 2026

jiweigithub commented on Jun 16, 2026

pete-willard commented on Jul 16, 2026

neonvarun commented on Jul 16, 2026

lunarmoon26 commented on Jul 31, 2026

SimSonic commented on Aug 6, 2026

medjmal54 commented on Aug 30, 2026

opencodejr commented on Oct 29, 2026

dobord commented on Oct 31, 2026

JonasHelming commented on Nov 12, 2026

neriousy commented on Nov 12, 2026

xsuchy commented on Nov 13, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions