GitHub Copilot Features Turn On by Default Oct 22: Check Now

GitHub announced on September 24, 2026 a new global policy for Copilot Business and Copilot Enterprise: a default that decides what happens to every eligible generally available Copilot feature an administrator has not explicitly configured. The policy can be set today and takes effect on October 22. GitHub's documentation is plain about the default: it is enabled, and if you take no action, unconfigured features switch on that day.

The set is wider than autocomplete. It covers every policy on the enterprise "Features & clients" page, plus the Copilot code review policy and the "MCP servers in Copilot" policy. That last one decides whether Copilot clients across your company can run Model Context Protocol servers at all, which is the door through which an agent reaches your tools and data. Twenty-eight days is enough time to decide it deliberately. This post is the checklist.

The changelog entry describes a "Default policy for new features" under the AI Controls page's Copilot subpage. For 28 days it can be configured without affecting anyone's access. From October 22 it applies. The mechanics, each from the changelog or the default-availability documentation, are below.

The documentation states the reason for the change without saying much about risk: with the default policies on, "users benefit from the latest features and models without the need for administrator intervention". That is true, and it is also why an unconfigured MCP policy is the item to look at first.

We have argued before that agent tooling should ship default-off and be turned on by a named person. Our post on the default-off change for AI review bots made that case for one GitHub setting; our census of coding-agent permission defaults shows how few vendors ship that way. This policy runs the other direction, which is why the deadline matters.

GitHub's MCP management documentation says the policy "defines whether MCP servers can run at all across Copilot clients", and recommends keeping it enabled while restricting the servers users can run to an approved list. That is the right shape. An MCP server is code that Copilot can call with your developers' credentials; an unrestricted policy means any server a developer adds to a client configuration runs. The incidents we track in our MCP security incident ledger are mostly servers that did more than their name suggested.

The question is therefore not enabled or disabled, but which allowlist mechanism. GitHub documents two, and is candid about the difference.

The practical reading: if you can publish a managed-settings file before October 22, set the MCP policy to Enabled and let the file enforce the list. If you cannot, set the MCP policy to Disabled explicitly, so the October 22 default does not decide it for you, and revisit when the file is ready. Copilot code review is the second item worth an explicit answer, because it decides whether an agent comments on pull requests across every repository the policy covers.

Four weeks, one owner per week. The dates run from the September 24 announcement to the October 22 effective date.

Three policies are excluded by name: the two restrictive model policies on GitHub's data-residency enterprise offering that limit Copilot to data-residency or FedRAMP models, and "Store local sessions in the Cloud" for Copilot CLI and VS Code. Preview features are outside the policy entirely.

A separate default-availability policy for models is already active. Models you have not configured carry a "Delegate to Default Policy" label and inherit the default when released. Four classes are disabled by default whatever that policy says: pre-GA models; open-weight models, which the docs list as DeepSeek, Kimi K2.7 Code and Kimi K3; models not covered by GitHub's data retention agreement, listed as Claude Fable 5 and Claude Fable 5.1; and, for restricted enterprises, any model that does not meet the data-residency or FedRAMP restriction.

Nothing in the announcement concerns individual Copilot plans; it is scoped to Business and Enterprise. The changelog says the policy lives in both enterprise and organisation Copilot settings, so an organisation without an enterprise account should check whether it has the same decision to make. Our AI transformation practice runs this inventory as part of agent governance reviews.

The policy’s mechanics are simple and the ways to be surprised by it follow from them. The illustrative enterprises below each find out on October 22 what they did not decide. They are patterns drawn from GitHub’s documentation, not customers.

The unread banner: nobody opens the Features & clients page before October 22, the unconfigured count is never read, and every eligible feature on it switches on, as the documentation says it will. The team learns the list from developers rather than from the page. The accidental delegation: the enterprise picks Let organizations decide to avoid choosing, and the same question moves one level down to organisation owners who were not told it was coming. The documentation’s second rule applies, and any organisation whose owner does not act inherits the enabled default. The MCP policy left to inherit: the policy that GitHub says “defines whether MCP servers can run at all across Copilot clients” is left unconfigured because the allowlist file was not ready. On October 22 the default enables it with no allowlist, so any server a developer adds to a client configuration runs. The explicit Disabled setting was the available fallback. The model confusion: a team reads about the default-availability policy for models, sees that open-weight and pre-GA models are disabled regardless, and assumes the feature policy has similar guard rails. It does not; the four model classes disabled by default belong to the separate models policy, and the feature set includes the agent doors.

Each case ends the same way: a decision GitHub gave four weeks to make was made by the default, and the checklist above exists so that the decision is made by a named person instead.

The checklist’s first week asks for an export of every feature and its state, and that export is the record the rest of the decision rests on. For the Features & clients page, the Agents page and the MCP page: each policy, its current state as Enabled, Disabled, Unconfigured or Let organizations decide, and the date read. Beside it, the banner count of unconfigured policies, so the record shows how many decisions the default would otherwise make. For the MCP policy, the chosen allowlist mechanism, managed-settings file or custom registry, with GitHub’s comparison of the two noted, and the date the file will be published. For Copilot code review, the per-organisation decision and who made it.

Then the global default itself: which of the three settings was chosen, by whom, on what date, and, if Let organizations decide, the list of organisation owners who were told and when. Finally the exclusions, so nobody expects the policy to cover them: the two restrictive model policies on the data-residency offering, Store local sessions in the Cloud, and all preview features; plus a note that the model default-availability policy is already active and separate, with its four always-disabled classes.

The record is also what the security-channel sentence in the checklist section summarises. When October 22 arrives, it shows that every feature that switched on did so because someone chose Enabled, and every one that stayed off did so because someone chose Disabled, which is the whole point of the four weeks.

Read the unconfigured count this week and write it at the top of the record. Everything else in the checklist is a way of turning that number into decisions with names on them before October 22 turns it into defaults.