September 3, 2026 update: Two September 2 GitHub Changelog entries add governance controls to the existing model, budget and review checklist. Enterprise-managed settings can support an administrator-selected default model, and content exclusions are generally available in the Copilot app and CLI. The controls have different surfaces and limits, so verify the product and policy scope before treating either as universal.
September 2 additions: default models and content exclusions
Default model policy
GitHub’s default-model changelog says enterprise-managed settings support any preferred default model for new conversations, with team overrides through the documented model and team-mapping controls. The relevant administrator task is to record the intended default, the teams allowed to override it and the review owner. “Available in the setting” does not mean every model is available to every plan, organisation, user or surface.
Content-exclusion policy
GitHub also says content exclusions are generally available in the Copilot app and CLI and that the app/CLI respect enterprise, organisation and repository policies. The Changelog entry should be read with the content-exclusion documentation: an administrator configures paths or fnmatch-style patterns, propagation can take up to 30 minutes, and the setting must be tested. The current documentation notes a limitation for Agent mode in IDEs, so do not claim that one exclusion configuration blocks every Copilot surface.
| Control | Administrator evidence to save | Boundary |
|---|---|---|
| Default model | Enterprise setting, preferred model, team mappings and an example new conversation. | Plan, organisation and surface availability still need verification. |
| Content exclusion | Enterprise/org/repository policy, path patterns, propagation timestamp and a controlled test. | App/CLI GA does not establish full IDE Agent-mode coverage. |
| Budget expiry | Owner, limit, expiry date, notification and renewal decision. | Keep the existing budget section; a default model can change consumption without changing the policy. |
| Code-review approval | Repository rule, reviewer role, pilot evidence and rollback path. | Keep the existing review section; model selection is not approval authority. |
Use GitHub’s enterprise-managed-settings reference as the schema authority and its configuration guide for the admin path. Test one repository with a known excluded path, one included path and the actual client surfaces your teams use. Save the observed policy state and timestamp; do not infer a successful exclusion from a setting that has not propagated. The prior model-deprecation, multi-organisation access, individual-budget and code-review sections below remain part of the same reader job and should not be removed or shortened.
Secondary Changelog coverage and community discussions help identify administrator questions, but they do not establish plan entitlement or enforcement. For adjacent implementation, use the Copilot VS Code release guide for feature changes, the agent/plugin guide for tool governance and the agent-harness guide for state and evaluation. This page remains the September governance canonical.
Editorial boundary: the two September 2 entries are documented product-policy updates. They do not prove that a particular organisation has the setting enabled, that a user can select every model or that an exclusion covers every client. Confirm account-level readback before changing production policy.
Short answer: GitHub’s September 2026 Copilot changes require an admin inventory: map deprecated models, verify the billing organisation, set budget expiry deliberately and pilot code-review approvals before relying on them.
Four GitHub Changelog entries from 31 August and 1 September 2026 change Copilot governance rather than adding one isolated feature. This checklist turns the model, access, budget and review-policy changes into explicit owner decisions.
The September admin checklist
GitHub’s 31 August and 1 September 2026 Changelog entries form one practical administrator update. The changes touch four controls: selected model deprecations, Team-plan model access when a user belongs to multiple organisations, individual-user budget expiry, and Copilot code-review approvals.
The safest response is an inventory, not a panic migration. Check which repositories and teams depend on a named model, identify the billing organisation for multi-seat users, record budget owners and expiry dates, and decide whether code-review approval belongs in branch protection. GitHub says no action is required to remove the deprecated models, but that does not remove the need to test the replacement workflow.
This page complements the GitHub Copilot VS Code August release guide, which owns feature changes. It does not absorb the model-selection question covered in the existing Fable versus Sonnet comparison.
| Model lifecycle | Selected Copilot models are deprecated with replacement families listed by GitHub; no removal action is required. |
|---|---|
| Team access | For users with multiple organisation seats, access is determined by the billing organisation under Usage billed to. |
| Budget | Business and Enterprise admins can set an individual budget expiry or no expiry. |
| Review | Copilot can make configurable approval assessments; approvals are off by default. |
| Owner | The organisation should record a human owner for each policy and exception. |
Model deprecations: map by family, then test
GitHub’s 31 August Changelog says selected Copilot models were deprecated from 1 September 2026 and lists replacements: Gemini3.1 Pro to Gemini3.7 Flash, Claude Opus4.5/4.6 to Opus4.7/4.8/5, Claude Sonnet4.5/4.6 to Sonnet5, and Raptor Mini to MAI-Code-1.1-Flash. Use that list as a lifecycle map, not as a claim that every replacement behaves identically.
GitHub says no action is required to remove the deprecated models and administrators may enable alternatives. Still, teams should test the prompts that matter: code generation, review comments, tool calls, long-context tasks and any marketing-operations automation that consumes the output. Record the model, repository, prompt class and observed failure mode.
Do not update a production runbook solely by replacing a string. A model deprecation can change latency, context behavior, tool permissions, quality and cost. Keep the rollback or fallback decision with the repository owner and verify current policy in the live organisation.
- Inventory model names in prompts, policies, docs and automation.
- Map every deprecated family to GitHub’s listed replacement family.
- Run representative tests with the replacement before changing a production default.
- Record model, date, repository, task class and reviewer.
- Keep a human fallback for critical workflows.
Team access now follows the billing organisation
GitHub says that when a user has seats in multiple organisations, Team-plan model access is determined only by the billing organisation shown under Usage billed to. That rule explains why a user can have a seat in one organisation but not see the expected Team-plan model access from another.
The operational check is straightforward: identify the seat, open the billing or usage relationship, find the organisation that is billed, and inspect its model policy. Do not ask a user to change seats or permissions until the billing path is confirmed. GitHub says enterprise-only access is unaffected by this specific change.
For an adjacent access-control mindset, use the agent plugins, Skills and MCP guide and the scheduled-workflow permissions guide; those pages are not GitHub documentation, but they reinforce explicit ownership and permission checks.
| User state | A user can have seats in multiple organisations. |
|---|---|
| Billing owner | The organisation under Usage billed to controls Team-plan model access for this case. |
| Enterprise-only access | GitHub says it is unaffected by this specific Team-plan update. |
| Next step | Verify the live billing and model-policy state before changing a seat or repository setting. |
Individual budget expiry is a governance control
GitHub’s 1 September update lets Business and Enterprise administrators set an expiration date for individual user budgets. The choices are no expiration, the next billing cycle or a specific date; GitHub also exposes an API field named expires_at. The value is operational: a budget can have a review date instead of remaining open-ended by accident.
Assign an owner and reason to each expiry. A temporary project may use a fixed date, while a recurring team budget may align to the next billing cycle. Record what happens at expiry, how the user requests renewal, and whether repository or organisation budgets remain unaffected. Do not assume a budget setting is a complete cost-control system.
Review spend and task value together. A lower cap can protect a budget while also interrupting a critical agent workflow. Set an escalation path before a user reaches the limit and make the renewal decision visible to the technical and business owner.
Copilot code-review approvals are off by default
GitHub says Copilot code review now produces approval assessments in every review, while actual approvals are off by default and can be configured at the enterprise, organisation or repository level. If enabled, the approval can count toward required approvals. GitHub also says a new commit dismisses the approval.
That makes this a branch-protection decision, not a simple quality badge. Before enabling it, define which repositories qualify, what human review remains required, how CODEOWNERS interacts with the setting, and what happens when a new commit arrives. Test the setting in a non-critical repository and keep an audit trail of policy changes.
For wider agent permission context, connect to the Claude Code Auto Mode guide; the product is different, but the governance principle is shared: make machine authority explicit and reviewable.
| Default | Actual Copilot approvals are off by default. |
|---|---|
| Scope | Enterprise, organisation and repository configuration are listed. |
| Protection | When enabled, approvals can count toward required approvals. |
| Fresh commit | GitHub says a new commit dismisses the approval. |
| Human review | Keep repository-specific human and CODEOWNERS controls explicit. |
A practical admin runbook
Start with a change register dated 1 September 2026. For each team, list deprecated models, replacement tests, billing organisation, budget expiry, code-review policy and owner. Add the source link and the evidence date so the register can be refreshed when GitHub changes the product.
Then run the smallest safe validation: one representative task per model family, one multi-seat access check, one budget expiry read-back and one review-policy test in a non-critical repository. This draft does not perform those account or UI checks; it gives the administrator the questions to answer.
Finally, publish internal guidance that distinguishes what GitHub changed from what your organisation decided. That separation prevents a vendor default, an entitlement condition and an internal control from being reported as the same thing.
Recommended workflow
- Create a dated inventory of affected models, organisations, budgets and repositories.
- Map deprecated model families and test listed replacements on representative tasks.
- Verify the billing organisation for any user with multiple Team-plan seats.
- Set budget expiry with an owner, renewal path and escalation rule.
- Pilot code-review approvals in a non-critical repository and re-check branch protection after new commits.
Related Digital Marketer guides
- GitHub Copilot in VS Code August 2026 — Existing Copilot feature-release owner; this draft is admin governance.
- OpenAI agent plugins, Skills and MCP — Agent integration and control-plane context.
- ChatGPT Work scheduled tasks — Scheduled-workflow governance context.
- ChatGPT Site Tools and WebMCP — Browser and site-tool workflow context.
- Claude Code Auto Mode — Permission and classifier context for agentic work.
- Claude Tag for Marketing Teams — Slack-based Claude workflows, memory and spend controls.
Questions marketers are asking
Do I need to remove deprecated Copilot models?
GitHub says no action is required to remove them and administrators may enable alternatives. Test and document replacements if a workflow depends on a deprecated family.
Why can a multi-organisation Team user lose model access?
GitHub says access is determined by the billing organisation under Usage billed to for this case.
Can an individual Copilot budget expire?
Business and Enterprise admins can choose no expiry, the next billing cycle or a specific date, according to GitHub.
Can Copilot approve a pull request automatically?
GitHub says approval assessments are available, actual approvals are off by default and configurable. If enabled, they can count toward required approvals; new commits dismiss the approval.
Sources and dates
Publication, event, and update dates are kept separate below. A source without a stated publication date is marked accordingly; access date is 2 September 2026.
- GitHub Changelog: selected Copilot models deprecated — published/event date: 2026-08-31; accessed 2 September 2026. GitHub lists model replacements effective 1 September 2026 and says no removal action is required; administrators may enable alternatives.
- GitHub Changelog: Copilot Team model access update — published/event date: 2026-08-31; accessed 2 September 2026. For users with seats in multiple organisations, GitHub says access is determined by the billing organisation under Usage billed to.
- GitHub Changelog: expiration dates for individual user budgets — published/event date: 2026-09-01; accessed 2 September 2026. GitHub says Business and Enterprise admins can set no expiry, next billing cycle or a specific date through the API or admin controls.
- GitHub Changelog: Copilot code review approvals — published/event date: 2026-09-01; accessed 2 September 2026. GitHub says approval assessments are available, actual approvals are off by default and can be configured; approved reviews count toward required approvals when enabled.
Editorial note: Re-check platform documentation immediately before implementation. Product rollouts, eligibility, pricing, policy, and measurement definitions can change after this draft.
