GitHub's new default enablement policy decides what happens to every Copilot feature an admin hasn't explicitly turned on or off. Starting October 22, 2026, anything still marked Unconfigured in an enterprise's or organization's Copilot settings follows whichever default the admin picked, or GitHub's own default of Enabled if nobody picked anything at all. That's a separate setting from GitHub's other Copilot changes this quarter, including the code review effort-level change coming no earlier than September 28. This one decides whether a feature reaches users in the first place.
What GitHub's new default enablement policy actually does
GitHub announced the mechanism in GitHub's changelog announcing the policy on September 24, 2026, describing it as a new global default policy for generally available Copilot features and supported client capabilities. In practice it's a single enterprise or organization-wide setting called "Default policy for new features," sitting inside the Copilot admin console, that governs any eligible Copilot feature nobody has explicitly turned on or off.
The setting is live to configure now, ahead of taking effect later. "For the next 28 days, you can configure this policy, but it won't affect feature access for your users yet," GitHub's changelog states. Starting October 22, the policy takes effect, and whatever an admin chose, or didn't choose, becomes the actual behavior for every unconfigured feature.
The three settings: Enabled, Disabled, Let organizations decide
The setting offers three options at the enterprise level. Enabled means, in GitHub's wording, current and future eligible features "will be available to users by default." Disabled flips that around: current eligible features stay unavailable, and any future eligible feature will "require administrator approval" before it reaches users. The middle option, Let organizations decide, pushes the call down a level: organization administrators get to choose whether to enable or disable eligible features themselves.
Picking Let organizations decide at the enterprise level doesn't finish the decision. It hands the same three-way choice to whoever owns each org, and that choice still needs to happen before October 22 or the org inherits whatever the enterprise-level default resolves to.
Which Copilot policies are in scope
The policy applies to two places: everything configured on an enterprise's Features & clients page, plus two named policies that live elsewhere, the Copilot Code Review policy on the Agents page and the MCP servers in Copilot policy on the MCP page, according to GitHub's docs on default availability. If your org runs Copilot code review or lets Copilot call MCP servers, both now sit under this same governing default. How to configure Copilot code review covers the gating step that already applies today: nobody in an org gets code review until an admin flips it on somewhere in the Copilot policy settings. The new default policy is what decides that flip automatically for anyone who leaves it unconfigured past October 21.
The same page carves out two exceptions that don't move no matter what an admin picks: the data-residency and FedRAMP model restriction policies on GHE.com, and the "Store local sessions in the Cloud" setting for Copilot CLI and VS Code. Both stay exactly where they are today regardless of the global default.
MCP servers in Copilot decides whether Copilot can call external tools at all. That's a different question from what a connected tool is allowed to do once it's live, which is the ground GitLab's opposite default for tool permissions covers on the GitLab Duo side: read-only tools default to always allow there, and write or delete actions default to always ask. GitHub's default enablement policy is upstream of that question entirely, and so is a related setting in the same admin console: once Copilot agents are enabled, GitHub's deny, ask, allow permissions for Copilot agents decide what those agents can actually do with shell commands, file edits, and network calls.
The 28-day window and what happens on October 22
Two categories are untouched regardless of what an admin decides globally. Explicit decisions are preserved: if a feature has already been explicitly enabled or disabled, GitHub won't override that choice on October 22. Preview opt-ins are preserved too, including if a preview later graduates to general availability. What actually moves on October 22 is narrower than "everything": only features and capabilities still sitting at Unconfigured that day inherit the new default.
How to decide before October 21
1. Open AI Controls, then Copilot, and check the Unconfigured banner
Configure the policy by going to the AI Controls page, opening the Copilot subpage, and selecting an option under Default policy for new features, per the changelog's setup instructions. GitHub surfaces a banner there showing how many policies currently sit at Unconfigured, which is the fastest way to see how much of your Copilot footprint would actually move on October 22 if you did nothing.
2. Set the enterprise-wide default
Enabled, Disabled, or Let organizations decide, and each fits a different risk posture. An enterprise that trusts most orgs to run new Copilot capability on their own timeline can pick Enabled and manage exceptions individually. One that wants every new capability reviewed before rollout should pick Disabled and accept that admin approval becomes a standing task. Let organizations decide only makes sense if org owners genuinely have the context and the bandwidth to make their own calls, because it doesn't remove the decision, it relocates it.
3. Explicitly configure any feature that should diverge from the default
Anything explicitly set now stays put after October 22, whatever the global default resolves to later. If Code Review should stay off company-wide even though the broader default is Enabled, set that feature's policy explicitly before the window closes rather than relying on a future override. To disable default enablement entirely, GitHub's documentation notes that admins can disable the default policies in that enterprise's or organization's own settings.
4. Repeat at the organization level for anything set to "Let organizations decide"
An enterprise-level choice of Let organizations decide isn't the end of the work. Each affected org owner still needs to make an explicit call for anything that hasn't already been configured, because org-level Unconfigured features inherit the same fallback logic the enterprise-level ones do. Leaving that step to org owners without telling them the window exists is how a deliberate enterprise decision turns into an accidental org-level Enabled default.
Don't confuse this with the default model availability policy
This policy governs Copilot features: the Features & clients page, Copilot Code Review, and MCP servers. AI models sit under a separate policy that GitHub's documentation says is already active, ahead of this one's October 22 start date. The docs page's description of the models policy names it "Default availability for released models," and it already affects new and unconfigured GA models today. If your team has never touched a model-level setting and assumed this new features policy covers it, it doesn't. They're two separate policies with two separate timelines, and the models one has been running for longer.
FAQ
What happens to unconfigured GitHub Copilot features on October 22, 2026?
Any eligible feature still marked Unconfigured follows whatever default an enterprise or org admin selected under "Default policy for new features." If nobody selects anything, GitHub's default of Enabled applies automatically, which means the feature becomes available to users on that date without anyone having made an active choice.
What are the three GitHub Copilot default enablement settings?
Enabled makes current and future eligible features available to users by default. Disabled keeps current features unavailable and requires administrator approval before any future eligible feature turns on. Let organizations decide hands that same choice to each organization's own administrators rather than fixing it at the enterprise level.
Which Copilot policies does the default enablement policy cover?
Everything configured on an enterprise's Features & clients page, plus the Copilot Code Review policy and the MCP servers in Copilot policy specifically. Two settings sit outside its reach regardless of the chosen default: the data-residency and FedRAMP model restriction policies on GHE.com, and the "Store local sessions in the Cloud" setting for Copilot CLI and VS Code.
Is this the same as GitHub Copilot's default model availability policy?
No. The default enablement policy covers features and capabilities and takes effect October 22, 2026. GitHub's documentation describes a separate "Default availability for released models" policy that governs AI models specifically and is already active, running under its own rules before this one takes effect.