{"slug": "agent-plugins-1-0-ships-what-still-does-not-port", "title": "Agent Plugins 1.0 Ships: What Still Does Not Port", "summary": "GitHub announced on August 12, 2026 that Agent Plugins 1.0 is generally available as a supported product feature in VS Code, Copilot CLI, the GitHub Copilot SDK, and the GitHub Copilot app on all Copilot plans. However, a review of four harnesses' documentation shows only VS Code and Copilot surfaces confirm full support, while Claude Code and OpenAI's plugin docs do not mention the standard. OpenAI, a named Core Maintainer and launch-day client, still describes a proprietary format, highlighting that governance membership does not guarantee shipped support.", "body_md": "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.\n\nThis 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.\n\nAlong 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](/blog/agent-plugins-1-0-open-standard-portable-ai-skills); we will not re-explain it here.\n\n- 01The GA event is dated and precise.GitHub’s changelog, published August 12, 2026, announces generally available Agent Plugins 1.0 support in VS Code, Copilot CLI, the Copilot SDK and the Copilot app, on all Copilot plans. Existing Copilot plugins remain supported with no migration required.\n- 02There are two partner lists, and they differ.Vercel’s August 6 launch post names six companies that refined the spec — AWS, Anysphere (Cursor), GitHub, Microsoft, OpenAI and Vercel itself — but the Technical Steering Committee of Core Maintainers is five companies, and it excludes GitHub.\n- 03Only two of four harnesses confirm support in their own docs.VS Code and the Copilot surfaces document full support, and Cursor’s docs state a spec-conformant plugin loads without changes. Claude Code’s and OpenAI’s current plugin docs do not mention the standard on the pages we checked.\n- 04OpenAI is the gap that answers the headline.OpenAI is a named Core Maintainer and appears on the launch-day client list, yet the plugin page we checked describes a proprietary format with no Agent Plugins 1.0 conformance stated. Governance membership is not shipped support.\n- 05Bespoke bridges keep shipping alongside the standard.OpenAI’s August 11 release extends /import to read Claude Code and Cursor setup directly — a per-vendor translator into Codex-native formats, not a consumer of the portable package the same company co-maintains.\n\n## 01 — The Status ChangeFour days after our Working Draft note, product support went *generally available*.\n\nWhen [our first look](/blog/agent-plugins-1-0-open-standard-portable-ai-skills) 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.”\n\nThe 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.\n\n##### Vercel’s launch post\n\nVercel initiated the proposal; six companies refined it collaboratively into Agent Plugins 1.0.0. Launch-day support was claimed across five client bullets naming six product brands.\n\n##### Working Draft noted\n\nOur coverage stated the spec page still read Status: Working Draft at that time, and framed the open question as the gap between the announcement and shipped, documented support.\n\n##### GitHub’s changelog\n\nGenerally available support in VS Code, Copilot CLI, the Copilot SDK and the Copilot app, on all Copilot plans. Existing Copilot plugins remain supported with no migration required.\n\n*product support*reached general availability on GitHub’s four Copilot surfaces — it is a claim about those products, dated by GitHub’s own changelog. It is not a claim that the spec document flipped status on that day, and it is not a claim about any other vendor’s shipping status. The rest of this post is about that second question.\n\n## 02 — GovernanceTwo partner lists, *not* one.\n\nMost 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.\n\nThat 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.\n\n##### Six *refiners*\n\nAWS, Anysphere (Cursor), GitHub, Microsoft, OpenAI — and Vercel itself, which initiated the proposal. This is the collaboration list, and it is the wider of the two.\n\n##### Five *Core Maintainers*\n\nAWS, Cursor, Microsoft, OpenAI, Vercel. GitHub appears only in the broader refiner sentence, not in the governance list — a distinction Vercel’s own post maintains and most coverage dropped.\n\n*GitHub’s claim*, not settled fact, until the project’s own governance pages reflect it.\n\n## 03 — The MatrixFour harnesses, checked against their *own* docs.\n\nThe 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.\n\n| Harness | Core Maintainer (TSC)? | On the Aug 6 launch list? | Own docs confirm 1.0 load support? |\n|---|---|---|---|\n| VS Code / Copilot CLI / Copilot SDK / Copilot app | Microsoft: yes. GitHub: refiner list only | Yes — VS Code and GitHub Copilot | Confirmed — manifest schema, directory layout and plugin-root tokens documented |\n| Cursor (Anysphere) | Yes | Yes | Confirmed — “loads in Cursor without changes,” alongside the native format |\n| Claude Code (Anthropic) | No | No | Undocumented — different manifest and MCP filenames; no mention of the standard on the docs page checked |\n| ChatGPT / Codex (OpenAI) | Yes | Yes — bullet-listed | Undocumented — the plugin page we checked describes a proprietary format; a bespoke /import bridge ships instead |\n\nRead 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.\n\n“You can now build a plugin once and use it across all compatible agent clients.”— The opening line of the August 12 GA changelog\n\n## 04 — ConfirmedThe Copilot surfaces: *deepest* documented support.\n\nGitHub’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`\n\nidentifier, and specifies the plugin-root tokens — including `${PLUGIN_DATA}`\n\n, 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`\n\nsetting.\n\nFor 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`\n\nmechanism they already use, via `enabledPlugins`\n\n, `extraKnownMarketplaces`\n\nand `strictKnownMarketplaces`\n\n, with “no separate Agent Plugins policy” required. Given [what this year’s plugin-marketplace security incidents taught](/blog/ai-agent-plugin-security-lessons-clawhavoc-2026), allowlist-based governance carrying over unchanged is a genuine adoption argument, not boilerplate.\n\n##### For an existing Copilot plugin\n\nAdd $schema to plugin.json; keep skills under skills/ and MCP configuration in mcp.json; move Copilot-specific files into the com.github.copilot/ directory, which other clients ignore.\n\n##### Auto-detected by VS Code\n\nAgent Plugins 1.0, Copilot, Claude and Legacy OpenPlugin — the portable format is one of four the client still detects side by side, told apart by manifest path and $schema.\n\n##### GA on all Copilot plans\n\nThe changelog states support is generally available on all Copilot plans, with no tier restriction stated — and existing non-conformant plugins keep working untouched.\n\nOne 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.\n\n## 05 — ConfirmedCursor: the row where governance and shipping *agree*.\n\nCursor 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.”\n\nThe 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`\n\nat the plugin root with the standard’s `$schema`\n\n, carrying skills and MCP servers only — and native Cursor Plugins at `.cursor-plugin/plugin.json`\n\n, 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/`\n\nfor 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.\n\n## 06 — UndocumentedClaude Code: structurally *adjacent*, formally elsewhere.\n\nAnthropic 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`\n\n, not the `plugin.json`\n\nat the plugin root the spec requires. Its MCP configuration file is `.mcp.json`\n\nwith a leading dot, not the spec’s `mcp.json`\n\nwithout one. Neither “Agent Plugins” nor the standard’s schema URL appears anywhere on the plugin documentation page we checked.\n\nThe one genuinely shared piece is the skills directory: Claude Code’s `skills/`\n\nlayout 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](/blog/mcp-server-ecosystem-tracker-50-servers-cataloged-2026) 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.\n\n## 07 — UndocumentedOpenAI: the *maintainer* gap.\n\nThis 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.\n\nWhat 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.\n\n*not*a claim that support is absent everywhere — OpenAI’s developer-facing plugin-build documentation was outside the pages we checked, and a conformance note could exist there or arrive tomorrow. The honest finding is narrower and still striking: a Core Maintainer’s primary plugin documentation, at the time of writing, shows no trace of the standard it maintains.\n\n## 08 — Adjacent EvidenceThe bespoke bridge shipping *alongside* the standard.\n\nWhat 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`\n\ncommand now reads Claude Code setup as well as Cursor’s. This extends the Cursor-skills import — [our August 10 coverage](/blog/codex-cli-cross-harness-skill-portability-lock-in) 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.\n\nThe 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:\n\n| Imported item | Codex-native destination |\n|---|---|\n| Instruction files | AGENTS.md |\n| settings.json | config.toml |\n| Skills | Codex Skills |\n| Plugins | Codex Plugins |\n| Existing project folders | Codex Projects (same folders) |\n| Project memories from Claude Code | Codex Memories |\n| Chats from the last 30 days | ChatGPT chats |\n| MCP server configuration | Codex MCP configuration |\n| Hooks | Codex hooks |\n| Slash commands | Codex Skills |\n| Subagents | Codex agents |\n\nA 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`\n\nis 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.\n\n## 09 — Practical GuidanceWhat to do with a *half-portable* standard.\n\nNone 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.\n\n##### Author to the portable floor\n\nPut everything you can into the two portable components — skills and MCP servers — with the canonical manifest and $schema. Keep client-specific extras in extension namespaces, and expect clients to ignore each other’s: VS Code documents dropping them today.\n\n##### Adopt *now*\n\nGA on all Copilot plans, no forced migration, and governance rides the managed-settings.json mechanism you already run — enabledPlugins and marketplace allowlists apply unchanged, with no separate Agent Plugins policy required.\n\n##### Keep the native format\n\nThe docs page we checked makes no conformance claim, and the manifest and MCP filenames differ from the spec’s. The skills directory is the genuine overlap — structure skills to the shared Agent Skills shape and they stay portable in substance.\n\n##### Verify per vendor, per quarter\n\nThe gap between governance rosters and shipped support is the finding of this post. Before standardizing a team on one packaging format, re-check each harness’s own current documentation — launch lists and maintainer seats have already proven unreliable proxies.\n\nLooking 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`\n\nonboard 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](/services/ai-transformation) start with.\n\n## 10 — ConclusionThe standard is real. So is the *gap*.\n\n### Governance membership is not shipped support.\n\nThe sequel headline is genuinely good news: four days after our first look noted a Working Draft label, GitHub’s August 12 changelog put Agent Plugins 1.0 support at general availability across four Copilot surfaces on all plans, and Cursor’s docs load a conformant plugin *without changes*. A build-once plugin now has two major places to run, with documented manifests, marketplaces and governance on both.\n\nBut the answer to “what still does not port” is not a file format — it is the distance between the spec’s rosters and the vendors’ own documentation. Six companies refined the spec; five govern it; two of the four harnesses we checked document loading it. The starkest cell belongs to a Core Maintainer whose plugin page, as we checked it, describes a proprietary system with no conformance stated, while it ships a bespoke import bridge that reads rival harnesses’ native files directly. Until a vendor’s own documentation says a package loads, no launch list or committee seat says it for them.\n\nOur advice from August 8 survives GA intact, with one upgrade: author to the portable floor, keep client extras namespaced — and plan against the matrix of documented support, re-checked on the vendors’ own pages, because this week demonstrated that every other roster measures something else.", "url": "https://wpnews.pro/news/agent-plugins-1-0-ships-what-still-does-not-port", "canonical_source": "https://www.digitalapplied.com/blog/agent-plugins-1-0-ga-what-still-does-not-port", "published_at": "2026-08-16 00:00:00+00:00", "updated_at": "2026-08-18 03:42:12.965333+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "ai-products"], "entities": ["GitHub", "VS Code", "Copilot CLI", "GitHub Copilot SDK", "GitHub Copilot app", "Vercel", "AWS", "Anysphere"], "alternates": {"html": "https://wpnews.pro/news/agent-plugins-1-0-ships-what-still-does-not-port", "markdown": "https://wpnews.pro/news/agent-plugins-1-0-ships-what-still-does-not-port.md", "text": "https://wpnews.pro/news/agent-plugins-1-0-ships-what-still-does-not-port.txt", "jsonld": "https://wpnews.pro/news/agent-plugins-1-0-ships-what-still-does-not-port.jsonld"}}