Your GitHub Copilot Settings Change Meaning on October 22. Unconfigured Will Mean On.

On 24 September 2026 GitHub added a global default policy for generally available Copilot features on the Business and Enterprise plans. For 28 days it can be set but changes nothing. From 22 October 2026 every eligible feature still marked Unconfigured in your GitHub Copilot settings follows it. The changelog lists the three choices (Enabled, Disabled, Let organizations decide) and never says which one you get if you do nothing.

The docs page it links to does. The policy is enabled by default, and if you take no action, unconfigured features are enabled on 22 October.

What Unconfigured used to mean in your GitHub Copilot settings

In November 2025 GitHub fixed a bug in how enterprise and organization policies interact. The corrected rule: when an enterprise policy is Unconfigured, the matching organization policy defaults to Disabled, so that policies stay restricted until an enterprise admin explicitly enables or delegates them. Leaving a row alone was a decision to keep it off.

The 22 October change reverses that for every eligible feature. At the enterprise level the default policy applies to anything labelled Unconfigured. At the organization level it applies to features the enterprise delegated with Let organizations decide that the organization owner never set. An untouched row stops meaning off and starts meaning whatever the default says, and the default says on.

This is the second time in two months. The same mechanism shipped for models on 29 July, began enforcement on 26 August with a gradual rollout through 1 September, per GitHub's changelog and Tech Times' coverage of it. Models that no admin had configured were moved to a Delegate to default policy state and switched on. Features are next.

What is in scope

The docs define a feature as any policy on the enterprise Features & clients page, plus two more: the Copilot code review policy on the Agents page, and the MCP servers in Copilot policy on the MCP page. Two things are excluded: the data-residency and FedRAMP model restrictions on GHE.com, and the setting that stores local Copilot CLI and VS Code sessions in the cloud. Preview features stay opt-in.

MCP is the one to read twice. The GitHub MCP server's governance document says that disabling this policy blocks GitHub MCP server access from the Copilot editors it governs, remote and local, whichever authentication method is used. It names VS Code and the Copilot coding agent as the editors covered today. Leave that row Unconfigured with the default at Enabled, and on 22 October the agent in those editors can reach your GitHub data through MCP with nobody having approved it.

The multi-organization case

GitHub's policy-conflict reference resolves most Copilot features, MCP servers in Copilot and Copilot code review among them, by the least restrictive organization. If any organization that grants a user a license enables the feature, the user has it everywhere.

Combine that with the new default. In an enterprise that set MCP servers in Copilot to Let organizations decide, a user licensed through two organizations, one of which explicitly disabled MCP servers in Copilot and one which never touched it, gets MCP on 22 October. The careful organization's decision is overruled by the other one's silence. We read that from two documented rules rather than from a statement by GitHub. The falsifier is simple: if a user in that position still has MCP blocked after 22 October, the conflict rule is not being applied to defaulted values, and this section is wrong.

What to decide this quarter

The decision is not whether to turn the new policy off. It is whether Unconfigured is allowed to exist in your tenant at all. GitHub's docs frame default-on as a benefit: users get the latest features without an administrator stepping in. If your AI rollout has an approval step anywhere — a security review of new agent capabilities, a data-access sign-off, a pilot group — that framing is the case for setting Disabled, because an approval step that new features skip is not an approval step. As we argued in why enterprise AI doesn't ship, the model is rarely the problem; integrations reaching real systems without the right auth and audit trail are. An MCP connection nobody approved is exactly that kind of integration.

The same pattern appeared when enterprise MCP allowlists went generally available: the client list is the policy, and a control only governs the surfaces it names.

The advice is wrong for one kind of tenant: an enterprise that already reviews every Copilot changelog entry and configures each feature explicitly within days. For that team the default rarely has anything left to apply to, and which way it points matters little.

The checklist, before 22 October

1. As an enterprise owner, open AI controls, then Copilot, where the Default policy for new features setting lives, and find the banner that GitHub's docs say shows how many eligible policies are currently Unconfigured. Write the number down.
2. Set MCP servers in Copilot (MCP page) and Copilot code review (Agents page) explicitly. Either choice is fine; Unconfigured is not.
3. Choose the enterprise default. If any feature needs sign-off before users get it, pick Disabled; new GA features will then wait for administrator approval.
4. For every policy set to Let organizations decide, check that each organization's owner has made the call, since the least restrictive organization decides for a user licensed through several.
5. Check the model default too. It has been live since the late-August rollout, and a model nobody configured may already be on.
6. After 22 October, reopen the page. The banner count should be zero, and the enterprise audit log, which the docs recommend for tracking policy changes, should show every change as one a named admin made.