feat: Add curated plugin marketplace + Metadata Cleanup.#13712
feat: Add curated plugin marketplace + Metadata Cleanup.#13712
Conversation
xl-openai
commented
Mar 6, 2026
xl-openai
commented
- Add a synced curated plugin marketplace and include it in marketplace discovery.
- Expose optional plugin.json interface metadata in plugin/list
- Tighten plugin and marketplace path handling using validated absolute paths.
- Let manifests override skill, MCP, and app config paths.
- Restrict plugin enablement/config loading to the user config layer so plugin enablement is at global level
xl-openai
force-pushed
the
xl/plugins
branch
3 times, most recently
from
e42f342 to
4a8ad1a
Compare
There was a problem hiding this comment.
nit: we should update this to say that the curated root is also considered when present
| #[serde(default)] | ||
| skills: Option<String>, | ||
| #[serde(default)] | ||
| hooks: Option<String>, |
There was a problem hiding this comment.
should we include hooks before its officially added? or can we just add it once it's been implemented, and maybe leave a comment for now? right now the field isn't consumed.
codex-rs/core/src/plugins/manager.rs
Outdated
| return PluginLoadOutcome::default(); | ||
| } | ||
|
|
||
| self.start_curated_repo_sync(); |
There was a problem hiding this comment.
plugin/list reaches this indirectly, which starts sync in the background, but marketplace listing still just checks whether the curated checkout already exists on disk. so on the first call after enabling plugins, plugin/list can omit curated entries just because the async clone/update has not finished yet.
should we move curated-catalog init to a marketplace/catalog lifecycle (i.e., first plugin/list after opt-in, or when enabling plugins feature)? and either block until sync is done or return an explicit syncing/not-ready state? or is best-effort enough? dont have a strong opinion, but want to clarify.
There was a problem hiding this comment.
basically it feels a bit unexpected to have this network/git side effect run in what seems to be a read helper: plugins_for_layer_stack(). im wondering if this should be a more first-class member or lifecycle in PluginsManager.
There was a problem hiding this comment.
Good call move to PluginsManager.
| config: &Config, | ||
| additional_roots: &[AbsolutePathBuf], | ||
| ) -> Result<Vec<ConfiguredMarketplaceSummary>, MarketplaceError> { | ||
| let installed_plugins = configured_plugins_from_stack(&config.config_layer_stack) |
There was a problem hiding this comment.
right now installed just means there's an entry for the plugin in config, should we at least check if the plugin dir exists in cache? the user could have old plugins listed in config so installed seems like its too strong.
sayan-oai
left a comment
sayan-oai
left a comment
There was a problem hiding this comment.
also approving to unblock as the logic all seems sound, most of my comments are about organization/nits
2 participants
