GitHub Copilot Default Enablement: Features Turn On October 22 Unless You Choose

GitHub’s Copilot default enablement policy starts applying on October 22, 2026, and it ships set to Enabled. On Copilot Business and Copilot Enterprise, any generally available feature an admin has not configured switches on that day. GitHub announced the change on September 24 and gave admins 28 days to choose. October 21 is the last full day to decide.

This piece covers what Copilot default enablement touches, where the setting lives and what happens if nobody acts. It also covers the separate model policy that has been live since August. It ends with a short checklist for agencies that run Copilot on client code.

The short version: open AI controls and find Default policy for new features. Pick Enabled, Disabled or Let organizations decide on purpose. Then set Copilot code review and MCP servers in Copilot explicitly, because both are named in scope. Finally, check the model policy. It already turned on Grok 4.7 and Claude Sonnet 5.5 for organizations that never changed it.

What GitHub announced on September 24

The GitHub changelog entry introduces a global default policy for generally available Copilot features and supported client capabilities. It applies to Copilot Business and Copilot Enterprise. Enterprise and organization administrators got a 28-day window to configure it before it takes effect on October 22.

The policy has three settings:

• Enabled: current and future eligible features are available to users by default.
• Disabled: current eligible features stay unavailable, and future features need an administrator to approve them.
• Let organizations decide: organization owners choose for their own organization.

From October 22, eligible features that are still unconfigured follow whichever global default is selected. Decisions an admin already made explicitly are kept. Preview features stay opt-in. If a preview feature later becomes generally available, any existing choice about it carries over.

What happens if an admin does nothing

This is the part most teams will miss. GitHub’s default availability documentation says the policy "is enabled by default." It adds: "If you don’t take action, unconfigured features will be enabled on October 22."

So under Copilot default enablement, silence equals Enabled. Nothing already switched off by hand gets switched on. But anything still unconfigured moves to on. Every future generally available feature will arrive on as well.

Before October 22, GitHub shows a banner in the policy settings. It shows "how many eligible policies are currently unconfigured," per the docs. That count is the fastest way to see how much would change.

Which features Copilot default enablement covers

GitHub names three places the policy reaches:

• The Features & clients page: the generally available features and client capabilities listed there.
• The Copilot code review policy: on the Agents page.
• The MCP servers in Copilot policy: on the MCP page.

Neither the changelog nor the docs list every item on the Features & clients page. The banner count is the practical inventory. GitHub’s Copilot CLI admin guide puts the CLI policy in the Clients section of that page. So the CLI is one example worth checking.

The docs also list what Copilot default enablement does not touch. Preview features are excluded. So are the two restrictive model policies, "Restrict Copilot to data residency models" and "Restrict Copilot to FedRAMP models." The "Store local sessions in the Cloud" setting for Copilot CLI and VS Code is excluded too.

The two named policies deserve a direct decision

Copilot code review and MCP servers in Copilot are the two policies GitHub calls out by name. Both carry consequences beyond a new button in the editor.

Copilot code review. Per GitHub’s code review documentation, each review consumes AI credits. It also uses GitHub Actions minutes for its agentic work. By default Copilot reviews only when someone assigns it. Users, repository owners and organization owners can turn on automatic reviews, though. For an agency that bills clients for AI usage, that is a cost to decide on in advance.

MCP servers in Copilot. This policy governs whether Copilot users can connect MCP servers. Those let the assistant call outside tools and data sources. GitHub’s MCP setup page describes the policy as disabled by default. It is also named in scope for Copilot default enablement. As we read the two pages, an MCP policy still unconfigured on October 22 would move to Enabled. Admins can also restrict MCP to an approved registry, with a "Registry only" option.

Tool connections and plugins are where recent coding-agent problems have come from. Our Plugin4Shell coverage shows how a plugin source can swap code under a pin that still looks honored.

Where the Copilot default enablement setting lives

For an enterprise, click AI controls at the top of the enterprise page. Then choose Copilot in the sidebar. The changelog names the option Default policy for new features on that Copilot page. Feature settings sit under Configure features & clients. Copilot code review sits with the agent policies. MCP servers in Copilot has its own MCP page in the same sidebar.

For an organization, open the organization’s Settings. Under "Code, planning, and automation," click Copilot, then Policies. Models have a separate Models tab.

Enterprise and organization settings stack. At the enterprise level, Copilot default enablement applies to features labeled Unconfigured. At the organization level, it applies to features set to Let organizations decide that the organization owner has not configured. An organization cannot override a specific choice the enterprise has made, per the docs.

