GitHub has announced that, no earlier than September 28, 2026, it plans to relaunch Copilot Chat on GitHub.com, Copilot Chat in GitHub Mobile, and GitHub Copilot cloud agent as a single experience. The most important point for administrators is that September 28 is a minimum launch date, not a promise that the change will happen on that exact day.
When the relaunch takes effect, the separate policies for these three experiences will be replaced by one unified policy. The new experience will be enabled by default after launch. For organizations using Copilot Business or Copilot Enterprise, this changes the operational review: a decision about the unified experience will jointly affect access to Copilot on GitHub.com and GitHub Mobile, as well as cloud agent.
What changes with the Copilot unification
GitHub's announcement brings together three changes with a direct impact on governance and day-to-day use:
- one policy instead of separate policies: cloud agent, Copilot Chat on GitHub.com, and Copilot Chat in GitHub Mobile will be governed by one unified policy;
- enabled by default: the unified experience will be enabled by default after launch;
- a new session foundation on GitHub.com: Copilot on the website will fully migrate to the agent sessions experience already used by cloud agent, while cloud agent will use Sandbox for cloud execution.
The official announcement is in the GitHub Changelog from August 28, 2026. Because GitHub used the wording “no earlier than September 28th,” administrators should monitor the changelog and policy page at rollout time, especially in environments with formal change controls.
Before and after: what administrators need to understand
| Area | Before the relaunch | After unification |
|---|---|---|
| Access policy | Experiences have separate policies. | One policy governs cloud agent, Chat on GitHub.com, and Chat in GitHub Mobile. |
| Default state | Behavior depends on the current policies for each experience and on the enterprise/organization hierarchy. | The unified experience will be enabled by default after launch, according to the announcement. |
| Chat on GitHub.com | In the documentation current on September 12, 2026, conversation messages are retained for 28 days. | With the move to agent sessions, GitHub announced that chat data will be retained for the life of the account. |
| Opt-out | The experiences could be governed separately. | Opting out of the unified experience removes access to Copilot on GitHub.com and GitHub Mobile after launch. |
| Admin action | Review separate controls for each surface in use. | Review the unified policy before rollout and confirm that the resulting access matches internal rules. |
Chat retention: from 28 days to the life of the account
The retention change is the most sensitive update for teams with privacy, security, or data-minimization requirements. The current Copilot Chat on GitHub documentation says the history shows up to 100 recent conversations and that messages in each conversation are kept for 28 days before being deleted. The August 28 announcement says that once GitHub.com fully migrates to agent sessions, chat data will be retained for the life of the account, aligning it with the existing cloud agent experience.
There is an important caveat: the changelog explicitly ties this retention change to Copilot on GitHub.com. It does not say that every Copilot chat in every client and IDE will automatically get the same retention. Internal policies therefore should not generalize the new rule to surfaces that the announcement does not mention.
For administrators, the practical effect is to revisit governance documents that still assume a 28-day window for GitHub.com chat. The change also deserves attention in information-classification procedures and user guidance about what may or may not be placed in prompts and conversations. This is an operational recommendation; specific legal or contractual requirements should be evaluated in each organization's own context.
How enterprise and organization policies work together
Unification does not remove the Copilot administration hierarchy. The GitHub Copilot policy documentation explains that policies are set at the enterprise level first. In general, enterprise administrators can enable, disable, or let organizations decide. Cloud agent has a special case: an enterprise can select which organizations receive access.
In practice, an organization cannot override an explicit enterprise-level decision. The cloud agent administration documentation for organizations reinforces this point. The pre-launch review should therefore start at the highest governance level: enterprise first, then organization, and finally controls that apply to repositories.
What can still be controlled beyond the unified policy
“Unified policy” does not mean that every Copilot administrative control has been collapsed into one switch. Current cloud agent documentation provides additional controls, and the unification announcement does not say that they will be removed.
- Availability by organization: the enterprise can restrict cloud agent to selected organizations.
- Availability by repository: organizations can block cloud agent in some or all of their repositories.
- Automations: permission for automations in repositories is managed separately from the main cloud agent policy.
- Agent firewall: organization administrators can configure the cloud agent firewall and which external hosts it can access.
These controls separate the question “who can use the experience?” from more specific questions such as “in which repositories?”, “with automations?”, and “with which network destinations?”. For regulated teams, that distinction helps avoid treating unification as unrestricted agent access.
What happens if the organization opts out
GitHub says no action will be required to keep using Copilot on GitHub.com and GitHub Mobile when the unified experience launches. The important consequence is on opt-out: if the unified experience is disabled, the user or team will lose access to Copilot on GitHub.com and GitHub Mobile after the new model takes effect.
That is why GitHub told Copilot Business and Enterprise administrators to review the policy before September 28. In the announcement, the path is to open Copilot settings on GitHub.com, select the Copilot cloud agent policy—marked “coming soon” in the post—and set the desired option. Because the interface may change at launch, administrators should confirm the final name and location of the control when rollout occurs.
There is another September 28 change: Code Review defaults to Balanced
The same changelog includes a parallel but separate change from the unified policy. Starting September 28, 2026, the Default value for GitHub Copilot code review will use the Balanced effort level instead of Lite. The setting can exist at both organization and repository levels: the organization default applies to repositories that have not chosen their own level, and the repository default applies to automatically requested reviews.
Teams that want to keep Lite should explicitly select Lite before September 28 instead of leaving the setting at Default. This belongs on the admin checklist because it occurs in the same window, but it should not be confused with the Chat and cloud-agent unification.
Do not confuse the September 28 change with the October 1 billing changes
The August 28 announcement also covers billing for Copilot Business and Enterprise. For existing customers paying by credit card or PayPal, the announced billing changes begin on October 1, 2026. They are a separate track: they do not define the unified policy or chat retention.
Separating the dates prevents a common rollout error: September 28 is the earliest window for the new experience and the Code Review default change; October 1 is the stated date for certain billing changes for existing customers.
Administrator review checklist
- Before rollout: confirm at the enterprise level which Copilot policy prevails and which organizations receive access.
- Review the unified policy: decide whether GitHub.com, GitHub Mobile, and cloud agent should remain available to the affected teams.
- Update the retention matrix: replace the 28-day assumption for GitHub.com chat with the announced life-of-account retention once the migration takes effect.
- Check complementary controls: allowed repositories, automations, and the cloud agent firewall.
- Review Code Review: if the organization does not want Balanced as the new default, explicitly select Lite before September 28.
- Communicate with users: explain the opt-out effect and retention change before activation.
- Confirm the actual launch date: because GitHub said “no earlier than September 28,” validate the changelog and settings at rollout time.
The governance benefit comes from treating this as a package of decisions, not merely a UI change. The unified policy simplifies control across three surfaces, but it also increases the impact of a single choice; at the same time, longer retention for GitHub.com chat requires an explicit review of data expectations. To track the rollout, use the official changelog and the Copilot policy documentation.
