Copilot plugin controls reach GA: Verify required and optional installs

On October 28, 2026, GitHub made repository plugin defaults and enterprise plugin controls generally available in VS Code, Copilot CLI, and the GitHub Copilot app. A trusted repository can now install and enable default plugins for its contributors. An enterprise can make a plugin mandatory, block it, or restrict the marketplaces users can install from.

Setting a convenience plugin to true in enterprise enabledPlugins makes it a requirement users cannot turn off. An approved marketplace added only to extraKnownMarketplaces leaves the installation-source restriction unset. Choose the scope before distributing either setting.

Repository defaults are available to individual, Business, and Enterprise Copilot users. The managed controls require GitHub Enterprise Cloud and a Copilot Business or Enterprise license issued by the enterprise or one of its organizations. This guide follows GitHub's documentation and proposes administrative acceptance checks; General Analysis has not exercised them in a customer deployment.

Separate availability, defaults, and requirements#

GitHub's plugin concepts guide distinguishes a marketplace being available, a plugin being installed, and its components being enabled in a session. Treat those as separate fields in your rollout record.

The configuration semantics come from GitHub's plugin administration guide. The verification column is our proposed acceptance procedure.

GitHub explicitly says managed plugin settings require or block; they do not provide an optional enterprise default. A repository default also cannot override a managed block or use a disallowed marketplace.

Deploy a policy with one clear installation path#

For server delivery, use copilot/managed-settings.json on the default branch of the enterprise's designated .github-private governance repository. GitHub's setup guide ties that policy to the user's enterprise license, even if the user cannot read the governance repository.

Reading a private plugin catalog is a different requirement. The marketplace setup instructions require members to have read access to its repository. A user can receive a valid policy and still be unable to install its required plugin.

The following hypothetical policy offers one company catalog, restricts marketplace installation to it, requires a review helper, and blocks a retired plugin. Replace the repository and plugin identifiers with reviewed assets. The catalog key must match the name in marketplace.json; plugin keys use plugin-name@marketplace-name.

Code source: illustrative configuration using GitHub's enterprise-managed settings schema.

Review the consequences before deploying this example. strictKnownMarketplaces disables built-in marketplaces, and [] means complete lockdown. The example's autoUpdate: false disables automatic updates for this catalog; it does not establish that installed files are trustworthy or prevent every manual update. Assign someone to review and distribute plugin fixes so the temporary update choice does not become an abandoned patch process.

The settings reference allows a managed autoUpdate value to require or disable automatic refresh and plugin updates for that marketplace. If omitted, client defaults or user configuration apply. Record the choice explicitly when predictable update behavior matters.

Use the existing managed-permissions deployment guide for delivery diagnostics, license selection, refresh requirements, and device policy. A successful repository commit alone does not establish that a running client loaded it.

Keep the project's optional plugin optional#

Suppose the same catalog contains a formatter that is useful for one repository but unnecessary elsewhere. Put its default in that project's .github/copilot/settings.json, leaving it out of managed enabledPlugins:

Code source: illustrative configuration using GitHub's CLI repository settings.

In the CLI, a developer can put the same key with false in .github/copilot/settings.local.json; keep that personal file out of Git. This opt-out cannot disable the enterprise-required review-helper. GitHub also documents reading the shared plugin-setting subset from .claude/settings.json and .claude/settings.local.json. Include those files in a configuration review when a repository supports both tools.

In VS Code's Copilot harness, the Agent Customizations editor lets users turn off optional plugins without editing shared defaults. Confirm the selected harness before comparing results across developers. The Local harness has a different recommendation flow, and VS Code documents separate inventories for /plugin commands and the editor. Inspect the interface used to install the plugin.

Review team exceptions as complete source policies#

Enterprise teams can add plugin entries to the baseline. However, team overrides use different semantics for marketplace settings: an eligible overridable marketplace map or allowlist can be replaced by the team's value.

For example, a team allowed to replace strictKnownMarketplaces must include every catalog it still needs. A team list containing only an experimental catalog can omit the source of a baseline-required plugin. Before approving that exception, resolve the team's complete catalog list and required-plugin list together. Do not repair an installation failure by removing the restriction before checking this mismatch.

Keep mandatory marketplace restrictions outside team override unless an exception is intentional. Review the team mapping and membership with the policy change, because the effective population determines who can install from the additional source.

Accept the rollout on the client#

Start with a small licensed pilot group on supported, current clients. GitHub's plugin standards documentation requires supported versions and describes policy application when users authenticate. The general managed-settings client list does not prove that every property works in every runtime. Keep this rollout scoped to the release's named clients until you verify any additional surface.

Use harmless, reviewed fixture plugins for these checks. Do not introduce unknown executable plugins to test a restriction.

1. Record the signed-in account, license source, client version, harness, governance revision, team membership, and policy refresh result. Follow the existing delivery diagnostics before changing a rule that appears absent.
2. Confirm that the required fixture installs and stays enabled after a local disable attempt. Separately confirm its expected components are available in a fresh session. Installation does not prove that a skill runs on every task.
3. Enable the blocked fixture in repository defaults and verify that managed policy keeps it disabled. Check the reported state rather than relying on the model declining to use it.
4. Turn off the optional formatter locally, reopen the repository, and confirm that the opt-out survives while the required fixture remains enabled. Confirm that the shared repository settings did not change.
5. Check the approved and unapproved source paths and the catalog's automatic-update setting. Record rejections, missing catalog access, and any unverified behavior as separate outcomes.

Retain the actual result beside each expected result. An unknown result stays unknown; do not roll it into a fleet-wide pass. Expand only the client and identity combinations with explainable results.

A required plugin still needs an execution boundary#

Plugins may bring executable hooks and MCP servers onto the device. VS Code's plugin guidance warns that these components can run local code. Review the plugin contents and its credentials before requiring it across an enterprise. A mandatory review skill is available to the agent; that alone does not make it an unavoidable security check.

An approved catalog also does not prove the integrity of every installed artifact. Keep source and installed-copy review in the plugin supply-chain response procedure, and use coding-agent security controls for sandboxing and action permissions.

For urgent containment, do not treat a newly committed block as proof that existing processes stopped or credentials were revoked. Verify fresh policy receipt and disablement, then check the affected session and downstream service through your normal incident procedure. Preserve the evidence needed to determine what ran before the block.