Copilot default enablement on 22 October: decide first

From 22 October 2026, copilot default enablement turns on every eligible generally available Copilot feature that your enterprise has left unconfigured, on Copilot Business and Copilot Enterprise alike. GitHub gave administrators 28 days to configure the policy first. Doing nothing is not a neutral position — the policy ships enabled, so silence means yes.

That distinction is the whole story, and it is the part most coverage of the changelog glosses over. The changelog presents three settings as if they were equal choices. GitHub's own documentation is blunter: "Unconfigured features will be enabled on October 22" because the policy is enabled by default. An admin who reads the changelog, decides to think about it, and comes back in November has already chosen Enabled.

What copilot default enablement changes on 22 October

The mechanism is narrow and worth stating precisely. On 22 October, any eligible feature sitting in an Unconfigured state adopts whatever the default policy says. Features you have explicitly switched on or off keep the state you gave them — explicit prior decisions remain unchanged.

Eligibility is defined by lifecycle, not by importance. Per GitHub's documentation, the policy applies to new general availability releases, features moving from preview to GA, and existing GA features still marked Unconfigured. It reaches beyond the feature toggles themselves: the Copilot code review policy and the MCP servers policy are both in scope.

Preview features are not. They stay opt-in, and if one later reaches general availability, the choice you already recorded for it is preserved rather than reset.

The three settings, and what each one commits you to

The changelog gives three values for the default policy, reachable from the AI Controls page under Copilot, as "Default policy for new features":

Setting	What happens on 22 October	What happens to future GA features
Enabled	Unconfigured eligible features become available to users	They arrive switched on, without a review
Disabled	Unconfigured eligible features stay unavailable	Each one needs administrator approval before use
Let organizations decide	The decision moves down to organization owners	Each organization answers for itself

The third option is the one worth thinking hardest about, because it is not a deferral — it is a delegation. In an enterprise with thirty organizations, "let organizations decide" means thirty independent answers to a question about data handling and third-party model access, made by owners who may not have been told a decision was coming. That is defensible if your organization owners are accountable for their own tooling. It is not defensible if the enterprise is the body that has to answer an auditor.

The strongest argument for Enabled is real and should be said plainly: blocking GA features by default produces a slow, ticket-driven adoption path that engineers route around, and the features most likely to be caught are the ones your developers already expect to have. If your Copilot rollout has been deliberate and your data handling is already settled at the enterprise level, Enabled is a reasonable answer. It should just be an answer, not an accident.

Enumerate the affected features from your own settings page

Do not work from a list — including this one. The set of features sitting in an Unconfigured state is specific to your enterprise, to when you bought Copilot, and to every policy decision made since. GitHub's documentation points administrators at the Features & clients page for their own enterprise, at github.com/enterprises/ENTERPRISE/ai-controls/copilot/features.

Open that page and read the state column before you touch the default policy. Three things are worth writing down as you go:

1. Every feature currently marked Unconfigured. This is the exact blast radius of the change, and it is the only list that matters.
2. The current state of the Copilot code review policy and the MCP servers policy, both of which the default policy reaches. MCP servers deserve their own conversation, because enabling them changes what a coding agent can reach outside GitHub.
3. Which supported clients — IDEs, the CLI, mobile — are unconfigured, since the same default governs those.

Organization owners have a parallel view under their own Copilot settings, where GitHub documents controlling the availability of Copilot features and models for users licensed by that organization. If you land on "let organizations decide", those owners need the enumeration exercise too, and they need it before 22 October rather than after.

What the policy does not touch

Some settings are explicitly out of scope, and knowing this prevents a wasted afternoon of re-checking. GitHub's documentation excludes restrictive model policies such as data residency and FedRAMP restrictions, along with session storage settings, from default availability. Those stay where you set them.

This matters for the common objection that the change is a compliance event. For most enterprises it is a feature-surface event: the controls that carry your regulatory commitments are not being flipped. What is being flipped is which tools appear in a developer's editor, and which of them will appear in future without anyone asking.

What to do inside the window

The window closes on 22 October 2026. As of 26 September 2026 that leaves 26 days, and the work is small enough to finish in one sitting.

1. Open the Features & clients page and export the current state of every feature, so you have a before picture you can diff against later. Screenshots are fine; the point is that you can prove what changed.
2. Decide the three-way policy at the enterprise level, and record why. "We chose Enabled because our data handling is settled enterprise-wide" is an audit answer. An empty setting is not.
3. Explicitly configure anything you would not want turned on, rather than relying on Disabled as the default. An explicit decision survives the next policy change; an Unconfigured state has now been shown not to.
4. If you delegate to organizations, tell the organization owners in writing what they are now responsible for, and by when.

The broader pattern is the one to take away. Copilot's administrative surface has been changing on dated schedules all year, and the six Copilot models that go on 19 October land three days before this policy does. In the AI engineering work we do for clients, the teams that handle these well are the ones treating vendor AI controls as configuration under change management — reviewed, recorded, diffable — rather than as settings someone checked once during onboarding.

That habit also decides how much of your review pipeline you are willing to automate. If the Copilot code review policy flips on by default, you have quietly changed who reads a diff first, which is a decision worth making on purpose rather than on a date. Teams building AI code review automation deliberately set the threshold themselves; the same care applies to what an agent can reach inside a workflow. Before 22 October, spend the hour: open the page, read the states, and make the choice while it is still yours to make.