Agent Plugins 1.0 Ships: What Still Does Not Port

Agent Plugins 1.0 reached general availability as a supported product feature on August 12, 2026 — GitHub’s changelog, published that day, announced GA support in VS Code, Copilot CLI, the GitHub Copilot SDK and the GitHub Copilot app, on all Copilot plans. That is the status change our August 8 coverage was waiting on, and it landed four days after we noted the spec page still read Status: Working Draft.

This post is the sequel, and it asks the follow-up question the GA headline invites: now that the portable package format is generally available somewhere, where does a plugin actually load? We checked four harnesses against their own current documentation rather than against launch lists or governance rosters — and the answer splits cleanly in half.

Along the way we untangle a detail most coverage flattened: there are two different partner lists behind this spec, not one, and the sharpest finding in the whole exercise sits in the gap between them. For the spec’s mechanics — the directory layout, the manifest, what v1 deliberately left out — see our August 8 first look; we will not re-explain it here.

When our first look ran on August 8, the central caveat was governance-versus-reality: the spec had been announced on August 6 with serious names attached, but the specification page itself still read Status: Working Draft, and richer vendor-specific formats kept shipping alongside it. The dated, unambiguous change since then is GitHub’s changelog of August 12: product support for Agent Plugins 1.0 is now generally available in VS Code, Copilot CLI, the GitHub Copilot SDK and the GitHub Copilot app, on all Copilot plans. The changelog opens with the standard’s whole pitch in one line: “You can now build a plugin once and use it across all compatible agent clients.”

The spec document itself, fetched at the time of writing, now opens with Status: Published — the Working Draft label is gone. What we cannot tell you is the day that label changed. The public commit history we checked for the spec file shows its most recent commit dated July 24, and we could not locate a commit that visibly edits the status field. So we will not assert a status-flip date, and neither should anyone else: the precisely dated event is the August 12 GA changelog, and the document’s Published label is corroborating color, not a second dated milestone.

Most coverage of this spec — including early drafts of our own notes — conflated two different lists that Vercel’s August 6 launch post keeps carefully separate. The first is the refiners: “Vercel initiated the proposal, which representatives from Amazon Web Services (AWS), Anysphere, GitHub, Microsoft, OpenAI, and Vercel refined collaboratively into Agent Plugins 1.0.0.” Six companies, Vercel included, GitHub included. The second is the governance body: “The initial Technical Steering Committee includes Core Maintainers from AWS, Cursor, Microsoft, OpenAI, and Vercel.” Five companies — and GitHub is not one of them.

That asymmetry is worth sitting with, because it cuts both ways. The company whose changelog delivered the GA moment, whose marketplace distributes plugins by default, and whose surfaces carry the most complete documented support is named only in the broader refiner sentence — not on the committee that governs the spec. Meanwhile, as sections 03 and 07 show, sitting on that committee turns out to guarantee nothing about what a vendor’s own products load. Who wrote the spec, who governs the spec, and who ships the spec are three different lists.

The method matters more than usual here, because this spec’s launch produced three overlapping rosters — refiners, Core Maintainers, and a launch-day client list. Vercel’s August 6 post claims support “at launch” across five bullets naming six product brands: ChatGPT and Codex, Cursor, GitHub Copilot, Kiro, and VS Code. Claude Code is not on that list. But a launch-list bullet is a claim made by one vendor’s blog about another vendor’s product — so for the matrix below, the only evidence that counts is each harness’s own current documentation. Where that documentation does not state support for the 1.0 package format, we record undocumented rather than inferring an answer from a partner list in either direction.

Read column by column and the table makes three different arguments. The launch-list column and the docs column disagree in one cell — OpenAI’s — and that disagreement is the story. The TSC column and the docs column disagree in the same cell. And the one harness with a clean sweep of “no” answers, Claude Code, is arguably the least surprising row of the four: Anthropic appears on neither partner list, and the docs page we checked makes no support claim, so there is no gap between claim and documentation. One footnote outside the matrix: AWS’s Kiro, also on the launch list, documents “Agent Plugin support for Powers” in its own changelog — light corroboration that the launch list and vendor docs can agree, which makes the cells where they do not stand out more.

GitHub’s GA is the most complete implementation on paper as well as the most precisely dated. The VS Code documentation describes Agent Plugins as “an open standard for packaging agent skills and MCP servers that works across multiple AI agents, including GitHub Copilot in VS Code, GitHub Copilot CLI, and the GitHub Copilot app,” documents the canonical manifest with its $schema identifier, and specifies the plugin-root tokens — including ${PLUGIN_DATA}, a writable state directory that persists across plugin updates and has no equivalent token in the Claude or Copilot native formats per the same table. Support toggles with the chat.plugins.enabled setting.

For teams already shipping Copilot plugins, the changelog is explicit that nothing breaks: existing plugins that do not target Agent Plugins 1.0 “remain supported, with no migration required.” Distribution runs through the Awesome Copilot marketplace, available by default in VS Code, Copilot CLI and the Copilot app. And governance carries over wholesale — Business and Enterprise customers control Agent Plugins with the same managed-settings.json mechanism they already use, via enabledPlugins, extraKnownMarketplaces and strictKnownMarketplaces, with “no separate Agent Plugins policy” required. Given what this year’s plugin-marketplace security incidents taught, allowlist-based governance carrying over unchanged is a genuine adoption argument, not boilerplate.

One limitation deserves repeating because it defines the portable format’s real perimeter: the VS Code documentation states that “VS Code currently ignores client extension data and directories in Agent Plugins 1.0 packages.” A plugin that bundles another client’s namespaced extras will load its portable skills and MCP components in VS Code — and silently drop the rest. That is the spec working as designed: skills and MCP servers port; agents, hooks and slash commands remain client-specific, exactly the boundary our August 8 post mapped.

