Agent Plugins 1.0 Makes Agent Tools Portable. Trust Still Does Not Travel.
GitHub has turned Agent Plugins 1.0 from an interesting specification into usable distribution infrastructure.
On August 12, GitHub made the format generally available across VS Code, Copilot CLI, the Copilot SDK, and the Copilot app, on every Copilot plan. A maintainer can now put skills and MCP server definitions in one package, expose it through a marketplace, and reach GitHub's editor, terminal, embedded SDK, and desktop surfaces without maintaining four unrelated bundles.
That is a meaningful shift. Agent extensions are starting to acquire the boring property that made browser extensions, containers, and language packages powerful: a recognizable unit of distribution.
But “write once, run everywhere” is the wrong conclusion. Agent Plugins 1.0 standardizes a deliberately narrow floor. Skills and MCP configuration travel. Agents, hooks, commands, rules, LSP servers, canvases, authentication, permissions, update policy, installation, and user experience do not. A conformant client can ignore unsupported components or vendor namespaces and still conform.
So the useful way to read GitHub's launch is this: the directory is becoming portable, while behavior and trust remain local. That moves competition away from manifest syntax and toward marketplaces, policy engines, provenance, runtime quality, and compatibility testing. It also creates a new supply-chain boundary. The easier it becomes to install one agent package across many clients, the more expensive a bad package becomes.
The format did not begin this week. The public specification repository dates to April. Version 1.0.0 was published in late July, and OpenAI Codex 0.146.0 added Agent Plugins support on July 29. RohitAI covered that earlier move in Codex CLI 0.146.0 Moves the Agent Boundary Out of the Terminal.
The multi-vendor project was publicly announced on August 6. Then Qwen Code shipped preview support for Agent Plugins v1 early on August 12, even though it was not yet in the official client directory at research time.
GitHub's August 12 GA announcement matters because it joins four mature distribution surfaces at once. It also makes Awesome Copilot the default marketplace across VS Code, Copilot CLI, and the Copilot app. Existing Copilot-format plugins continue working, so maintainers can adopt the standard without a flag-day migration.
The official compatibility directory now names VS Code, Cursor, GitHub Copilot, ChatGPT and Codex, Kiro, Hermes Agent, OpenClaw, and Grok Bot. That list spans editors, CLIs, personal agents, and always-on teammates. It is broad enough to treat the format as a credible interoperability layer, though the directory is living and self-reported rather than a public conformance test suite.
One precision point is worth preserving. The specification page identifies version 1.0.0 but labels the document “Working Draft.” The repository calls 1.0.0 the current published release. That is not a reason to dismiss it; software standards often evolve in public. It is a reason to avoid pretending an external standards body has frozen every edge.
The portable layout is intentionally plain:
review-assistant/
├── plugin.json
├── skills/
│ └── pull-request-review/
│ ├── SKILL.md
│ ├── scripts/
│ └── references/
├── mcp.json
└── com.github.copilot/
├── agents/
├── hooks/
└── commands/
The required root plugin.json declares the canonical schema and a package name. Skills are discovered only from immediate child directories under skills/ that contain SKILL.md. Portable MCP servers live in root mcp.json; they cannot be smuggled into the manifest under a custom core field.
Everything else belongs outside the portable core. Reverse-domain namespaces such as com.github.copilot let a package carry client-specific behavior without lying about its portability. A client that does not implement that namespace must ignore it.
That escape hatch is not a weakness. It is probably why the format could ship. Standardizing every agent concept now would freeze immature abstractions and force clients into the same product design. Version 1 chooses the two pieces with the strongest existing agreement: reusable instructions and MCP-based tool connections.
The portable package is the center layer. Discovery, richer behavior, execution policy, and updates still belong to each host.
Sourced fact: version 1 defines skills and MCP servers, permits incremental client support, and assigns no portable semantics to vendor namespaces.
RohitAI's interpretation: the ecosystem is settling on a thin portability kernel surrounded by competitive vendor shells. File layout will commoditize faster than distribution, trust, and runtime behavior.
Teams will get into trouble if they reduce compatibility to “the manifest parses.” There are at least four separate tests.
| Layer | What 1.0 gives you | What still varies | Proof you need |
|---|---|---|---|
| Structural | One manifest, fixed skill and MCP locations | Installer and marketplace metadata | Schema validation |
| Capability | Skills and declared MCP transports | Unsupported transports and vendor namespaces | Per-client capability matrix |
| Behavioral | Common package inputs | Prompt assembly, tool UX, errors, and approvals | End-to-end task tests |
| Operational | A package clients can load | Updates, secrets, audit, rollback, and policy | Controlled promotion in a real fleet |
This distinction is visible today. The standard describes stdio, Streamable HTTP, and legacy SSE MCP entries, but an MCP-capable conformant client only has to implement at least one of stdio or Streamable HTTP. SSE is optional. The client directory says ChatGPT and Codex support stdio and Streamable HTTP, while several other listed clients also document legacy SSE.
VS Code adds another concrete difference. Its Agent Plugins documentation says it currently ignores client-extension data and directories in version 1 packages. GitHub says Copilot-specific agents, commands, rules, and hooks can live under com.github.copilot across its own clients. The same directory can therefore be valid in both places while offering a richer experience in one.
Open formats are often assumed to weaken platform control. Here, the effect is subtler.
When package syntax becomes common, maintainers spend less time repackaging the same skill. But users still need somewhere to discover it. Enterprises still need a way to approve it. Someone still chooses update cadence, private-source support, search ranking, publisher identity, and installation UX.
That makes the registry more strategic, not less. GitHub can support a vendor-neutral package while using Awesome Copilot as a distribution advantage. Cursor, OpenAI, AWS, or an enterprise artifact vendor can do the same with their own catalogs and policy layers. The package travels; the route to users does not.
This leads to the first non-obvious implication: marketplaces will compete on trust metadata before the core format grows it. The project's future-considerations document explicitly leaves signatures, provenance, permission declarations, dependencies, audit events, enterprise controls, and a validation harness outside version 1. Those omissions create the product surface for registries.
Expect enterprise catalogs to add immutable version pinning, attestations, scanning results, compatibility badges, approval history, and rollbackable promotion channels. JFrog is already framing plugins as software supply-chain artifacts, though that is a vendor position rather than proof that one registry model will win.
Put reusable skills and MCP definitions in the standard locations. Keep this layer small, deterministic, and useful without any vendor namespace.
Use a reverse-domain namespace for richer agents, hooks, commands, rules, or canvases. Document the graceful fallback when another client ignores it.
Add provenance, pinning, review, compatibility evidence, staged updates, and policy integration outside the version 1 manifest.
The second-order security problem is easy to miss. An Agent Plugin is a package, but mcp.json can describe processes and remote endpoints that expose their own tools. Package trust and tool trust are different decisions.
The spec has sensible containment rules: plugin-relative paths cannot escape the package root, non-loopback remote MCP endpoints must use HTTPS, and visible environment or header values must not be treated as a secret mechanism. But the specification is explicit that path containment is not a subprocess sandbox. Version 1 has no portable OAuth or credential-reference fields. Authentication, secret storage, prompting, and runtime isolation belong to the client.
VS Code makes the operational boundary unusually clear. Enabled plugin MCP servers start automatically, and the VS Code docs say they are implicitly trusted after plugin installation rather than receiving a separate startup trust prompt. That is not evidence of an Agent Plugins vulnerability. It is evidence that install approval can authorize future code execution and tool exposure.
The surrounding ecosystem has already shown why publisher trust matters. Independent reporting found malicious AI-branded VS Code extensions that exfiltrated files, but those were VS Code extensions, not Agent Plugins 1.0 packages. The distinction matters. The lesson is about distribution and review, not a demonstrated flaw in this specification.
GitHub's enterprise settings reflect the two-layer problem. Admins can control plugins with enabledPlugins, known marketplaces with extraKnownMarketplaces and strictKnownMarketplaces, and MCP separately with allow/deny rules and sandbox controls. Teams should use both sets. RohitAI's earlier analysis of RufRoot's MCP bridge compromise is a useful reminder that an MCP connection can widen execution and memory-poisoning blast radius even when the surrounding package looks tidy.
PLUGIN_DATA quietly creates a state ABIThe most interesting builder detail is not in the headline. Clients that launch stdio MCP servers must provide PLUGIN_ROOT and a writable, per-plugin PLUGIN_DATA directory. The latter persists across plugin updates and may be removed on uninstall.
That turns stored state into part of the plugin's application binary interface. A plugin may keep installed dependencies, caches, generated code, indexes, or user state there. Once an update expects a new schema, rollback can fail unless the author planned for it. Cache invalidation and migrations become cross-client concerns even though version 1 defines no lifecycle hooks for them.
This is the third non-obvious implication: portable packaging arrives before reproducible operation. Manifest version is optional. SemVer is recommended rather than mandatory. There are no portable dependency declarations, signatures, migrations, or shared test harness. A package can be structurally portable and still produce different results because the host resolves a bare executable differently, retains old state, injects different credentials, or updates from a mutable branch.
Builders should treat PLUGIN_DATA like a database:
PATH or environment variables are identical across hosts.GitHub's editor and CLI support will get most of the attention. The SDK may matter more over time.
The Copilot SDK plugin-directory documentation includes examples for TypeScript, Python, Go, .NET, Java, and Rust. Applications can inject plugin directories into a session, which makes a plugin a composition primitive for embedded agents—not merely a developer preference stored in an IDE.
That opens several useful patterns:
For deterministic deployments, COPILOT_PLUGIN_DIR_ONLY=true suppresses ambient plugin discovery. That flag deserves more attention than it will get. Without it, a developer's personal marketplace installs can silently change the tool surface of a test or headless run. Reproducibility begins by making the loaded plugin set explicit.
Do not migrate by deleting your existing client package. GitHub's own guidance is additive: declare the canonical schema, place portable skills under skills/, move reusable MCP configuration to mcp.json, and move Copilot-only material under com.github.copilot/. Remove legacy structure only after target-client tests pass.
The output of that work should be a small evidence bundle: the exact artifact digest, source repository and revision, requested permissions and credentials, MCP server inventory, compatibility results, state migration version, and rollback procedure. None of that is glamorous. It is what turns portability into production infrastructure.
Agent Plugins 1.0 will not erase vendor lock-in. It will relocate it.
The lowest layer—where a skill lives and where MCP config goes—should become less differentiating. That is good for authors. Above it, clients will compete on how well they execute long-running work, expose approvals, isolate tools, debug failures, and preserve state. Marketplaces will compete on discovery and trust. Enterprises will compete on how quickly they can promote a plugin from experiment to approved infrastructure.
Three predictions follow.
First, recognizable portability profiles will emerge even if the specification never names them: skills-only, skills-plus-MCP, and vendor-enhanced. Compatibility pages will become more useful than a single conformant badge.
Second, registries will implement signing, attestations, scanning, and compatibility metadata faster than the core project standardizes them. Buyers need those controls now, and the format intentionally leaves them open.
Third, plugin packages will become deployment units for product agents. The SDK support in six languages and the directory-only switch point toward controlled agent assembly in servers and CI, not only customization in chat panes.
The Agent Plugins governance charter is designed to prevent one vendor from holding a majority of core-maintainer seats. That is a healthy start. It cannot guarantee equal distribution power, equal client behavior, or equal trust controls—and it should not be expected to.
The version 1 bargain is narrower and more credible: agree on the package's center, then let clients and registries compete around it.
GitHub's launch proves that bargain can attract enough hosts to matter. The next test is whether the ecosystem can make a portable plugin predictable, inspectable, and reversible. Until then, agent tools can travel farther than the trust needed to run them.