GitHub Copilot's 'Default Policy for New Features' Takes Effect October 22 - Enabled by Default, and Unconfigured Features Open Up If Left Alone

GitHub announced on September 24, 2026 that it had introduced a new global default policy for generally available Copilot features in enterprise and organization Copilot settings ¹. Administrators can configure it starting the day of the announcement, but it does not affect what users can reach until October 22; for the 28 days in between, changing the setting does not change actual behavior.

What matters for administrators is the policy’s initial value. The official documentation states plainly that the policy is enabled by default, and that if you take no action, unconfigured features will be enabled on October 22 ². Leaving it untouched until the deadline is therefore not a decision to keep things as they are — it is a decision to open up the features that currently sit unconfigured.

What Falls Within Scope

The setting lives on the “AI Controls” page, under the “Copilot” subpage, as an item labeled “Default policy for new features” ¹. Three options are available: Enabled, which makes current and future eligible features available to users by default; Disabled, which keeps current eligible features unavailable and requires administrator approval for future eligible ones; and Let organizations decide, which hands the choice to organization administrators.

Despite the name, the policy is not limited to features that have yet to arrive. According to the documentation, the setting determines the enablement status of three things: new features reaching general availability (GA), features moving from preview to GA, and existing GA features that are currently Unconfigured in your policy settings ². Items left unconfigured in an environment already in use will all fall in line with the global default on October 22.

The scope of “feature” is also spelled out. It covers any policy configured on an enterprise’s “Features & clients” page, plus the Copilot code review policy on the “Agents” page and the MCP servers in Copilot policy on the “MCP” page ². That agent-facing functionality is named explicitly is worth noting for organizations that pay attention to permission design. Copilot code review in particular is in the middle of gaining configuration layers: when review effort levels reached general availability in August, administrators set an organization-wide default that repositories inherit unless they specify their own.

Exclusions are stated as well. The policy does not apply to features in preview, and if you opt into a preview that later becomes generally available, your existing choice is preserved ¹. As for policies exempt from the mechanism itself, the documentation lists the restrictive model policies on GHE.com — Restrict Copilot to data residency models and Restrict Copilot to FedRAMP models — along with Store local sessions in the Cloud for Copilot CLI and VS Code ².

Explicit Settings Are Left Alone, Which Is the Remedy

When the default policy takes effect, features an administrator has already explicitly enabled or disabled will not be overridden ¹. Put the other way around, the only items that move on October 22 are the ones still sitting Unconfigured, so the remedy comes down to two choices: configure them individually before the deadline, or turn the default policy itself off.

GitHub has built something to help with the first route. The policy settings screen displays a banner showing how many eligible policies are currently unconfigured, so administrators can gauge what the global default would do and configure individual policies before October 22 ². For the second route, the documentation describes disabling the default policies in enterprise or organization settings — either across the whole enterprise, or only in organizations with stricter compliance requirements. It is also possible to keep the default policies enabled while explicitly disabling individual features so they are not eligible for automatic enablement.

How the layers interact carries a condition. The policy can be configured both at the enterprise and in its organizations, but at the enterprise level it applies to features labeled Unconfigured, while at the organization level it applies only to features an enterprise owner has set to Let organizations decide and an organization owner has not explicitly configured ². Once the enterprise side picks Enabled or Disabled, no room for judgment is left on the organization side.

The Feature Policy and the Models Policy Are Separate

One confusing aspect is that Copilot has two default-availability policies. The documentation says that whether unconfigured GA features and models default to enabled or disabled is governed by “two separate policies” ². The models-side policy, Default availability for released models, is already active and affects new and unconfigured GA models. What takes effect on October 22 is the features side.

On the models side, GitHub announced general availability of the global model policy on August 26, which introduced a state called Delegate to Default Policy. Models an administrator has not explicitly configured carry that label, and a newly released model inherits the default until it is explicitly configured ². The models side does come with an out-of-scope list: pre-GA models, open weight models (DeepSeek, Kimi K2.7 Code, Kimi K3), and models not covered by GitHub’s data retention agreement (Claude Fable 5, Claude Fable 5.1) stay disabled by default regardless of the default policy setting.

Separately, choosing which model serves as the default for new conversations is a different axis, configurable through enterprise-managed settings, and plays a different role from today’s policy on whether a feature may be used at all.

October 22 Joins a Run of Effective Dates

On August 28, GitHub had already given advance notice of three effective dates for Copilot policy and billing changes: September 1, September 28, and October 1. Seat prepayment, chat data retention periods, and the default code review effort level were separate matters, but each asked administrators to check their settings by a given date. October 22 joins that run in the same form.

As background for this pattern, the documentation frames the benefit of having the policies enabled as letting users benefit from the latest features and models without administrator intervention ². It reads as a design that absorbs, on the default-value side, the gap between how fast features ship and how fast approval work can keep up. Which also means that the more an organization wants approval in the loop, the more worthwhile it is to check whether the default value points the opposite way from its policy. GitHub recommends keeping up with new releases and GA announcements, which appear in its changelog, so that enablement settings can be chosen deliberately.

The documentation lists the plans that can use this feature as Copilot Business and Copilot Enterprise ². For anyone administering Copilot for an organization, the task is bounded: open the unconfigured-count banner before October 22, look at what is in it, and separate the items that can be left to the default from the ones worth setting explicitly. That takes fewer steps than walking back features that quietly became available after the date.

Sources

1. Default Enablement of Copilot features for Copilot Business and Enterprise - GitHub Changelog (September 24, 2026)
2. About default availability of Copilot features and models - GitHub Docs (accessed September 26, 2026)