Changes confirmed medium confidence

GitHub Rolls Out Agent Plugins 1.0 Across Copilot Clients

One package can now carry skills and MCP server configuration across VS Code, Copilot CLI, the SDK and Copilot app, with enterprise controls applying across supported clients.

GitHub announced on August 12, 2026 that Agent Plugins 1.0 support is generally available in VS Code, Copilot CLI, the GitHub Copilot SDK and the GitHub Copilot app. The release gives plugin authors a common package for agent skills and Model Context Protocol server configuration instead of requiring a different wrapper for every supported client.

The change matters to developers maintaining reusable agent tooling and to administrators deciding which packages and MCP connections can enter managed environments. GitHub says support spans all Copilot plans, while organization controls are available to Copilot Business and Enterprise customers.

What GitHub changed

Agent Plugins 1.0 defines a portable package rather than a new agent runtime. GitHub's release connects that package to four Copilot surfaces: VS Code, Copilot CLI, the Copilot SDK and the Copilot app. A compatible client can inspect one package and load the parts it supports.

The immediate benefit is less duplicated packaging. A deployment runbook and its MCP integration, for example, can travel together instead of being maintained as separate client-specific bundles. Existing GitHub Copilot plugins that do not target the new specification remain supported, so general availability does not impose an immediate migration deadline.

GitHub also preserves room for client-specific behavior. Copilot-only files can live under a namespaced `com.github.copilot/` directory, allowing custom agents, commands, rules and hooks to accompany the portable core without changing what another client sees.

What the 1.0 package standardizes

The published specification requires a root `plugin.json` manifest. Agent skills live as immediate child directories under `skills/`, each with its own `SKILL.md`, while MCP server configuration lives in a root `mcp.json`. Skills and MCP servers are the two portable component types defined by version 1.0; installation interfaces, marketplaces and update behavior remain client responsibilities.

That boundary is important. The format standardizes where components are found and how their metadata is validated, but it does not promise identical behavior in every host. Clients may support different component types, and unsupported components can be ignored. The specification also requires package paths to stay within the plugin root, yet explicitly separates that file-containment rule from sandboxing a plugin subprocess. Portability is therefore not the same as a universal security guarantee.

What authors and administrators need to check

For authors, GitHub describes migration as mostly manifest and directory-layout work: declare the Agent Plugins schema in `plugin.json`, keep portable skills and MCP configuration in their fixed locations, and move Copilot-specific material into the GitHub namespace. Teams should still test each target client because the sources provide no cross-client conformance results or independent interoperability measurements.

For managed organizations, existing Copilot settings can govern the new format. Administrators can automatically install or block plugins, add approved marketplaces, or restrict installation to known marketplaces. GitHub says those controls apply across supported Copilot clients and do not require a second Agent Plugins policy. MCP allowlists remain a separate control for approving or blocking individual servers by URL, command or name.

The practical checkpoint is whether plugin authors consolidate formerly duplicated packages and whether multiple clients implement the same portable components consistently. Neither fetched source reports adoption, failure rates, security review outcomes or real-world migration costs, so the release is confirmed but internal confidence remains medium.

Status

Confirmed. GitHub's official changelog establishes general availability, and the published specification defines the package contract. Both sources are controlled by the initiative and do not provide independent deployment testing.

Sources

Update note: Last reviewed 2026-08-13. We will revise this post if the maintainers publish compatibility results, migration changes or material security guidance.

Sources

Drafted with AI assistance from source briefs; reviewed for citation completeness and label accuracy.

More Changes coverage