GitHub Copilot Default Enablement (October 22): Admin Checklist Before Unconfigured Features Turn On

Introduction

Update (2026-10-23). GitHub’s follow-up changelog entry, published October 22, 2026, confirms the default policy went live as announced, with two refinements. First, enforcement is a gradual rollout through October 26, 2026, not a single-day cutover — different enterprises and organizations may see it take effect on different days within that window. Second, the rollout is a one-time change: once an eligible Unconfigured feature is set according to the default, later changes to the global default policy will not retroactively change feature policies that are already set — you can still adjust each feature explicitly at any time. Everything else in this checklist is unchanged: Business/Enterprise scope, explicit choices preserved, preview features opt-in, and the MCP servers and code review policies still covered per GitHub’s documentation.

If you administer GitHub Copilot for a company, October 22, 2026 is a date that changes the meaning of doing nothing. On September 24, GitHub added a global “Default policy for new features” to Copilot Business and Enterprise settings, with a 28-day window to configure it before it takes effect. When the window closes, every eligible generally available feature still marked Unconfigured starts following that default, and the default itself ships set to Enabled. This tutorial is the admin checklist for the days before the cutover: what flips, what does not, and the exact settings to review.

Quick answer

On October 22, 2026, GitHub’s “Default policy for new features” started rolling out — enforcement is gradual through October 26, so your enterprise or organization may see it take effect any day within that window. Any generally available Copilot feature marked Unconfigured in Business or Enterprise settings will be set according to the global default (enabled unless you changed it). Review the AI Controls page and set each policy explicitly if you have not already.

Evidence

The claims below come from GitHub’s own changelog and Copilot enterprise documentation, plus Microsoft’s disclosed adoption figures.

The rollout, as it happened. GitHub’s follow-up changelog entry on October 22, 2026 confirms enforcement began that day and rolls out gradually through October 26, so timing varies by enterprise and organization. It also clarifies the rollout is a one-time change: once an Unconfigured eligible feature is set according to the global default, subsequent changes to the default policy won’t change that feature’s setting.

The announcement. GitHub published the change in its official changelog on September 24, 2026: a new global default policy for generally available Copilot features and supported client capabilities in enterprise and organization settings. For 28 days it can be configured without affecting users; starting October 22 it applies to new and existing GA features left Unconfigured.

The default is on. GitHub’s default availability documentation states the policy plainly: “This policy is enabled by default. If you don’t take action, unconfigured features will be enabled on October 22.” The same page adds that a banner in policy settings shows how many eligible policies are currently unconfigured, so admins can assess the impact before the date.

Explicit choices survive. The changelog’s most quoted safeguard: “If you’ve explicitly enabled or disabled a feature, we won’t override that choice.” Preview features remain opt-in, and an existing preview opt-in is preserved if that feature later becomes generally available.

Why this matters at scale. Copilot’s reach makes a silent default flip significant. Microsoft reported 50 million Copilot users on its fiscal Q4 2026 earnings call in July 2026, with 4.7 million paid subscribers as of January 2026, up 75 percent year over year, and 90 percent of Fortune 100 companies using Copilot. As of October 2026, a large share of those seats sit on Business and Enterprise plans, exactly the plans this policy covers.

Precedent. GitHub ran the same playbook for models two months earlier: the “Default availability for released models” policy shipped in the changelog in late July 2026 and began enforcement on August 26, moving unconfigured models to a “Delegate to default policy” state. Features are next, and the mechanism is identical.

Prerequisites

• A GitHub Enterprise Cloud account with Copilot Business or Copilot Enterprise (the policy does not apply to Copilot Pro or other individual plans).
• An admin role: enterprise owner for enterprise-level policy, or organization owner for organization-level policy.
• Access to the enterprise “AI Controls” page (or the organization’s Copilot settings page).
• A list of your organizations if you run a multi-org enterprise, because the “Let organizations decide” option delegates the decision downward.

Step-by-step guide

Step 1: Confirm the policy applies to you

Open your enterprise or organization settings and check your Copilot plan. The Default policy for new features exists only under Copilot Business and Copilot Enterprise. If your developers are on individual Copilot Pro seats, nothing changes for them on October 22, and you can stop here.

Step 2: Open the default policy setting

For an enterprise, go to the “AI Controls” page, open the “Copilot” subpage, and find “Default policy for new features”. For an organization, open the organization’s Copilot policy settings. GitHub shows the setting with a banner indicating how many eligible policies are currently Unconfigured. That number is your blast radius: it counts every policy that will flip on October 22 if you leave the default at Enabled.

Step 3: Read the unconfigured banner before touching anything

Do not change the global default yet. First record the banner count and screenshot the current state of each policy page. You need a before picture, because after October 22 there is no built-in audit trail distinguishing “enabled by admin choice” from “enabled by default”.

Step 4: Inventory every Unconfigured policy

Walk three surfaces and mark each row as explicitly enabled, explicitly disabled, or Unconfigured:

1. Features and clients page. The bulk of eligible GA features live here. Every row still labeled Unconfigured follows the global default on October 22.
2. Agents page: Copilot code review policy. Covered by the change. Note that flipping this policy changes availability, not behavior: automatic review still requires a ruleset or the developer’s own setting.
3. MCP page: MCP servers in Copilot policy. Also covered. This is the highest reach policy on the list, because MCP servers let Copilot touch tools and data outside the repository.

Policies outside this list are exceptions and never flip: the data residency and FedRAMP model restrictions, and “Store local sessions in the Cloud” for Copilot CLI and VS Code.

Step 5: Choose the global default deliberately

The setting offers three options, and GitHub defines them exactly:

