Reuse the Extension You Built Once Across Different Agents — Copilot CLI Adopts the Open Plugin Spec and MCP Config, While the Sandbox Moves Toward "Locked by Default"
The latest release of GitHub Copilot CLI can now read the vendor-neutral "Open Plugin Spec" and MCP configuration files. Extensions built for other agents can be carried over as-is, while the default settings for the OS sandbox have moved toward tightening.
Copilot Can Now Read Extensions Built for Other Tools
On July 23, 2026, GitHub released v1.0.74 of its command-line AI coding assistant, GitHub Copilot CLI. What stands out is its support for Open Plugin Spec v1, a specification for extension packages, and for configuration files in the mcp.json format. As a result, the "plugins" and external tool integration definitions prepared for agents other than Copilot can now be loaded by Copilot CLI as-is.
The Open Plugin Spec is an open specification whose stated goal is to avoid being tied to any particular vendor. It standardizes "skills" that add capabilities to an AI agent, along with "MCP (Model Context Protocol) servers" that serve as connection points to external data and tools, into a single catalog (manifest) called plugin.json that can be distributed. MCP was originally a mechanism popularized by Claude, and it is now being adopted across the industry, including in VS Code's agent features (preview) and Codex. Copilot CLI's support this time means GitHub itself has joined that trend.
Extensions Become a "Portable Asset"
Until now, the work of embedding custom skills or tool integrations into an agent differed subtly from tool to tool in how it was written and where it was placed, forcing you to recreate the same setup in multiple places. Once agents can read a common catalog format and MCP configuration, the following changes can be expected.
- Less rework: an extension packaged once can be carried across Copilot, VS Code, and other agents.
- Team sharing: because extensions can be treated as distributable artifacts, you can hand out a full set of company-standard integrations and skills.
- Lower switching costs: you are less locked into tool-specific settings, making it easier to swap out your choice of agent.
In other words, extensions move closer from being "settings that only work in that one tool" to being a "portable asset."
Opening Up on One Side, Tightening the Sandbox's Defaults on the Other
Around the same time, Copilot CLI moved in the opposite direction on the containment of its execution environment (the sandbox), tightening it even as it widened the door for extensions.
- In v1.0.74, on first launch it displays a prompt asking whether to enable the default sandbox, adopting a scheme where
gitandghauthentication within the OS sandbox is enabled optionally. - A few days earlier, v1.0.72 turned access to the macOS keychain off by default, strengthening isolation a notch.
It has long been pointed out that the more portable extensions become, the more the risk of an "extension-borne supply chain" — where plugins or MCP servers of dubious origin slip in — can spread to each agent. The fact that the move to widen the intake for capabilities and the move to tighten the execution environment's defaults are advancing in tandem can be read as the flip side of exactly that.
What to Check Before Adopting It for Unattended Operation
Copilot CLI has seen a steady stream of updates at short intervals through July. Here is a summary of the main developments.
| Version / Release date | Main content |
|---|---|
| v1.0.72 (7/20) | Keychain access off by default; skill management from the CLI added |
| v1.0.74 (7/23) | Open Plugin Spec v1 and mcp.json support; first-run prompt for the default sandbox; gemini-3.6-flash support |
| v1.0.75 (7/24) | Claude Opus 5 support |
From an automation and unattended-operation standpoint, combining this with the change announced on July 2 — that you can run it inside GitHub Actions using the built-in GITHUB_TOKEN (no personal access token required) — makes it easier to build a setup that runs Copilot CLI on CI. That said, when adopting it, keep the following points in mind.
- In GitHub's official documentation, the sandbox feature is positioned as a public preview, so the possibility of specification changes remains.
- The sandbox and in-sandbox authentication are optional (opt-in); they are not tightened to the maximum by default. You need to configure them explicitly to match your own organization's policy when adopting it.
- The premise that the origin and permissions of the plugins and MCP servers you bring in must be verified on the user's side has not changed.
The more interoperability of extensions advances, the more the development floor's burden seems set to shift — beyond "which agent to use" toward "which extensions and connections to run, and with how much permission."
References: GitHub Copilot CLI Releases / Open Plugin Spec / Agent plugins in VS Code (Preview) / Copilot CLI no longer needs a PAT in GitHub Actions / Gemini 3.6 Flash is now available in GitHub Copilot