Cursor is the cleanest row in the matrix — a named Core Maintainer whose shipped product documents exactly what the membership implies. Its docs state that “Cursor supports the Agent Plugins open standard alongside its own plugin format,” and make the compatibility claim in the most direct language any vendor uses: “A plugin that follows the Agent Plugins specification loads in Cursor without changes.”

The mechanics mirror the VS Code pattern of a portable floor beneath a richer native ceiling. Cursor auto-detects two formats from the manifest itself: spec-conformant Agent Plugins — plugin.json at the plugin root with the standard’s $schema, carrying skills and MCP servers only — and native Cursor Plugins at .cursor-plugin/plugin.json, which additionally carry rules, agents, commands, hooks and variables. Team and Enterprise marketplaces distribute both formats side by side under the same access and installation-mode controls (Default Off, Default On, Required), and either format can be dropped into ~/.cursor/plugins/local/ for local testing. The authoring guidance splits the same way: the project’s own plugin-authors page for portable plugins, Cursor’s template for native ones.

Anthropic appears on neither of Vercel’s two lists and is absent from the launch-day client bullets, so Claude Code’s undocumented verdict is expectation-matching rather than a gap. But the details are worth spelling out because they show how close and how far “structurally adjacent” can be at the same time. Claude Code’s plugin manifest lives at .claude-plugin/plugin.json, not the plugin.json at the plugin root the spec requires. Its MCP configuration file is .mcp.json with a leading dot, not the spec’s mcp.json without one. Neither “Agent Plugins” nor the standard’s schema URL appears anywhere on the plugin documentation page we checked.

The one genuinely shared piece is the skills directory: Claude Code’s skills/ layout matches what the spec’s skills component expects — because both build on the separate, shared Agent Skills specification, not because Claude Code implements Agent Plugins 1.0. The practical consequence for a plugin author: a package written strictly to the 1.0 manifest would not be discovered by Claude Code without renaming and relocating both the manifest and the MCP config. Skills port conceptually; MCP server definitions travel as content but not as a discovered file. And there is a neat corroborating detail from the other side of the matrix: VS Code’s own docs treat “Claude” as a separate, fourth manifest format needing its own detection logic — even the standard’s most complete implementer handles Claude Code’s format as a non-standard peer, not as an implementation of the spec.

This is the sharpest finding in the matrix, and it is the answer to the question in this post’s title. OpenAI sits on the five-company Technical Steering Committee as a named Core Maintainer. Vercel’s launch post lists “ChatGPT and Codex” among the products supporting Agent Plugins at launch. And yet OpenAI’s own current plugin documentation — the single page we fetched covering plugins in both ChatGPT and Codex — makes no mention of Agent Plugins, the standard’s schema, or conformance of any kind.

What that page describes instead is an entirely proprietary taxonomy: “Plugins bundle capabilities into reusable workflows in ChatGPT and Codex. They can include skills, connectors, or both. Both products use one universal plugin directory.” A plugin in OpenAI’s current documentation can bundle skills, connectors, MCP servers, browser extensions, hooks and scheduled task templates, distributed through OpenAI’s own Plugins Directory — with no visible relationship to the portable directory-and-manifest contract the company co-maintains. The vendor that helped write the portability standard documents, on the page we checked, a plugin system that does not reference it.

What OpenAI did ship, one day before the GA changelog, deepens the picture. Its August 11 release notes announce a Linux desktop preview and “agent imports”: the desktop app imports “instructions, settings, skills, plugins, projects, and recent work” from Claude Code, Claude Cowork and Cursor, and Codex CLI’s /import command now reads Claude Code setup as well as Cursor’s. This extends the Cursor-skills import — our August 10 coverage owns that story and the SKILL.md mechanics; we will not re-tell it. The two releases are one day apart and easy to conflate: the August 10 news was Codex CLI reading Cursor-managed skills, the August 11 news broadens the CLI to Claude Code and adds a desktop-app-level import covering plugins and Claude Cowork.

The mechanism is the tell. Every row of OpenAI’s own import table maps a source-specific field into a Codex-native destination — nothing in it reads an Agent Plugins 1.0 package:

A few operational specifics from the same documentation: Codex CLI imports up to 50 chats from the trailing 30-day window; the page states that importing “doesn’t change or delete your existing agent setup”; and /import is unavailable during a running task, in a remote session, or while connected to a local app-server daemon. None of that is a criticism — a source-specific translator is arguably the fastest way to onboard a competitor’s users, and it reaches configuration surfaces the portable format deliberately excludes, like hooks and subagents. But it is the clearest evidence for this post’s tension: in the same week the portable package format reached GA, one of its Core Maintainers shipped a bespoke per-vendor bridge that reads rival harnesses’ native files directly — a translator, not a consumer of the standard it co-designed.

None of this argues against the standard. A floor that two major harness families load natively, four days into GA, is more portability than agent tooling had a month ago. It argues for authoring with the matrix open — treating documented support, not partner lists, as the unit of planning.

Looking forward, the interesting question is which direction the two undocumented rows resolve. The cheap prediction is convergence: skills already share a spec across all four harnesses, and the remaining deltas — a manifest path, a dot-prefixed filename — are small enough that either vendor could close them in a point release. The harder question is whether they want to: bespoke bridges like /import onboard competitors’ users asymmetrically, which is a business reason for a maintainer to ship a translator before a consumer. If your team is standardizing agent tooling across harnesses and needs the portability question answered for your own stack rather than in general, that packaging-and-governance audit is exactly the kind of work our AI transformation engagements start with.