• Enabled. Current and future eligible features become available to users by default. Choose this if your organization wants new Copilot capabilities without an admin approval step for each one.
• Disabled. Current eligible features remain unavailable, and future ones require administrator approval. Choose this for regulated environments, or if you have no review process for new AI features yet and want every enablement to be a conscious decision.
• Let organizations decide. Each organization under the enterprise chooses for itself. Choose this for multi-org enterprises with genuinely different risk postures, and only if you will chase every organization owner to a decision before October 21.

Write down which one you chose and why. A one-line rationale in your change log prevents a future admin from “fixing” a deliberate Disabled back to Enabled.

Step 6: Explicitly set the high-blast-radius policies

Even if you keep the global default at Enabled, set these two explicitly so their state reflects a decision, not an accident:

• MCP servers in Copilot. Decide which servers developers may connect and document the boundary. If you already run Copilot with a managed model policy for JetBrains admins, apply the same discipline here: defaults are fine, but the security boundary must be explicit.
• Copilot code review. If your teams are not ready for AI-generated review comments on pull requests, disable it explicitly now. The Copilot code review API tutorial shows what the review surface looks like, which helps you judge whether your workflow is ready.

An explicit choice on these rows survives October 22 regardless of the global default.

Step 7: Close the delegation gap

If the enterprise policy is “Let organizations decide”, every organization owner must set each eligible feature explicitly, because an organization that never chooses is treated the same as Unconfigured. Send each org owner the inventory from Step 4 with a deadline of October 21. For organizations with stricter compliance needs, consider disabling the default policy for that organization entirely rather than relying on delegation.

Step 8: Verify through the rollout window (October 22–26)

October 21 was the last full day the policy was configurable without effect. GitHub is enforcing the rollout gradually through October 26, so if you have not finished the checklist, set every row you care about explicitly now — explicit decisions are never overridden, even mid-rollout. Re-open the three surfaces, confirm no row you care about is still Unconfigured, and re-check the banner count. Once the rollout has reached your enterprise or organization, spot-check that the policies you set explicitly still show your choice and that nothing unexpected flipped. If something did, the fix is the same as the prevention: set it explicitly now, since explicit decisions are never overridden. Keep in mind the rollout is a one-time change: after it reaches you, changing the global default will not retroactively alter feature policies that are already set, so any revert needs the explicit per-feature step.

Troubleshooting

A feature turned on October 22 even though I set the policy to Disabled

You probably set it at the organization level while the enterprise policy says something else. Enterprise policy wins over organization policy: an organization cannot override an enterprise enablement. Check the effective policy at the enterprise’s AI Controls page first, then reconcile the organization setting with it.

A preview feature I never touched is suddenly on

That should not happen through this change. Preview features remain opt-in and are excluded from the default policy. What does happen by design: if you opted into a preview feature and it later became generally available, your opt-in is preserved, which can look like a surprise enablement. Check the feature’s history before assuming the default policy caused it.

The banner’s unconfigured count does not match my manual count

The banner counts only eligible policies. Exceptions are excluded: the data residency and FedRAMP model restrictions and the “Store local sessions in the Cloud” setting never appear in that count. If your manual inventory included those rows, that explains the gap.

We chose “Let organizations decide” and some orgs never configured anything

Those organizations’ eligible features flip on October 22 exactly like Unconfigured enterprise features. Delegation is not a safe harbor for inaction. Either get explicit decisions from every organization owner before October 21, or set the policies explicitly at the enterprise level for the orgs that did not respond.

I want the old behavior back after October 22

Set the Default policy for new features to Disabled, then explicitly disable any feature that flipped on and should stay off. Because the rollout is a one-time change, the second step is the one that does the work: after the rollout has applied to your account, changing the global default alone will not revert feature policies it already set — there is no bulk “revert to pre-October 22 state” button, which is why the Step 3 screenshot matters. Going forward, treat every new GA feature announcement on GitHub’s changelog as a prompt to make an explicit choice.

FAQ

When does GitHub Copilot default enablement take effect?

October 22, 2026. GitHub announced it on September 24 with a 28-day configuration window, and its October 22 follow-up changelog confirms enforcement rolls out gradually through October 26 — your enterprise or organization may see it take effect any day within that window.

Which Copilot plans are affected?

Copilot Business and Copilot Enterprise. Individual plans like Copilot Pro are not covered by the Default policy for new features.

Will it override settings I already configured?

No. GitHub’s changelog is explicit: “If you’ve explicitly enabled or disabled a feature, we won’t override that choice.” Only features still marked Unconfigured are affected.

Are preview features included?

No. Preview features stay opt-in. If you opted into a preview that later became generally available, your existing choice is preserved.

Is the MCP servers policy covered?

Yes. The MCP servers in Copilot policy is covered, along with eligible features on the Features and clients page and the Copilot code review policy. Because MCP servers reach outside your code, set this one explicitly rather than leaving it to the default.

Does this change which AI models my developers can use?

Not this policy. Models are governed separately by the “Default availability for released models” policy, active since August 2026. That is also why some teams pair this checklist with a review of their local model setup for Copilot in the same maintenance window.

Conclusion

The October 22–26 rollout rewards admins who already made explicit decisions and punishes nobody who did, except through inaction. The checklist is short: confirm the plan scope, read the unconfigured banner, inventory the three covered surfaces, pick the global default on purpose, set MCP servers and code review explicitly, close the delegation gap, and verify while the rollout is reaching your account. If your window has passed, the one-time-change rule makes the lesson retroactive in only one direction: explicit settings made before or during the rollout stand, and anything left Unconfigured now carries whatever the default said.

Next, if your shop also runs JetBrains IDEs, read the Copilot admin guide for JetBrains to align the model policy with the feature policy you just set.

Frequently asked questions