GitHub announced a new global default policy for generally available Copilot features and supported client capabilities on September 24, 2026. Copilot Business and Enterprise administrators can configure it now; it starts applying on October 22, 2026.
The setting decides what happens when an eligible Copilot feature is left unconfigured: Enabled, Disabled, or Let organizations decide. Explicit feature decisions remain intact, and preview features stay opt-in. GitHub’s announcement says the rollout includes eligible policies on the Features & clients page, Copilot Code Review on the Agents page, and MCP servers in Copilot policy.
What changes on October 22
- Unconfigured eligible GA features will inherit the selected global default.
- Existing explicit enable or disable decisions are preserved.
- Preview features do not inherit this policy; they remain opt-in.
- The feature policy covers existing unconfigured GA features too, not only new releases.
GitHub’s documentation notes that the policy is enabled by default. If an enterprise takes no action, unconfigured eligible features will be enabled when the policy becomes active. The same documentation distinguishes this feature policy from the already-active default availability policy for released models.
Why this matters for QA engineers
QA teams often encounter Copilot changes through code review, client tools, and MCP-connected workflows before they appear in a formal test plan. A default policy can make that exposure predictable, but only if the organization decides its posture before the activation date. Treat October 22 as a release-readiness checkpoint: inventory unconfigured Copilot capabilities, decide which can enter test environments automatically, and explicitly set policies for anything that needs security, compliance, or regression validation first.
A concise QA readiness checklist
- Review the AI Controls > Copilot feature inventory and identify policies still marked Unconfigured.
- Confirm ownership for Copilot Code Review and MCP-server policy decisions; both are in scope.
- Use an explicit Disabled policy for capabilities that require a controlled pilot before GA adoption.
- For permitted capabilities, add acceptance tests for permissions, audit evidence, code-review behavior, and connected-tool boundaries.
- Record exceptions by organization if different products or regulated teams need different rollout timing.
This is a governance change, not a claim that every new Copilot feature is safe to enable everywhere. The practical test is whether your team can explain which GA capabilities may be enabled by default, which are deliberately disabled, and how the resulting workflows are validated.