GitHub Copilot's September 28 change is three releases, not one toggle: an access-policy merge, a retention change, and a code-review cost default. Snapshot each current state, name an owner, and pin any deliberate exception before the platform moves.
Treat September 28 as three separate releases
Do not approve the September 28 Copilot change as one product update. GitHub is changing three controls that answer different questions.
- Access: Copilot Chat on github.com, GitHub Mobile, and Copilot cloud agent will converge under one unified policy. GitHub says the unified experience will be enabled by default after launch.
- Retention: chat data on github.com will move from 28-day retention to retention for the life of the account, aligning it with the cloud-agent experience.
- Review effort: repositories and organizations that leave Copilot code review on
Defaultwill move from Lite to Balanced.
GitHub says the relaunch will happen no earlier than September 28, 2026. The date is a vendor boundary, not evidence that every enterprise should accept the same configuration. Access, data lifecycle, and review economics need separate owners and separate acceptance records.
The strongest release decision may be mixed. An enterprise could accept the unified experience for a pilot group, require a retention review before broad enablement, and pin Lite for routine repositories while qualifying Balanced on security-sensitive code.
Snapshot the current control plane
Record the effective policy for each covered group before editing a setting. GitHub evaluates enterprise controls before organization controls, and cloud-agent access can be limited to selected organizations. A screenshot of one organization is not an enterprise inventory.
Capture these fields for every affected scope:
- enterprise and organization identifier;
- current web, mobile, and cloud-agent policy state;
- repositories opted out of cloud-agent use;
- people permitted to manage AI controls;
- current code-review effort at organization and repository levels;
- retention owner and governing requirement;
- user, cost-center, organization, and enterprise budget controls;
- timestamp, actor, and evidence URL for the snapshot.
Resolve license conflicts explicitly. GitHub documents that the least restrictive setting usually applies when one user receives access from multiple organizations in the same enterprise, with exceptions. Across different enterprises, the most restrictive setting almost always applies. “The enterprise policy is off” is therefore not enough to predict every user's effective access.
Cloud-agent policy is also not the whole agent surface. GitHub's enterprise agent-management documentation says third-party agents such as Claude and Codex have separate policies, while local agents in Visual Studio Code are not managed through GitHub at all. Inventory them as separate runtime tuples rather than assuming one Copilot switch closes every path.
Decide retention and review effort independently
Accept or reject account-lifetime chat retention on its own evidence. Opting out of the unified experience removes Copilot access on github.com and GitHub Mobile after launch, so the retention decision has a user-experience consequence. It is still not a reason to silently accept the new lifecycle.
Name the data owner, the affected populations, the deletion process, the audit requirement, and the exception path. If the enterprise cannot reconcile account closure, legal hold, deletion, and export expectations, keep the access decision pending rather than treating default enablement as approval.
Review effort needs a different test. Lite is the fast, targeted option for common bugs, security issues, and style inconsistencies. Balanced routes the pull request to a higher-reasoning model for longer analysis of complex logic, security-sensitive code, and cross-service changes. GitHub's current code-review documentation estimates $0.05 to $1 of AI credits for a Lite review and $0.25 to $5 for Balanced. The ranges can change as models evolve and exclude GitHub Actions minutes.
Do not choose Balanced because it sounds safer. Pick representative pull requests from the task class, record findings accepted by the human reviewer, false positives, missed seeded issues, review time, AI credits, and Actions minutes. The release metric is cost per accepted review finding for that repository class, not review count.
If Lite is the intended default, explicitly select Lite at the organization or repository level before September 28. Leaving the setting on Default is a decision to follow GitHub's future default.
Build one reversible release record
Create one record with three independently releasable changes. Each row needs the same evidence shape:
| Control | Owner | Acceptance evidence | Rollback |
|---|---|---|---|
| Unified access | AI platform owner | Effective-policy probe for pilot users | Restore prior scope or opt out |
| Account-life retention | Data owner | Approved lifecycle and deletion test | Disable affected experience |
| Balanced review | Engineering owner | Repository eval plus cost boundary | Pin Lite at org or repo |
The record should bind the current state, intended state, actor, scope, timestamp, representative tests, cost boundary, stop condition, and post-change observation. Keep the configuration evidence beside the decision. A meeting note that says “Copilot approved” cannot tell an operator which of the three controls was accepted.
Put budget checks into the same release. GitHub allows alert thresholds at 75%, 90%, and 100%, and a user-level Copilot budget is evaluated before cost-center and enterprise limits. Overlapping limits can block a user even when a broader pool still has capacity. Test the intended hard-stop and alert path with the same identity and scope the pilot will use.
This is the same principle as the repository release rule: inventory is not release evidence. A default setting is an input. The controlled configuration, representative result, observed cost, and reversible rollback make it a release.
Observe the first week without inventing ROI
Measure reach, cost, and accepted work separately after the change. Do not use adoption as a proxy for code quality.
For access, compare intended pilot membership with effective access and audit events. For retention, verify that the expected sessions are visible and that account or deletion workflows behave as approved. For code review, join each review to its repository, effort level, AI credits, Actions minutes, human disposition, and accepted finding.
The existing Copilot usage-metrics limits still apply. Aggregate activity can show that people used a feature. It cannot prove that a review finding was correct, that the policy applied to the intended identity, or that the resulting patch was accepted.
Stop the rollout if effective policy diverges from the approved scope, retention cannot be reconciled, or review spend crosses its boundary without a corresponding accepted-work improvement. A vendor default should never outrun the enterprise's ability to observe and reverse it.
GitHub Copilot September 28 FAQ
What changes on September 28 for GitHub Copilot?
GitHub says its web, mobile, and cloud-agent experiences will converge under one policy, chat data on github.com will move from 28-day to account-lifetime retention, and code review left on Default will use Balanced effort.
How can an organization keep Copilot code review on Lite?
Explicitly select Lite at the organization or repository level before September 28. GitHub says that an explicit Lite setting will not switch to Balanced.
Does disabling Copilot cloud agent disable third-party coding agents?
No. GitHub documents separate policy controls for third-party agents such as Claude and Codex. Local Visual Studio Code agents also sit outside GitHub's agent-management controls.
Does Balanced review cost more than Lite?
GitHub publishes higher estimated AI-credit ranges for Balanced than Lite and lists GitHub Actions minutes as a separate cost component. Measure both on representative pull requests before making Balanced the default.
