Copilot Decides for You on 22 October

GitHub gave enterprise admins 28 days' notice on 24 September to decide something most of them have never decided explicitly: what should happen to a Copilot feature nobody has an opinion about. On 22 October 2026 the answer stops being “nothing”.

This is a small change with a long tail, and the coverage of it has focused on the wrong half. The interesting part is not that some features switch on. It is that one of the three available settings is a permanent delegation, and it is the one that reads like the convenient choice.

What actually flips

GitHub's changelog entry describes “a new global default policy for generally available GitHub Copilot features and supported client capabilities in enterprise and organization Copilot settings.” It applies to Copilot Business and Copilot Enterprise, and the scope it names is three places: eligible features on the enterprise Features & clients page, the Copilot code review policy on the Agents page, and MCP servers in Copilot policy.

The supporting documentation is more precise about what the policy governs: whether “unconfigured generally available (GA) features and models default to enabled or disabled.” Three categories fall under it — new GA features, features that move from preview to GA, and “existing GA features that are Unconfigured”, with that third category becoming active on 22 October 2026.

Two exclusions are stated plainly, and they are the reassuring part. The policy does not apply to features an administrator has already configured — GitHub's wording is “explicit decisions are preserved. If you've explicitly enabled or disabled a feature, we won't override that choice.” And it does not apply to features in preview, which stay opt-in and keep their configuration if they later graduate to GA.

So the exposure is precisely the set of toggles currently showing Unconfigured. If you rolled Copilot out by deciding each feature deliberately, you have nothing to do. If you rolled it out by enabling the two things people asked for and leaving the rest alone, that untouched remainder is the thing with a date on it.

---

Three settings, one of which is not a decision

Setting	GitHub's definition	Applies to future features?
Enabled	“Current and future eligible features will be available to users by default.”	Yes, automatically
Disabled	“Current eligible features will remain unavailable, and future eligible features will require administrator approval.”	Yes, but gated on approval
Let organizations decide	“Organization administrators can choose whether to enable or disable eligible features.”	Delegated downward

Read the Enabled row again. It is not a statement about the features that exist on 22 October. It is a subscription. Every future capability GitHub promotes to general availability arrives switched on, and the only notice you get is whatever appears in the changelog that week. GitHub published Copilot-related changelog entries on four consecutive days, 22 to 25 September 2026 — sandboxing, telemetry, code review configuration, client releases, chat integrations. At that cadence, “current and future” is a meaningful rate of unreviewed surface area.

Disabled is the stricter mirror of the same mechanism: future features require administrator approval, which means someone has to go and grant them, which means adoption of anything genuinely useful will lag by however long your change process takes. That is the honest trade, and for a regulated environment it is the correct one.

“Let organizations decide” is the option that quietly creates work. It pushes the same unconfigured problem down a level: at organization scope, the policy applies to features the enterprise owner set to Let organizations decide but the organization owner has not explicitly configured. One delegation, N organizations, N new decision surfaces. If you have twelve orgs you have just created twelve copies of the audit you were trying to avoid.

The one that is not a feature toggle

MCP servers being named in scope is the item that deserves separate treatment, because an MCP server is not a UI feature. It is a channel between the coding assistant and something else — an internal API, a database, a ticket tracker, a third-party service — and the security question it raises is about egress and tool permissions, not about whether developers like the autocomplete.

The protocol itself has been moving fast: the 2026 spec revision removed sessions and the handshake, and server implementations written in 2025 have needed real work to keep up. Treating “MCP servers” as one row in a defaults table is convenient for GitHub's policy model and a poor fit for how the risk actually distributes. If your enterprise has any position at all on which external services a developer tool may reach, configure that row explicitly rather than letting a global default answer it. The same instinct applies to GitHub's other recent default changes — the platform has been shifting toward safer-by-default behaviour in workflow triggers and runner images, and in both cases the teams that came out fine were the ones holding an explicit inventory rather than an implicit one.

Models are governed on a separate track

Model availability runs through the same policy but with its own marker: new and unconfigured GA models carry a Delegate to Default Policy label, and the default policy decides them. This matters more than the feature list for anyone with a data-residency or vendor-approval requirement, because a new model provider appearing in the picker is a procurement fact, not a UI change. If your organization maintains an approved-vendor list for anything that receives source code, the model track is the one to configure explicitly and the one to re-check quarterly.

What GitHub does not say

Neither the changelog nor the concept page states the initial value the policy ships with. The announcement is titled “Default Enablement” and the documentation frames Disabled as the way to “prevent default enablement entirely”, which strongly implies unconfigured means enabled on 22 October. It is implied, not written. Do not build an audit narrative on the inference — open the settings page, read the value it currently shows, and set it deliberately. That takes a minute and removes the ambiguity permanently.

This is the same reference-lag pattern that keeps catching people this year: the changelog moves first, the reference docs fill in later, and the gap is where the wrong assumption lives.

The checklist worth running before 22 October

Four things, in order. First, open Features & clients at enterprise scope and list every row showing Unconfigured — that list is your entire exposure, and it is probably longer than you expect. Second, configure the three named high-impact rows explicitly: Copilot code review, MCP servers, and the model policy. Third, pick a value for the global default and write down why, because someone will ask in six months. Fourth, if you choose Let organizations decide, name the owner in each organization now rather than discovering the gap after a feature has been live for a fortnight.

GitHub also shipped an in-product validator for enterprise managed settings in the same changelog week, which checks JSON configurations and team mappings. If you manage Copilot policy as committed JSON rather than through the UI, run it — and validate the file locally first with a JSON formatter so you are debugging policy logic rather than a trailing comma.

None of this is an argument against turning Copilot features on. Most of them are fine and several are good. It is an argument for the difference between a default you accepted and a default you chose, which is the only difference that survives a security review. If you are still mapping the wider landscape of assistants and agent tooling, our AI tools and platforms directory and the broader developer tools category are the faster way to compare what else is in this space.

FAQ

When does GitHub's Copilot default availability policy take effect?

22 October 2026, announced on 24 September 2026. That date is when the policy starts applying to existing generally available features that are still marked Unconfigured. New GA features and features graduating from preview to GA are governed by the same policy going forward.

Will it override settings we already configured?

No. GitHub states that explicit decisions are preserved and that a feature you have explicitly enabled or disabled will not be overridden. The policy governs only the unconfigured set, which is why the audit is a filter on that label rather than a full review.

Does this affect preview features?

No. Preview features remain opt-in and are excluded from the policy. If a preview feature you had configured graduates to general availability, it keeps the configuration you gave it rather than falling back to the default.

What does “Let organizations decide” actually change?

It moves the unconfigured problem to organization scope. At that level the policy applies to features the enterprise owner set to Let organizations decide but the organization owner has not explicitly configured, so every organization needs a named owner and its own decision.

How are Copilot models handled?

New and unconfigured GA models carry a Delegate to Default Policy label and follow the same default. Treat that as a procurement surface rather than a UI setting: a newly available model is a new recipient of your source code.

---

A default you accepted and a default you chose look identical in the UI and nothing alike in an audit.