Review this before October 22, 2026. Eligible Copilot features turn on unless an administrator sets a policy. Related controls: local sandboxing, OpenTelemetry, and Copilot billing and policy changes.
GitHub is introducing a global default policy for generally available Copilot features and supported client capabilities in organizations and enterprises using Copilot Business or Copilot Enterprise. The policy begins affecting access on October 22, 2026.
For eligible features that remain unconfigured, the selected global default will determine whether they are available. GitHub’s documentation says the feature policy is enabled by default, so administrators should review their settings before that date rather than assume every feature decision has already been made explicitly.
What changed
The change adds a default policy for eligible generally available Copilot features. Administrators can select one of three settings:
- Enabled: eligible, unconfigured generally available features can become available by default.
- Disabled: eligible features left under the default remain unavailable unless they are explicitly approved.
- Let organizations decide: applicable decisions are delegated to organization administrators where enterprise governance permits that delegation.
The policy covers new generally available features, features moving from preview to generally available, and existing generally available features that are still marked as unconfigured. It applies to eligible controls managed through enterprise Features & clients settings, Copilot Code Review settings, and MCP server policy controls.
The exact future inventory of features and client capabilities included in the October rollout has not been documented. GitHub’s supported-surfaces documentation describes where policies can apply, but policy coverage does not mean that every underlying capability is available on every listed surface or that every listed surface will be part of this rollout.
Explicit decisions still take precedence
The default policy is intended to handle features without an explicit setting. Administrators’ existing decisions are preserved: a feature that is explicitly enabled or disabled will not be overridden by the global default.
This distinction is important for organizations that have already reviewed individual Copilot controls. The October 22 change does not replace those decisions. Instead, it determines the outcome for eligible features that are still unconfigured and for qualifying features introduced or promoted to general availability later.
Preview features remain separately opt-in. An organization must choose to use a preview, and an existing opt-in or opt-out decision is preserved if that feature later becomes generally available. The default-availability documentation also distinguishes this feature policy from the separate default-availability policy for released models, which is already active.
Who controls the policy
Enterprise owners can define policies across an enterprise or delegate applicable decisions to organization owners. If an enterprise selects a specific setting, an organization generally cannot override that enterprise policy. Delegated policies are subject to GitHub’s policy conflict rules, which can vary by feature.
Enterprise policy administration is documented for enterprise owners and users with the Manage enterprise AI controls custom role permission. Organization-level administration is documented for organization owners and users with applicable granular custom permissions, although the supplied documentation does not enumerate every organization-level permission.
Administrators should also account for how Copilot access is assigned. Users licensed directly by an enterprise are not covered by the Let organizations decide option in the same way as organization users; a separate policy determines the default for those users.
When policies conflict, the effective result can depend on the feature. Availability generally follows either the least restrictive or most restrictive policy, and sensitive features can use the most restrictive setting. Users licensed across multiple enterprises may also be subject to the most restrictive applicable policy, with documented exceptions. The policy conflict reference should be consulted for complex enterprise arrangements.
Why this matters for engineering teams
An enabled default can reduce the administrative work required when new generally available Copilot capabilities are released. However, it also means that unconfigured features may become available without a separate approval decision on October 22.
That behavior matters for teams with formal review requirements, controlled development environments, or different policies across business units. A feature can be generally available without being appropriate for every organization, repository, workflow, or user group. The practical governance question is therefore not only whether Copilot is licensed, but also which feature decisions are explicit and which are still left to the default.
The policy can affect Copilot surfaces across IDEs, Copilot CLI, the GitHub website, and other supported surfaces. Coverage is not universal for every policy, however, so administrators should verify the relevant control rather than assume one setting governs every Copilot experience.
The change is not described as a vulnerability, security fix, or security incident. Its primary impact is administrative and governance-related. GitHub’s policy documentation identifies policy drift as a risk when too many people can change settings or ownership is unclear, and recommends reviewing access and monitoring policy changes through the audit log.
What administrators should do
- Review the default before October 22, 2026. In enterprise AI Controls, inspect the Copilot area and the Default policy for new features setting.
- Choose the organization’s intended default. Select Enabled, Disabled, or Let organizations decide based on the organization’s governance model.
- Find unconfigured features. Use the documented policy controls and related banner or policy information to identify eligible features still marked Unconfigured.
- Make sensitive decisions explicit. Configure individual features that should not be determined by the global default.
- Review delegated organization policies. If the enterprise allows organizations to decide, confirm that organization owners understand which decisions they now control.
- Check enterprise-assigned users. Confirm which users receive Copilot directly from the enterprise, because the delegation option does not apply to those users in the same way.
- Keep preview governance separate. Preview features remain opt-in, so review those settings independently from the new general-availability default.
- Monitor policy changes. Review administrator access and use audit-log monitoring as part of ongoing governance.
Availability and remaining limits
Administrators can configure the policy before October 22, 2026, but the supplied documentation does not specify the rollout hour or time zone. It also does not confirm whether deployment will be staged. Organizations should therefore plan around the published date without assuming a particular time of day or rollout sequence.
The change applies to eligible generally available features and capabilities for Copilot Business and Copilot Enterprise environments. GitHub has not documented the number of affected organizations or users, nor has it provided a definitive future list of every feature included in the rollout. Licensing, pricing, client-version, and compatibility requirements beyond plan eligibility are also not established in the supplied materials.
Sources
- GitHub Changelog: Default enablement of Copilot features for Copilot Business and Enterprise
- GitHub Copilot default availability documentation
- GitHub Copilot enterprise policies
- Manage Copilot policies for an enterprise
- Manage Copilot policies for an organization
- Supported surfaces for Copilot policies
- Copilot policy conflicts
