feat(opencode): add unified marketplace - #40085

Summary

Adds a unified OpenCode Marketplace for installing and managing plugins, skills, agents and subagents, slash commands, MCP servers, instruction files, and reusable bundles.

Original issue: anomalyco/opencode#28696.

The branch has been rebuilt as 10 focused commits directly on the current dev head. It includes the original desktop/TUI experience plus the completed security, reproducibility, Codex compatibility, control-plane, and reliability work.

Why

Marketplace packages can contain executable plugins, local MCP commands, and model-influencing instructions. The implementation therefore keeps discovery separate from activation and preserves a strict ownership boundary:

user-authored opencode.json
        +
SQLite Marketplace registry
        +
immutable materialized artifacts
        =
effective in-memory configuration

Marketplace operations never persist generated Marketplace entries into opencode.json or opencode.jsonc. User edits remain user-owned and survive package updates, disables, and uninstalls.

Architecture

Core domain and compatibility

• Defines the opencode.marketplace/v1 catalog and install-plan model.
• Supports plugins, named skills, agents, commands, MCP servers, instructions, and mixed bundles.
• Uses stable SHA-256 listing and plan digests rather than presentation-only fingerprints.
• Enforces OpenCode version, platform, architecture, runtime, and capability requirements before installation.
• Adapts Codex .agents/plugins/marketplace.json catalogs and .codex-plugin/plugin.json manifests into the same install pipeline.
• Resolves repository-local, GitHub, GitLab, and public npm-backed Codex sources.
• Materializes Codex skills and MCP definitions normally; unsupported Codex apps/hooks fail compatibility checks rather than installing partially.

Registry and runtime overlay

SQLite/Drizzle is the source of truth for:

• ordered catalog sources;
• installed package state and explicit priority;
• per-package, per-skill, and per-MCP switches;
• monotonic registry revisions;
• artifact, fetch, and materialization metadata;
• durable mutation audit entries.

Writes are transactional and compare-and-swap revision aware. Stale clients receive a revision conflict instead of replacing newer state.

Active plans are projected into plugin, skills, agent, command, mcp, and instructions only in memory. Explicit package priority determines conflict resolution; disabling the active provider exposes the next eligible provider.

Immutable plan/apply lifecycle

Install, aggregate update, and profile import use the same two-phase flow:

1. Planning validates compatibility, trust, permissions, and configuration conflicts.
2. Every executable byte is fetched or copied and materialized into the content-addressed cache.
3. The service returns a short-lived, process-local, one-time plan_id.
4. Apply consumes that exact prepared plan once in a revision-checked transaction.
5. Apply never refetches a second copy of the reviewed bytes.

Aggregate update planning prepares all eligible updates before one atomic apply. Component choices are preserved where the updated package still declares the component, and updates never perform an implicit semantic-version downgrade.

Content-addressed cache

Catalogs, manifests, icons, plugin files, skills, and instructions are stored and verified by SHA-256 digest.

The cache additionally:

• deduplicates identical bytes;
• materializes immutable local trees;
• rejects local traversal and symbolic-link escapes;
• prevents network catalogs from reaching file:// artifacts;
• strips sensitive headers on cross-origin redirects;
• rejects HTTPS-to-HTTP redirect downgrades;
• bounds redirects, response sizes, package bytes, file/skill counts, and path lengths;
• verifies cached object hashes on read;
• permits validated stale data only for transient network failures, 408, 429, and server errors;
• never fails open to stale executable content after 401, 403, or 404;
• disables stale fallback entirely during strict plan materialization;
• retains installed artifact digests during pruning.

Private source secrets use header_env environment-variable bindings. Secret values are resolved only at request time and are never written to SQLite, returned by the API, or exported.

Profiles, locks, and audit

• Exports deterministic opencode.marketplace.profile/v2 profiles.
• Continues to accept and upgrade v1 profiles.
• Supports atomic profile planning/apply in merge or replace mode.
• Profiles contain portable intent and component state, not credentials, cache paths, receipts, or artifact bytes.
• Exports opencode.marketplace.lock/v1 locks containing package, materialization, and artifact digests.
• Verifies installed state against a lock.
• Exposes a durable, revision-ordered audit log.

User experience

Desktop

