Import a plugin from a marketplace into a repo, so Claude and Codex both pick it up

[aviadr1]

Is your feature request related to a problem? Please describe.

AgentSync solves "one canonical config in .agents/, fanned out to every agent." But the unit teams actually distribute shared tooling in is increasingly the plugin (a .claude-plugin/marketplace.json marketplace, consumed by both Claude Code and Codex), and there is no way to get a plugin from a marketplace into a repo such that both Claude and Codex pick it up for everyone who clones it.

Doing it by hand turns out to be surprisingly awkward, and for Codex it isn't possible at all at repo level. I verified the following rather than assuming it:

Claude Code — repo-level works. A tracked .claude/settings.json with enabledPlugins + extraKnownMarketplaces auto-registers the marketplace and enables the plugin on clone. No per-user action.

Codex — repo-level does not exist. Both codex plugin marketplace add and codex plugin add write to the user's ~/.codex/config.toml and populate per-machine caches (~/.codex/.tmp/marketplaces, ~/.codex/plugins/cache). A project-level .codex/config.toml is merged, but only for some sections:

Section in project .codex/config.toml	Honoured?
[mcp_servers.*]	✅ yes
[plugins.*]	❌ ignored
[marketplaces.*]	❌ ignored

Method: a throwaway CODEX_HOME whose user config set enabled = false, run from a repo whose tracked project config set enabled = true. Both codex plugin list and a real codex exec session reported the plugin disabled/unavailable — identical to the control with no project config at all. A marketplace declared only in project config never appeared. (The [mcp_servers.*] row is positive evidence from the same setup: a server declared only in project config does show up in codex mcp list.)

Net effect: a plugin that Claude Code users get for free on clone requires every Codex user to run bootstrap commands by hand, and a fresh clone is silently missing the tooling until they do.

Describe the solution you'd like

A plugin-aware command, e.g.:

agentsync plugin add <plugin>@<marketplace>
agentsync plugin update <plugin>@<marketplace>
agentsync plugin list

with marketplaces declared in agentsync.toml alongside the existing [mcp] block, so agentsync apply reconciles plugins the same way it reconciles instructions and skills today. Concretely it would:

1. Fetch the plugin from its marketplace at a pinned revision.
2. Place its skills under .agents/skills/ so the existing symlink fan-out immediately gives Claude, Codex, Gemini and OpenCode access — no per-user install, works on clone.
3. Merge the plugin's MCP servers into the existing [mcp] mechanism. AgentSync already generates per-agent MCP config (.mcp.json for Claude, .codex/config.toml for Codex), and [mcp_servers.*] is precisely the section Codex does honour from project config — so this part would work end to end today.
4. Record real provenance (marketplace, plugin name, version, resolved revision, content hash) so update is a genuine refresh with drift detection.

This feels squarely in AgentSync's existing wheelhouse: it is the same "declare once, fan out per agent" problem, one level up from skills — and step 3 in particular is something AgentSync can do that neither vendor's CLI does.

Describe alternatives you've considered

• agentsync skill install <id> --source <dir> — closest existing thing, and it does put the skill in .agents/skills/ so every agent sees it. But it is skill-scoped, not plugin-scoped: it drops the plugin's agents/, MCP servers, scripts and manifest, and you must enumerate skills one by one. The registry also doesn't retain a usable origin — after installing from a local directory, registry.json recorded "source": "/tmp/.tmpXXXXXX" (a staging dir that no longer exists) with provider, version and manifestHash all null, so skill update can't resolve where it came from and --source must be re-supplied every time. A remote --source URL also 404s against private repos (no auth), so private marketplaces have to go through a local clone.
• A per-machine bootstrap script (codex plugin marketplace add … && codex plugin add …). Works, but it is exactly the per-user step that repo-level config is supposed to eliminate, and a fresh clone is broken until someone remembers to run it.
• Vendoring copies of the skills into each repo. Zero setup, but N copies drifting across N repos with no version or provenance — the thing you'd adopt a marketplace to avoid.

Additional context

Environment: agentsync 1.45.2, codex-cli 0.147.0, Claude Code 2.1.233, Linux.

Motivating case: a small set of shared engineering-practice skills (PR review, PR writing, testing standards) living in one internal marketplace repo and consumed by three sibling repos, where the team uses both Claude Code and Codex. The Claude half is a two-line commit; the Codex half currently has no repo-level answer at all.

Happy to test a prototype against a real private marketplace and report back.

[linear-code]

DALLAY-584