Agent Plugins 1.0 goes GA across VS Code, Copilot CLI and the Copilot app

The moment I stopped shipping the same plugin twice

Every time I have shipped a Copilot plugin, some part of me knew I would end up shipping it twice. Once for the editor, once for the CLI, once more for whichever surface a teammate insisted on. So the GitHub changelog line dated August 12 landed as a quiet relief for me: Agent Plugins 1.0 is now generally available across VS Code, Copilot CLI, the GitHub Copilot SDK and the Copilot app, on all Copilot plans. One package, four places it can attach.

If you have never authored one of these, the friction is the point. You had skills, you had an MCP server config, and you had a slightly different envelope for every host. Now GitHub says compatible clients can discover the skills and MCP server configuration they support from the same package. That is the whole pitch, and if you have been threading agent tooling into pipelines and IDEs in the same week, it changes what "supporting Copilot" costs you.

What the release actually does

The change is small and load-bearing. Agent Plugins 1.0 is a shared package format that is portable across the three Copilot surfaces plus the SDK. Installations flow through a marketplace called Awesome Copilot, which ships enabled by default in VS Code, Copilot CLI and the Copilot app.

A few things worth noting from the changelog itself:

• The support is described as generally available across all Copilot plans, so this is not gated behind a preview flag.
• Existing Copilot plugins that predate the 1.0 spec keep working. There is no forced migration.
• Skills live under skills/, MCP configuration lives in mcp.json, and any files that only make sense inside Copilot land in a com.github.copilot/ directory that other compatible clients ignore.

The last bullet is the one I keep re-reading. That directory pattern is how a portable format tolerates a vendor-specific escape hatch without turning back into a fork. Every client sees the same tree, and the Copilot-only bits are quarantined by convention.

Why this shows up on a CI/CD desk

If your pipeline already touches any of these surfaces, and most of them do now, plugins are the seam where "agent behaviour" becomes "code you own". A skill you ship in skills/ is a thing your build can generate, sign and version. An mcp.json you ship in the same package is a thing your reviewer can diff in a PR. The move to one artifact means the review, the provenance and the release cadence collapse into a single object.

That has a knock-on effect on rollout. When a plugin was three ports, teams tended to update the surface they used most and drift on the other two. One package with one release means the CLI and the app catch up automatically, which matters when the plugin talks to a production MCP server and you would rather not have three versions of your tool contract in the wild.

The DX win on any given day is modest. The compounding win over a quarter is bigger. You author once and you post-mortem once.

Migrating a plugin you already ship

The changelog spells out the mechanical bits, and they are short. If you have an existing Copilot plugin, three moves get you onto the 1.0 spec:

// plugin.json
{
  "$schema": "<url-of-agent-plugins-1.0-schema>"
  // your existing fields stay
}

Then check that skills live under skills/, MCP config sits in mcp.json, and anything Copilot-specific is moved into the com.github.copilot/ folder so other clients skip it cleanly. That is the migration. Everything else the changelog promises to leave alone.

If you are starting fresh, the pull is stronger. You pick up marketplace discovery via Awesome Copilot without extra work, and you inherit whatever installation UX the surface owner ships without writing it yourself.

The enterprise knobs worth reading twice

For anyone whose day job includes signing off on what installs itself into a developer laptop, the governance surface is worth reading twice. The changelog names three settings inside managed-settings.json:

• enabledPlugins for automatic installation or blocking
• extraKnownMarketplaces to add sources
• strictKnownMarketplaces to restrict to managed sources

That last flag is the one I would flip early. A marketplace that ships enabled by default is convenient. A marketplace that ships enabled by default without a way to lock the source list would keep me up. strictKnownMarketplaces puts the org back in charge of where plugin code comes from, and it does so before the "which plugins" question, which is the right order.

Rough edges I would keep an eye on

Enthusiasm with the receipts still attached. A few things I would want to watch settle before I recommend this to a friend running a hundred-engineer org:

1. The marketplace ships enabled by default. Fine for reach, less fine for a security team that wants a curated allowlist before anyone can install. If you are in a regulated setting, wire up strictKnownMarketplaces on day one.
2. Backward compatibility is a promise, not a plan. Pre-1.0 plugins keep working today. The open question is how long, and whether newer marketplace features quietly become 1.0-only over the next few releases.
3. Portability is a claim about compatible clients. The four GitHub-owned surfaces are the ones the changelog names. Third-party editors and CLI hosts that say they are Copilot-compatible will have their own catch-up schedules.

None of these are dealbreakers. All are worth a five-minute conversation with whoever owns your dev-tools policy.

How other agent surfaces are approaching the same problem

Portable plugin formats are having a moment across the agent ecosystem. The Model Context Protocol has been doing the same job at the transport layer, giving skills and tools a shared way to describe themselves regardless of which host loads them. Editor extension ecosystems (the VS Code marketplace being the obvious ancestor) already showed how much friction a shared package format removes once tooling catches up. Terminal-first agents typically ship their own plugin shapes, pinned to that vendor's CLI. Watching one release land Agent Plugins 1.0 across an editor, a CLI and an app is the first time I have seen a large vendor try to hit all three surfaces with a single artifact.

The interesting comparison in six months will not be "is Agent Plugins 1.0 portable enough?" It will be "which non-Copilot host actually implements it?" A shared format lives or dies by the second implementation.

What I am watching next

Two things. First, whether plugin.json picks up a proper signing story over the next few releases. Portable plugins without a portable trust story are a bigger blast radius, not a smaller one. Second, whether Awesome Copilot grows a machine-readable curation layer a security team can point at. If both of those show up, this stops being a DX release and starts being an infrastructure release, and I will happily write that one up too.