Marketplaces & plugins

This is where agentsync earns its keep. A plugin is a bag of components — MCP servers, skills, subagents, commands, hooks, LSP servers. Install it once and every enabled agent gets the components it understands.

Install a plugin

1. Add a marketplace (a registry of plugins):

   agentsync marketplace add github:anthropics/claude-plugins-official

2. Install a plugin from it:

   agentsync plugin add atlassian@anthropic

3. Fetch from the network — plugin outdated is the polling verb of the daily loop:

   agentsync plugin outdated

4. Apply — renders from the local cache to all agents:

   agentsync apply

polling fetches, apply renders

plugin outdated is the daily loop’s networked verb (plugin add, plugin upgrade, marketplace add, import <agent>:plugin, and init <git-url> fetch too). It refreshes the local plugin cache and recomputes version pins. apply then renders entirely from that cache — so it’s fast, offline, and reproducible. See Updating from the network.

The translation report

Each component in a plugin is projected independently per agent — fully, lossily, or skipped — and the report tells you exactly which:

plugin: atlassian@anthropic
  claude    ✓ full    (1 mcp, 5 commands)
  opencode  ◐ partial (1 mcp; 5 commands → projected)

Inspect a plugin’s coverage without applying:

agentsync plugin explain atlassian@anthropic
agentsync plugin explain atlassian@anthropic --json

Controlling per-plugin fan-out

Two keys in a plugin’s TOML decide which agents its components render to:

~/.agentsync/plugins/atlassian.toml

[plugin]
id            = "atlassian@anthropic"
agents        = ["claude"]   # only fan this plugin out to Claude
# native_agents = ["claude"] # OMIT unless an agent installs this itself (see below)

agents is your allowlist — ["*"], or omitted, means every enabled agent. It is a deliberate, security-relevant choice: a plugin’s MCP servers, hooks, and skills can carry ${secret:…} credentials, so agents = ["claude"] keeps that blast radius scoped to Claude only.

native_agents is different in kind — not a preference but a fact about your machine. An agent whose own plugin manager installs a plugin (you ran /plugin install in Claude Code) already serves its components. agentsync never disables a plugin inside another tool’s plugin manager, so projecting the same components into that agent’s standalone paths would simply duplicate them: two of every skill, subagent and command, and every hook firing twice. Listing the agent here stops the projection for that agent only.

A component renders for an agent when agents targets it and native_agents does not claim it.

`import` asks about this, per plugin

agentsync import claude:plugin just discovered the plugin installed in Claude, so it offers the deferral: “Let claude keep serving this plugin? [Y]es / [n]o, project it there too”. Accepting records native_agents = ["claude"]; every other enabled agent still gets the full fan-out. Declining warns that agentsync will duplicate the plugin’s content there and that you should disable it inside Claude yourself. Under --no-input or a non-TTY stdin the deferral is recorded without asking, so a scripted import never silently produces two of everything.

To hand the plugin over to agentsync completely, uninstall it in the agent and drop that agent from the list.

Because apply never inspects your agents’ installed plugins (that is what keeps a render reproducible from your dotfiles repo alone), a plugin you install natively after declaring it in agentsync goes unnoticed at apply time — agentsync status and agentsync doctor report that pair instead.

Per-component overrides are not wired in v1

A per-component [plugin.overrides.<agent>] table was specced but the projector does not consult it in v1 — use the keys above.

Lifecycle commands preserve your targeting

plugin disable/enable and re-running plugin add on an already-registered plugin preserve its agents allowlist and native_agents list (and its update mode and disabled state) — they never silently re-broaden a narrowed plugin back to every agent. Adopting a plugin (uninstalling it in the agent, then dropping that agent from native_agents) sticks, because the agent no longer reports the plugin as installed — and if you drop the entry WITHOUT uninstalling it there, the next import asks again rather than silently re-deferring. Only id/version/manifest_sha are refreshed by a re-install (from the fresh fetch); when a re-install keeps non-default targeting, the command says so (e.g. (kept agents=[claude], update=pinned)).

Plugin lifecycle

agentsync plugin add <id[@marketplace]>
agentsync plugin upgrade  <id[@marketplace]>
agentsync plugin enable   <id[@marketplace]>
agentsync plugin disable  <id[@marketplace]>
agentsync plugin remove   <id[@marketplace]>
agentsync plugin list

disable/enable flip only the disabled bit. add rewrites only the three fields it re-fetches (id, version, manifest_sha) and carries every other field agentsync models in plugins/<id>.toml forward from the file you have; a key you omitted, or an agents or update you left empty, is written with its default. The file is rewritten, so comments and unmodelled keys are not kept. Your agents and native_agents targeting survives the full lifecycle.

Agent capability matrix What each agent supports per component, what each ◐ loses, and how to read the report.