GitHub is preparing to bring Copilot Chat on GitHub.com, Copilot Chat in GitHub Mobile, and GitHub Copilot cloud agent into a single unified experience.

The change is planned to begin no earlier than September 28, 2026.

For individual developers, this may look like a product interface change. For organizations using GitHub Copilot Business or Enterprise, it is more important than that. The change introduces a unified policy, changes how GitHub.com Copilot sessions work, and changes the retention period for chat data.

There is also a separate Copilot code review change scheduled for the same date. The default review effort will move from Lite to Balanced when the organization or repository is still using the Default setting.

Teams should review their Copilot configuration before September 28 instead of waiting for the new experience to appear.

What Is Changing?

GitHub currently provides Copilot through several related experiences, including:

GitHub plans to converge these into one unified Copilot experience.

The separate policies governing these experiences will be replaced by a single policy.

The unified experience will also be enabled by default after launch.

This means organizations should treat the change as a policy and governance update, not simply a UI redesign.

The September 28 Timeline

There are two Copilot changes that administrators should review before the date.

Change

Current behavior

Planned behavior

Copilot experience

Separate GitHub.com, Mobile, and cloud-agent experiences

Unified Copilot experience

Policy

Separate policies

Single policy

Default state

Existing configuration

Unified experience enabled by default

GitHub.com sessions

Existing Copilot Chat experience

Agent sessions experience

Chat retention

GitHub.com chat data retained for 28 days

Retained for the life of the account

Cloud execution

Existing cloud-agent behavior

Cloud agent will leverage Sandbox

Code review Default

Lite

Balanced

The unified experience is planned for no earlier than September 28, so administrators should avoid treating the date as proof that every account will change at exactly that moment.

Why the Unified Experience Matters

The most important change is the move toward agent sessions.

GitHub says Copilot on GitHub.com will fully migrate to the agent sessions experience previously used by Copilot cloud agent.

An agent session is different from a traditional question-and-answer interaction.

A typical development task can involve:

  1. Understanding the repository context.

  2. Investigating an issue.

  3. Planning a change.

  4. Modifying files.

  5. Running commands or tests.

  6. Reviewing the resulting changes.

  7. Continuing the session when additional work is required.

That workflow is closer to delegated software development than simple chat.

For developers, this can make Copilot more consistent across the different places where development work starts.

For administrators, it means the policy governing these capabilities deserves closer attention.

Review the Unified Copilot Policy

GitHub has stated that the separate policies for these experiences will be replaced by a single policy.

Business and Enterprise administrators should therefore review the Copilot policy before September 28.

The important question is not simply:

Is Copilot enabled?

The better questions are:

If an organization has separate expectations for chat and agent-based work, those differences should be reviewed before the policies converge.

Understand the Chat Data Retention Change

One of the most important changes is easy to miss.

GitHub says Copilot Chat on GitHub.com will move from a 28-day retention period to retention for the life of the account as part of the unified experience.

That changes the way organizations should think about Copilot conversations.

A developer may put much more information into a Copilot session than a short question. An agent session can contain repository context, requirements, debugging information, implementation discussions, and other development details.

That makes retention a governance consideration.

Questions Teams Should Ask

Before the rollout, review:

The exact answers depend on the organization's policies and regulatory requirements. Do not assume that a longer retention period is acceptable simply because the data is inside GitHub.

Review Existing Content Exclusions

Organizations already using Copilot content exclusions should verify that their exclusions still represent the intended boundary.

Typical candidates include:

A content exclusion policy should be treated as one layer of protection, not a replacement for access control and secure development practices.

Developers should also understand that preventing Copilot from using a specific path does not mean the underlying repository is protected from every other form of access.

Check How Developers Use Copilot Today

Before the change, identify which Copilot surfaces your developers actually use.

A simple inventory can help:

Copilot usage

Team using it

Business purpose

Review needed

GitHub.com Chat

Development

Code questions

Yes

GitHub Mobile

Engineering leads

Quick repository questions

Yes

Cloud agent

Development teams

Delegated coding tasks

Yes

IDE Copilot

Developers

Daily coding

Yes

Code review

Development teams

Pull request review

Yes

The purpose is not to remove tools.

It is to understand what changes when multiple experiences begin following one policy.

Prepare for the Code Review Default Change

The unified Copilot rollout is not the only change scheduled for September 28.

GitHub is also changing the default effort level for Copilot code review from Lite to Balanced.

The important detail is how the Default setting works.

