[Feature]: 支持导入三方插件市场

[renguangqian1993]

Product or interface

Desktop app

Use case and problem

增加三方插件，如”claude-plugins-official“，以增强mcode。

目前不支持导入插件市场，只支持导入“插件”。

Desired behavior

支持导入三方插件市场。参考zcode

[hetaoBackend]

This was generated by AI during triage.

@renguangqian1993 — clear and reasonable ask, and it's a real gap rather than a misunderstanding. I checked what already exists so you know how close this is.

What I verified (against main)

Marketplaces are already a first-class concept in the plugin system — the gap is specifically adding/importing a new (third-party) source, not the marketplace model itself:

• The plugin CLI (packages/tui/src/cli/plugin-command.ts) already has marketplace-list and marketplace-upgrade actions, and plugin selectors are marketplace-qualified — you address a plugin as name@official, name@local, etc. (:137-146).
• There's a typed McodePluginMarketplace used throughout the selector/plumbing, and a registry-client.ts for pulling plugin/catalog data.
• What I did not find on main is any "add / import / register a new marketplace" path (no known_marketplaces / installLocation / addMarketplace equivalent in the runtime). The @official / @local naming also suggests only built-in marketplaces are currently wired up.

So the good news: the selection, listing, and per-marketplace plumbing you're asking to plug into largely exists; what's missing is the onboarding step for a new marketplace source (and the resolution/refresh logic behind it).

Why this matters beyond convenience

This isn't only a power-user feature. A closely related report — #344 (Desktop in-app browser control) — turned out to hinge on exactly this: the browser-control capability depends on a marketplace-sourced plugin, and on a clean install the marketplace's installLocation was a dead path, so the plugin never resolved. Supporting importable third-party marketplaces is part of the plumbing that makes marketplace-delivered capabilities (and their failure modes) manageable. I'd treat this as connected to that work.

Classification

• Category: enhancement (as filed) — new capability on top of existing marketplace plumbing.
• State: needs-triage — it's a well-scoped feature that fits the existing architecture, but touches marketplace trust/resolution (where a source points, how it's refreshed, what a bad source can do), so it deserves a maintainer decision on scope and safety before implementation. (This tracker has no ready-for-human label, so needs-triage + this note is the routing.)

A couple of design points worth settling

1. Trust model for an imported marketplace. An imported source can point anywhere; the resolution/refresh path is what [Bug]: Desktop In-App Browser control not authorized on 3.0.73 - controlAuthorized: false #344 tripped over. Worth deciding up front what a third-party marketplace is allowed to do (read-only catalog? install into the user profile? pinned vs floating source?) — this is the substance of the feature, not just plumbing.
2. Reference implementation. You pointed at ZCode; if its approach (and the claude-plugins-official layout) is the model, attaching the concrete manifest/URL shape you expect to import would help size it.

This looks like a good, achievable feature given the existing selector/registry plumbing. Thanks for the clear write-up and the reference.

No credentials or sensitive data echoed.