GitHub’s pages do not spell out how a standalone Copilot Business organization sees this setting. That is an organization with no parent enterprise. The changelog addresses "enterprise and organization administrators." If you manage one, look for the banner on its Copilot policies page before October 21.

Models already default on since August 26

The feature policy is the new piece. Models have had their own default since summer. A July 29 changelog entry set a global default for generally available models on Business and Enterprise. It took effect on August 26.

The organization setting is called Default availability for released models. Models no one has configured show as "Delegate to Default Policy" and follow it. Like the new feature policy, it is on by default.

That is how new models reach developers without an admin click. September’s changelog entries for Grok 4.7, Claude Opus 5.5, GPT-6 Sol, GPT-6 Luna and Claude Sonnet 5.5 share one line, with small wording changes. The Grok 4.7 entry reads: "Under default model enablement, new models are automatically enabled unless an administrator has turned off the global default or explicitly disables this model."

The model default covers generally available models only. GitHub’s docs list what stays off regardless. That includes pre-GA models and open weight models (DeepSeek, Kimi K2.7 Code, Kimi K3). It also includes models outside GitHub’s data retention agreement (Claude Fable 5 and 5.1). Models that do not respect data residency or FedRAMP restrictions are excluded as well.

Grok 4.7 and third-party models on client code

Our Grok 4.7 coverage noted that the model is on by default in GitHub Copilot for most organizations. The September 21 changelog lists it for Copilot Pro, Pro+, Max, Business and Enterprise, with a gradual rollout.

On data, GitHub’s model hosting reference says xAI models run under a zero data retention API policy. Per that page, prompts are not logged, stored, seen by xAI staff or used for training. The page also sets out retention and training terms for OpenAI, Anthropic and Google models. It notes limited exceptions for Anthropic’s Fable models.

Zero retention settles one question, not all of them. Some client contracts, procurement rules or data policies name which AI vendors may process their code. A government or higher education client may keep an approved vendor list. If that list leaves out xAI, a model that appeared by default breaks it, whatever the retention terms say. The fix is simple. Set the model to Disabled for that client’s organization. Or turn off the model default and approve models one at a time.

A second model date lands before the feature deadline. GitHub plans to retire six models on October 19, including GPT-5.5 and Grok 4.5. The replacement models are enabled automatically under the same default unless an admin turned it off.

Copilot default enablement checklist for agencies with client repos

Agencies often administer Copilot in several places. There is their own organization, client organizations they manage and enterprise accounts they sit inside. Each one gets its own Copilot default enablement change on October 22. Work through these before October 21.

1. List every enterprise and organization you administer. Note who owns the Copilot bill for each, and whether the client or your agency sets policy.
2. Read the banner count. The number of unconfigured eligible policies tells you how much changes on October 22.
3. Pick the global default on purpose. Enabled suits a team that wants new features fast. Disabled means every future feature waits for an approval. Let organizations decide pushes the choice to each client organization.
4. Set Copilot code review explicitly. Decide who pays for the AI credits and Actions minutes, and whether automatic reviews are allowed on client repos.
5. Set MCP servers in Copilot explicitly. If you allow it, consider limiting access to a registry you control.
6. Review the model list per client. Check which models show “Delegate to Default Policy,” including Grok 4.7 and the replacements arriving October 19. Disable any model a client has not approved.
7. Write the decision down. Record the setting, the date and the approver for each client. The next new feature or model then has a rule to follow.

Explicit settings are the safest ones here, because the global default never overrides them.

Editor settings still matter after October 22

Organization policy decides what Copilot can do. It does not decide what a developer’s editor trusts. A cloned client repository still opens in an editor with its own rules.

VS Code’s Restricted Mode, for example, limits AI agents, the terminal and extensions in untrusted folders. Our VS Code Workspace Trust write-up covers one way around it and the settings that close it. Treat Copilot default enablement as one layer. Pair it with editor settings you manage.

Other vendors made similar default-on changes this fall. We covered Gemini defaults in Google Workspace and ChatGPT for Word. In each case, an admin who never opened the setting got the vendor’s choice.

What we could not confirm

As of September 29, 2026, a few points remain open:

• The full feature list. GitHub names the Features & clients page but does not list every item on it.
• Standalone organizations. The docs describe enterprise and delegated organization behavior. They do not describe a standalone Copilot Business organization directly.
• The MCP starting state. GitHub’s MCP page calls that policy disabled by default. It does not say whether that counts as unconfigured for the new default. Set it explicitly and the question goes away.

GitHub’s community discussion for the change had no staff clarifications when we checked. Watch the changelog for updates before October 22.

Frequently Asked Questions