An organization-level default applies to repositories that have not selected their own review effort. A repository-level setting can override the organization default.

Starting September 28, repositories and organizations that remain on Default will use Balanced.

If a team explicitly selects Lite before the change, GitHub says that explicit selection will be respected.

Why Code Review Effort Matters

Different effort levels can affect how much reasoning Copilot uses during review.

A team should therefore avoid changing the setting blindly.

For example, a repository with small pull requests and strict review-time requirements may prefer a lighter review process.

A security-sensitive repository with complex changes may benefit from more thorough automated analysis.

The correct setting depends on the repository and review workflow.

A Practical Review Test

Before September 28, choose several representative pull requests and evaluate:

  1. How many useful findings were produced?

  2. How many findings were false positives?

  3. Did the review identify issues missed by developers?

  4. How long did the review take?

  5. How much additional AI usage did it consume?

  6. Did developers find the additional findings useful?

Do not judge Balanced simply by the number of comments it produces.

More comments do not automatically mean better code review.

Check Organization and Repository Defaults

Administrators should review settings at both levels.

For example:

Enterprise
   |
   +-- Organization A
   |      |
   |      +-- Repository 1
   |      +-- Repository 2
   |
   +-- Organization B
          |
          +-- Repository 3
          +-- Repository 4

An organization-wide configuration can affect many repositories, while repository-level settings may override it.

This creates a common problem during policy changes: administrators believe they have configured the organization correctly, but individual repositories already contain explicit settings.

Before the rollout, identify where settings are inherited and where they are overridden.

Do Not Treat Opting Out as a Simple Rollback

GitHub's announcement contains an important limitation.

If an organization or user opts out of the unified experience, access to Copilot on GitHub.com and GitHub Mobile will be lost after the new experience launches.

That means opting out is not equivalent to keeping the old Copilot Chat experience.

Teams should therefore make the decision based on policy and governance requirements rather than assuming they can temporarily switch back to the previous experience.

Prepare Developers for Agent Sessions

Developers who currently use Copilot primarily as a chat assistant may notice a different workflow when working with agent sessions.

The preparation should be simple.

Explain the Difference

Make sure developers understand that an agent can work through a multi-step task instead of simply returning text.

Reinforce Review Requirements

AI-generated changes should still go through:

Keep Sensitive Information Out

Developers should continue following organizational rules for secrets, credentials, customer data, and proprietary information.

A unified experience does not change those responsibilities.

A Pre-September 28 Checklist

Use this checklist before the rollout:

[ ] Review the new unified Copilot policy
[ ] Identify users and teams using GitHub.com Copilot
[ ] Identify teams using GitHub Mobile Copilot
[ ] Identify teams using Copilot cloud agent
[ ] Review content exclusion rules
[ ] Review sensitive repository access
[ ] Review Copilot chat retention requirements
[ ] Check organization-level code review settings
[ ] Check repository-level code review settings
[ ] Decide whether repositories should use Lite or Balanced
[ ] Test representative pull requests
[ ] Document the approved Copilot policy
[ ] Communicate the changes to developers
[ ] Verify settings after the rollout

Common Mistakes to Avoid

Assuming It Is Only a UI Change

The move changes policy and session behavior as well as the user experience.

Ignoring Data Retention

Account-lifetime retention is materially different from a 28-day retention period.

Checking Only Organization Settings

Repository-level settings can affect individual repositories independently.

Automatically Choosing Balanced Everywhere

Balanced becomes the Default, but that does not mean it is the right choice for every repository.

Treating Opt-Out as a Rollback

Opting out can remove Copilot access from GitHub.com and GitHub Mobile after launch.

Forgetting Developer Communication

Administrators may understand the policy change while developers continue using Copilot as if nothing changed.

What Developers Should Do

Most developers do not need to change their workflow immediately.

The useful preparation is to understand:

Developers should continue treating generated code as code that requires review, testing, and normal engineering controls.

Final Checklist for September 28

The September 28 Copilot changes are worth reviewing before they arrive because several settings move together.

The key areas are policy, access, retention, agent sessions, and code review effort.

For organizations, the safest approach is to document the desired configuration before the rollout instead of accepting every Default setting without review.

For developers, the main change is the shift toward a more unified agent-based Copilot experience. The development workflow may become more capable, but normal repository controls, testing, security practices, and human review still remain necessary.

The September 28 date should therefore be treated as a configuration checkpoint. Review the settings, test the workflow, communicate the changes, and make explicit choices where the defaults do not match your team's requirements.