• Marketplace entry in both settings layouts and the command palette.
• Discover, Installed, Updates, and Sources views.
• Search and component-type filters.
• Publisher, provenance, version, license, setup, capability, compatibility, and conflict details.
• Install, update, update-all, uninstall, package enable/disable, and individual skill/MCP switches.
• Source add, enable/disable, remove, refresh, and cache-prune controls.

TUI

• Marketplace and Marketplace sources commands.
• Searchable package browser and installed-package management.
• Explicit trust and conflict confirmation.
• Package, skill, and MCP toggles.
• Source management, update-all, uninstall, refresh, and cache pruning.

CLI

opencode plugin marketplace add https://example.com/marketplace.json
opencode plugin marketplace list
opencode plugin marketplace install <key>
opencode plugin marketplace update
opencode plugin marketplace export marketplace-profile.json
opencode plugin marketplace import marketplace-profile.json --mode merge
opencode plugin marketplace lock marketplace.lock.json
opencode plugin marketplace verify marketplace.lock.json

Marketplace API

Desktop, TUI, and CLI use the domain control plane rather than replacing global configuration:

GET    /marketplace
POST   /marketplace/refresh
GET    /marketplace/icon/{source}/{catalog}/{item}
POST   /marketplace/plan
POST   /marketplace/install
POST   /marketplace/update-all
POST   /marketplace/update/plan
POST   /marketplace/update/apply
DELETE /marketplace/install/{key}
PATCH  /marketplace/install/{key}
POST   /marketplace/source
PATCH  /marketplace/source/{id}
DELETE /marketplace/source/{id}
POST   /marketplace/profile
POST   /marketplace/profile/plan
POST   /marketplace/profile/apply
GET    /marketplace/lock
POST   /marketplace/lock/verify
GET    /marketplace/audit
POST   /marketplace/cache/prune

Mutations accept expected_revision; install/update/profile apply operations also require a one-time plan_id. Listing supports cursor pagination. Public responses redact resolved headers, materialized plans, internal artifact references, and machine-local state.

The Effect HttpApi definitions are the source of truth, and both generated JavaScript clients were regenerated.

Source and catalog behavior

Sources may be HTTPS catalogs, loopback development catalogs, GitHub shorthand/repositories, conventional GitLab/Gitea repository URLs, local catalog files/directories, or file:// URLs.

Directory discovery supports:

• .opencode/marketplace.json;
• marketplace.json;
• .agents/plugins/marketplace.json;
• legacy-compatible .claude-plugin/marketplace.json.

Official and verified provenance cannot be spoofed by user configuration. Installed packages remain visible, toggleable, and removable when a source is disabled, unavailable, removed, or no longer publishes the item.

Additional reliability fixes

The final branch also retains validated fixes discovered while stabilizing the feature:

• portable repository-cache path comparison on Windows;
• serialized ripgrep provisioning and ZIP extraction without a PowerShell dependency;
• deterministic cleanup of non-interactive opencode run event subscriptions;
• order-independent timeline reconnect reconciliation;
• explicit plugin build dependency on generated SDK output.

Security model

Marketplace is a discovery, materialization, and configuration mechanism, not a sandbox.

• Plugins execute code inside OpenCode.
• Local MCP servers execute commands on the host.
• Remote MCP servers receive requests and may use credentials.
• Skills and instructions influence agent behavior.
• Agents and commands can alter model, tool, and permission configuration.

The UI exposes provenance, publisher, requested capabilities, compatibility failures, setup notes, and planned configuration before activation.

Migration policy

Marketplace has not shipped with the intermediate development formats. The final Drizzle migrations create the Marketplace registry and audit tables. OpenCode intentionally does not import experimental registry.json files, receipt snapshots, or Marketplace fields written into configuration by earlier branch revisions.

Validation

Current rewritten head was published only after the repository pre-push hook completed the full monorepo typecheck successfully: 30 tasks across the 36-package workspace scope.

Focused local validation also passed:

• Core typecheck and 41 marketplace/repository-cache/ripgrep tests;
• OpenCode typecheck and 20 marketplace/API/runtime tests;
• App typecheck and the reconnect suite repeated three times (21/21);
• TUI typecheck;
• HttpApi coverage, authentication, and Effect/runtime suites;
• regenerated client and CLI help snapshot checks;
• Drizzle incremental/full migration consistency;
• App and documentation builds;
• git diff --check.

The documentation is intentionally English-only. Temporary export, diagnostic, and validation workflows are not part of the final diff.