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:
Copilot Chat on GitHub.com
Copilot Chat in GitHub Mobile
GitHub Copilot cloud agent
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:
Understanding the repository context.
Investigating an issue.
Planning a change.
Modifying files.
Running commands or tests.
Reviewing the resulting changes.
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:
Who is allowed to use the unified experience?
Which repositories can be accessed?
Which teams currently use cloud agent?
Are there repositories that should have additional restrictions?
Are developers using Copilot on GitHub.com for sensitive work?
Are existing organization policies still appropriate?
Does the new policy match the company's AI governance requirements?
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:
What information can developers enter into Copilot?
Are proprietary implementation details allowed?
Can production incident information be included?
Are credentials or secrets explicitly prohibited?
Are customer-specific details allowed?
Does the organization's retention policy permit account-lifetime storage?
Does the security team need to update its internal AI usage guidance?
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:
Security-sensitive source code
Credentials and configuration files
Proprietary algorithms
Internal infrastructure code
Sensitive customer-specific code
Generated files containing confidential information
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:
How many useful findings were produced?
How many findings were false positives?
Did the review identify issues missed by developers?
How long did the review take?
How much additional AI usage did it consume?
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:
Pull request review
Automated tests
Static analysis
Repository rules
CODEOWNERS requirements
Existing security checks
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:
Copilot may move toward an agent-session-based experience.
Conversations can have a longer retention period.
Cloud-agent capabilities are becoming part of the unified experience.
Code review may use Balanced when the setting remains Default.
Repository and organization policies determine how Copilot is used.
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.
Join the conversation! Your thoughts help the community grow.