GitHub has started enforcing the GitHub Copilot default policy for new features on Copilot Business and Copilot Enterprise. Any eligible, generally available feature that an admin left Unconfigured gets set once from the global default. According to GitHub's announcement thread, if no one chose an option, those features will be enabled. The rollout runs from October 22 through October 26, so for some enterprises it may not have landed yet.
GitHub's global default policy for new GA Copilot features on Business and Enterprise plans, enforced Oct 22-26, 2026
Best for: GitHub-centric teams wanting deep issue, PR, and CI integration, Organizations needing IP indemnity and enterprise compliance controls
What GitHub changed on October 22
GitHub's October 22 changelog post announces a global default policy for "generally available GitHub Copilot features and supported client capabilities on Copilot Business and Copilot Enterprise plans." The post says GitHub is "gradually rolling out enforcement of the policy through October 26, so it may take effect at different times for different enterprises." An enterprise that looks unchanged today can still be switched before the window closes.
The mechanics are short. Eligible GA features and capabilities left Unconfigured are set according to the selected global default, which has three options: Enabled, Disabled, or Let organizations decide. GitHub calls this "a one-time change." The post adds that administrators can still make explicit choices for individual features at any time.
GA stands for general availability. GitHub's public roadmap describes the GA phase as "Generally available to all customers" and "Ready for production use with associated SLA and technical support obligations." For this policy, read a GA feature as one available to all relevant Copilot Business and Enterprise customers and not in preview; the docs exclude preview features, as covered below.
The change was announced in advance. GitHub pre-announced the policy on September 24 with a 28-day window: "For the next 28 days, you can configure this policy, but it won't affect feature access for your users yet." The same post set October 22 as the date the policy takes effect.
What happens if you never picked an option
This is the part that matters most, and neither changelog post states it. The October 22 post lists the three options but names no pre-selected value. The September 24 post describes the options and the October 22 effective date, also without a no-action outcome. The default availability documentation does not say which option is pre-selected either.
The answer comes from GitHub's community announcement thread, which the October 22 changelog links to: "If no action is taken, eligible unconfigured features will be enabled." Digital Applied's pre-enforcement admin checklist gives the same reading. If your enterprise never opened the setting during the 28-day window, plan on your unconfigured GA features turning on for users.
What the three options mean
The September 24 post and the docs describe the options in slightly different words. The docs also give the setting a longer name, "Default policy for new features and clients," and label two of the options "Enabled everywhere" and "Disabled everywhere."
| Option | September 24 changelog | Docs |
|---|---|---|
| Enabled | Current and future eligible features are available to users by default | Any unconfigured GA feature is automatically enabled for all your Copilot users, and organizations cannot disable it |
| Disabled | Current eligible features stay unavailable; future eligible features require administrator approval | Any unconfigured GA feature is automatically disabled for all your Copilot users, and organizations cannot enable it |
| Let organizations decide | Organization administrators choose whether to enable or disable eligible features | The decision is delegated. An unconfigured feature is set to Let organizations decide if its policy supports that option; otherwise, it is disabled. Where delegated, an organization-level default policy for new features determines availability |
The rollout itself is one-time, but the setting keeps mattering afterward. The docs say the policy covers new GA features as well as existing GA features that are Unconfigured, and the September 24 descriptions of Enabled and Disabled both address future features. Your choice decides what happens the next time GitHub ships an eligible GA feature, not only this week.
Which settings it covers
The October 22 post says the policy applies to eligible settings on "Features & clients" and "MCP servers in Copilot." It does not mention Copilot code review, and it points to the docs for eligibility and exceptions. The docs answer directly: for this policy, a feature is any policy configured on an enterprise's "Features & clients" page, plus the Copilot code review policy on the Agents page and the MCP servers in Copilot policy on the MCP page. The September 24 post also named code review, so all three are in scope:
- Features & clients: any policy configured on that enterprise page, per GitHub's docs.
- MCP servers in Copilot: the policy on the MCP page. If you gate MCP access deliberately, this is the line to check first. For background on controlling what agents can reach, see the agent permissions playbook and the OWASP Top 10 for agentic apps.
- Copilot code review: the policy on the Agents page, per the September 24 post and the docs.
What it leaves alone
- Explicit choices. If you already enabled or disabled an individual feature, the rollout won't change that setting.
- Previews. Preview features remain opt-in, and the docs say the policy does not apply to features in preview. If you opted into a preview that later becomes GA, GitHub says that choice is preserved.
- Data residency and FedRAMP restrictions on GHE.com. The docs list the restrictive model policies on GHE.com, "Restrict Copilot to data residency models" and "Restrict Copilot to FedRAMP models," as exceptions.
- Cloud session storage. "Store local sessions in the Cloud for Copilot CLI and VS Code" is also listed as an exception.
- Models. The docs describe model availability under a separate policy, "Default availability for released models," which affects new and unconfigured GA models. Setting the features default is not a model decision.
Where to check and override the setting
GitHub's enterprise policy how-to page has no steps for this setting, so the path in the changelog is the reference:
- Go to AI Controls → Copilot → Default policy for new features and confirm which option is selected.
- If you chose Let organizations decide, check that each organization has set its organization-level default, since that decides availability under delegation. Also check for unconfigured features whose policy has no Let organizations decide option: the docs say those are disabled.
- For any feature you want fixed regardless of the default, set it explicitly. Explicit choices survive the rollout and can be changed at any time.
- To turn default enablement off entirely, the docs say to disable the default policies in your enterprise or organization settings.
- Watch GitHub's changelog. The docs say new features and models are announced there, which is where the next feature covered by your default will show up.
My recommendation
GitHub says enforcement may reach different enterprises at different times through October 26, so I recommend opening the default policy now rather than finding out from users. If you want new GA Copilot capabilities to arrive automatically, Enabled does that. If you have review or compliance requirements, choose Disabled or delegate deliberately, then set the MCP servers and Copilot code review policies explicitly; in my view those are the two surfaces where an unplanned change deserves the closest look. Model availability remains a separate decision, and the GHE.com data residency and FedRAMP model restrictions and the cloud session storage setting are outside this policy. For more on the product, see the GitHub Copilot tool page.
