GitHub has begun enforcing a global default policy for Copilot features, GitHub said in its changelog on October 22, so generally available features that administrators never explicitly enabled or disabled will now follow the organisation’s chosen default instead of staying untouched. The rollout reaches Copilot Business and Enterprise customers gradually through October 26, with timing varying by enterprise and organisation. Features already set to enabled or disabled keep their settings, and preview features stay opt-in, but anything still marked Unconfigured on the Features and clients page, plus Copilot code review and MCP servers in Copilot, will be set by the default. The change is one-time: later edits to the default will not rewrite features that are already set.
What the default policy changes
GitHub announced the policy in September and moved it to general availability on October 22. From that date, enforcement rolls out in stages, so the change may land on different days for different enterprises and organisations before the October 26 end of the rollout window. The setting lives under AI Controls, then Copilot, then Default policy for new features.
Administrators choose one of three defaults: Enabled, Disabled, or Let organizations decide. Once the policy takes effect, every eligible generally available feature left Unconfigured is set according to that choice. GitHub describes the conversion as a one-time change. Changing the default afterwards does not rewrite features already set, and administrators can still make explicit choices for individual features at any time.
The distinction that matters is between a feature never configured and one explicitly set. An explicit choice is preserved in full; only untouched rows move, which is why administrators should review the settings page before the rollout reaches them.
Which settings it covers, and which it does not
According to GitHub’s documentation, the policy applies to eligible settings on the Features and clients page, plus two named additions: the Copilot code review policy on the Agents page, which governs whether Copilot can review pull requests, and the MCP servers in Copilot policy on the MCP page, which governs whether Copilot can reach outside tools and data through Model Context Protocol servers.
At the enterprise level, the policy applies to features labelled Unconfigured. At the organisation level, it applies to features that an enterprise owner set to Let organizations decide but that an organisation owner has not explicitly configured. In both cases, preview features are excluded: they remain opt-in, and if an administrator opted into a preview that later becomes generally available, that choice is preserved.
Two kinds of policy are explicitly out of scope. Restrictive model policies on GitHub’s cloud platform, namely Restrict Copilot to data residency models and Restrict Copilot to FedRAMP models, are not affected. The Store local sessions in the Cloud setting for Copilot CLI and Visual Studio Code is also untouched. GitHub runs a separate default policy for released models, a different control from the features policy.
What admins should check before October 26
The practical step is a review of the Features and clients page, the Agents page and the MCP page before the rollout reaches the organisation. Any row still marked Unconfigured is a row the default will decide. Administrators who want a feature off should set it to disabled explicitly, and those who want it on should set it to enabled, rather than leaving the decision to the global default.
The MCP servers policy deserves particular attention. It controls whether Copilot can connect to outside servers, which can reach tools and data beyond the codebase. An organisation that has never set that policy should decide deliberately whether that access is acceptable, because the default will decide it otherwise. The same applies to Copilot code review: a team that has not chosen whether Copilot reviews pull requests will find the question answered for it.
Administrators should also note the timing. Because the rollout is gradual, an organisation may not see the change on October 22 itself. Checking the settings page now, rather than waiting for the change to appear, is the only way to be sure the outcome matches the organisation’s intent.
Why It Matters
Unconfigured has stopped meaning untouched. Until this rollout, leaving a Copilot feature unconfigured was a safe way to defer a decision, and many organisations will have rows they never consciously chose. From October 22, those rows get an answer from the global default, and the answer is permanent for that feature unless an administrator changes it explicitly afterwards.
That shift matters most for governance. Copilot features now reach into code review and outside tool connections, so a default decision is a security decision, even when nobody made it deliberately. Organisations with compliance requirements should treat the settings review as a small audit: every Unconfigured row is a policy that was never written, and this rollout writes it.
Background
GitHub has been tightening and reorganising the administrator controls for its AI pair programmer through 2026, alongside a fast-moving programme of model changes. GitHub retired six Copilot models on October 19, and a further three models, including Claude Opus 4.8 and GPT-5.6 Terra, are due to retire on November 16. The default policy is part of the same administrative surface: as Copilot gains features and models change, GitHub is pushing organisations to state their choices explicitly rather than leaving them blank.
Source: GitHub Changelog, GitHub Docs
0 Comments