“Unconfigured” Is a Vendor Decision: Snapshot Every Agent Admin Toggle Before Oct 22
Copilot turns on Unconfigured features Oct 22 unless you decide first. Snapshot every agent admin toggle, diff it weekly and give each default an owner.
Go deeper. Build your own.
On October 22, every eligible, generally available Copilot feature your enterprise left Unconfigured gets a setting anyway. GitHub’s docs say which one: “This policy is enabled by default. If you don’t take action, unconfigured features will be enabled on October 22.” Nobody on your team made that call. The vendor made it, and the changelog post that set the date never says which way the default points.
Unconfigured sounds like a blank. It works like a proxy vote. The fix is a sweep: snapshot every agent admin toggle you own, turn each Unconfigured row into an explicit decision, and make Disabled the global default so the next generally available feature waits for a person. Then keep the snapshot running weekly, because GitHub wasn’t the only vendor moving a default this month.
The reach is the reason to bother. Copilot code review and MCP servers sit inside that policy’s scope. Claude Code started syncing account skills and plugins into terminal sessions on Sep 17, and from v2.1.283 it starts interactive sessions in auto mode.
Chatbots suggest; agents act. A default that once decided whether someone saw a chat panel now decides what runs against a pull request, and how much a session does before it asks.
Four notices, two deadlines: the agent admin toggles that moved this month
GitHub, Sep 24. A new global policy called “Default policy for new features” sits on the AI Controls page, under the Copilot subpage, with three options: Enabled, Disabled and Let organizations decide. It covers eligible features on the enterprise’s Features & clients page, plus “the Copilot Code Review policy on the “Agents” page and the MCP servers in Copilot policy”. For 28 days you can configure it without effect. Then: “Starting October 22, the policy takes effect.”
The changelog states the rule plainly: “Eligible generally available features and capabilities left Unconfigured will follow your selected global default of enabled, disabled, or let organizations decide.” Choices you already made survive: “Explicit decisions are preserved. If you’ve explicitly enabled or disabled a feature, we won’t override that choice.”
Screenshot: GitHub Changelog, “Default Enablement of Copilot features for Copilot Business and Enterprise - GitHub Changelog” (Sep 24, 2026), captured Sep 28, 2026.
What the post never says is what happens if you pick nothing. The default-availability docs do, and the answer is Enabled. They also promise a counter: “In your policy settings, you will see a banner showing how many eligible policies are currently unconfigured, so you can assess the impact of your global default and explicitly configure individual policies before October 22.”
Screenshot: GitHub Docs, “About default availability of Copilot features and models - GitHub Docs” (undated page), captured Sep 28, 2026.
The same page marks the edges: preview features stay opt-in. “Store local sessions in the Cloud” for Copilot CLI and VS Code is outside the policy, as are the GHE.com data-residency and FedRAMP model restrictions. Models run under a separate policy, “Default availability for released models”, which is already active, and the docs spell out its rule: “When a new model is released, it inherits the default until you explicitly configure it.” Pre-GA models, open-weight models, and models not covered by GitHub’s data retention agreement stay disabled by default regardless.
GitHub, Aug 28. The earlier notice said: “No earlier than September 28th, 2026, GitHub will relaunch Copilot Chat on github.com, Copilot Chat in GitHub Mobile, and GitHub Copilot cloud agent as a single, unified Copilot experience.” Their separate policies become one, and “This unified Copilot experience will be enabled by default after launch.” Retention moves with it: “chat data will be retained for the life of the account instead of 28 days”, and opting out costs access to Copilot on github.com and GitHub Mobile. The same notice moves code review’s Default effort to Balanced “starting September 28th, 2026”.
That launch is announced for no earlier than Sep 28. When we last checked GitHub’s changelog, at 20:47 UTC on Sep 28, it had posts from that day, but none saying the single policy or the Balanced switch had happened.
GitHub, Sep 18. Six Copilot models retire on October 19: Gemini 3.7 Flash, GPT-5.5, GPT-5.4, GPT-5.4 mini, GPT-5 mini and Grok 4.5. Their replacements switch on by themselves: “the suggested alternatives are automatically enabled for Copilot Enterprise and Copilot Business customers unless an administrator has turned off the global default or explicitly disabled the model.” The same default fired on Sep 28, when GitHub made Claude Sonnet 5.5 generally available in Copilot: “Under default model enablement, new models are automatically enabled unless an administrator has turned off the global default or explicitly disables this model.”
Anthropic, Sep 15 to Sep 25. Claude Code v2.1.273 (Sep 15) made sign-in “also request access to your claude.ai plugins”. v2.1.275 (Sep 17) “Added syncing of the skills and plugins enabled on your claude.ai account to terminal sessions signed in with it”. The CHANGELOG scopes v2.1.283 (Sep 25) to third-party providers or telemetry off.
The permission-modes docs are broader: “With Claude Code v2.1.283 or later, auto mode is the built-in starting permission mode for interactive terminal and VS Code sessions.” claude -p and the Agent SDK still start in default. npm’s stable tag read 2.1.274 earlier on Sep 28 and 2.1.277 by evening, while latest had reached 2.1.284. So stable-channel installs now have the sync but not the auto-mode start, which lands on stable lanes the day the stable tag reaches 2.1.283.
Step 1: Before Oct 22, turn every Unconfigured agent admin toggle into a decision
Start with the number GitHub gives you. Open the AI Controls page, read the banner’s count of unconfigured policies and write it at the top of the snapshot. That count is your to-do list. The target is zero.
Then work the rows:
- Features & clients. Every eligible feature marked Unconfigured gets Enabled or Disabled, set by a named person. Copying what the vendor would have picked is allowed. Leaving the row for the vendor to pick isn’t.
- The two named policies. The Copilot Code Review policy and the MCP servers in Copilot policy are in scope by name, and both let agents act. One reviews pull requests and, since Sep 11, can run commands while it does; the review-bot register covers what it can reach. The other admits tools. Decide both on purpose.
- The global default. Set it to Disabled. GitHub’s definition: “Disabled: Current eligible features will remain unavailable, and future eligible features will require administrator approval.” That turns the next GA feature into a request instead of a surprise. The cost is a queue somebody has to answer, which is what step 5 is for.
- Org owners. If the enterprise picks Let organizations decide, the docs apply the policy at org level to delegated features the org owner hasn’t configured. Every org owner then owns a snapshot. Put them on the sweep, or don’t delegate.
A row you set to Enabled on purpose beats a row that happens to be enabled. GitHub won’t override it, and your snapshot records who chose it and when.
The snapshot is one row per toggle. The rows below are illustrative, including the banner count; the toggle names are GitHub’s and Anthropic’s.
| Toggle | Current state | Effective state seen by the probe account | Owner | Decision | Date |
|---|---|---|---|---|---|
| Default policy for new features (AI Controls, Copilot) | Enabled by default | Not visible to users; governs the next three rows | Platform lead | Disabled | Oct 2 |
| Features & clients, each eligible feature | Unconfigured (banner: 7) | Feature absent in the probe seat | Feature owner | Enabled or Disabled, per row | Oct 9 |
| Copilot Code Review policy (Agents page) | Unconfigured | Review ran on the probe PR | AppSec | Enabled, after the review-bot register | Oct 2 |
| MCP servers in Copilot policy | Unconfigured | MCP tools offered in a probe session | AppSec | Disabled until allowlisted | Oct 2 |
| Default availability for released models | Active | Replacement models listed after Oct 19 | Platform lead | Explicit per model | Oct 18 |
Code review Default effort |
Balanced from Sep 28, per the notice | Effort the probe PR’s review ran at | AppSec | Lite or Balanced, set explicitly | Oct 2 |
| Single policy for Chat, Mobile and cloud agent | Announced; no launch post yet | Retention shown to the probe seat | Privacy | Decide on launch day | Launch + 1 |
| Claude Code skill and plugin sync | Unset | claude.ai skills in a probe session | Platform lead | Off, in managed settings | Oct 2 |
| Claude Code starting permission mode | Unset, so auto from v2.1.283 | Mode a fresh probe session opens in | Platform lead | default, in managed settings |
Oct 2 |
The mechanism fits on one page. Unconfigured rows follow whichever global default is set on Oct 22, and nobody chose that default unless someone opened the page. Explicit rows stay put. The weekly loop is what turns the first kind into the second.
Unconfigured rows follow the vendor. The loop turns them into rows you own.
Step 2: Every week, export the toggles and what a probe account actually gets
The admin page shows what you configured. It doesn’t show what a user got. Export both, weekly.
The admin side covers five kinds of setting: policies, retention, model enablement, review and effort defaults, and permission-mode defaults. GitHub doesn’t publish a list of which eligible features are Unconfigured in your enterprise; the docs point you to the banner. So the export is whatever your admin tooling produces, down to a hand transcription of the AI Controls pages if that’s all you have. Ugly is fine; missing isn’t.
The probe side is a real seat with ordinary permissions in each org, used only to read effective state. It records which features appear, which models are listed, what effort a test pull request’s review ran at, what mode a fresh Claude Code session opens in, and which synced skills and plugins show up.
The probe exists because sources disagree. GitHub’s Aug 28 notice moves code review’s Default effort to Balanced from Sep 28. GitHub’s code-review docs, fetched on Sep 28, still end their resolution list with “GitHub’s built-in default, which is Lite. Some owners have Balanced as the built-in default.” Two GitHub pages, one question, and only a probe PR tells you which answer your repositories got.
The job below is illustrative. The export and probe scripts stand in for whatever your admin tooling and probe seat produce, and MANAGED_SETTINGS points at your Claude Code managed settings file.
#!/usr/bin/env bash
# weekly-toggle-sweep.sh (illustrative): snapshot, diff, demand a decision
set -euo pipefail
WEEK=$(date -u +%G-W%V)
DIR="snapshots/$WEEK"
mkdir -p "$DIR"
# Admin side: policies, retention, model enablement,
# review and effort defaults, permission-mode defaults.
./export-admin-toggles.sh > "$DIR/admin.json"
# Probe side: what an ordinary seat actually gets this week.
./probe-effective-state.sh > "$DIR/probe.json"
# Claude Code: the managed keys that carry the opt-outs.
jq '{syncClaudeAiSkills, syncClaudeAiPlugins, disableAutoMode,
defaultMode: .permissions.defaultMode}' \
"$MANAGED_SETTINGS" > "$DIR/claude-managed.json"
# Diff against the previous snapshot. Any change opens a decision
# (owner, decision, date) and fails the job so a person sees it.
PREV=$(ls -d snapshots/*/ | sort | tail -n 2 | head -n 1)
if ! diff -ru "$PREV" "$DIR/" > "snapshots/$WEEK.diff"; then
./open-decision.sh "snapshots/$WEEK.diff"
exit 1
fi
The job fails on a change and on an error. An export that breaks is a red job, not a quiet week, and a quiet week nobody verified is exactly what this sweep exists to prevent. What the job can’t see is anything the vendor doesn’t expose. That’s why the Disabled global default stays behind it as the wall: a feature the sweep misses still waits for an administrator.
Step 3: Pin Claude Code’s new defaults in managed settings, not in the repo
Claude Code’s two September defaults have documented off switches, and one of them has a trap. The sync opt-outs are syncClaudeAiSkills: false and syncClaudeAiPlugins: false. Anthropic’s settings docs put them among the keys where a restrictive value wins from an unusual scope: “For a few keys whose values restrict a session, Claude Code honors a restrictive value from a scope that otherwise couldn’t override managed settings.” A false counts from any managed source, --settings, ~/.claude/settings.json or .claude/settings.local.json.
A false in a committed project .claude/settings.json is ignored. So a repo can’t opt its team out. The pull request that adds the key to the project file passes review, merges and changes nothing. Put the keys in managed settings, where the weekly job reads them.
The keys below are documented; collecting them in one managed file is our illustration.
{
"syncClaudeAiSkills": false,
"syncClaudeAiPlugins": false,
"permissions": {
"defaultMode": "default"
},
"disableAutoMode": "disable"
}
Either of the last two keys handles auto mode. permissions.defaultMode still overrides the new starting mode, and a settings file with disableAutoMode: "disable" switches auto off, so sessions start in default. Pick one on purpose and record which. Claude Code shows a one-time notice the first time the built-in default starts a session in auto mode, and a notice isn’t a decision.
Two more fields belong in the snapshot:
- The channel. npm’s
stabletag moved from 2.1.274 to 2.1.277 on Sep 28, which brought the sync to stable lanes but not the auto-mode start. Each default reaches stable lanes the day stable reaches its version, not the day you read this. Version drift across lanes is a canary problem. Here it means the probe session runs once per channel you ship. - The wall. A managed file can fail to reach a laptop. If it does, the session falls back to the new default, and the only thing left standing is whatever deny rules that machine enforces. That’s why permissions nobody can override sit under this sweep, not beside it.
Step 4: When a notice says “single policy” or “enabled by default”, snapshot before and diff after
A weekly job catches drift. A notice hands you a date, so use it. Watch vendor changelogs for these phrases: “single policy”, “enabled by default”, “automatically enabled”, syncing, and any retention period that changes.
For each notice:
- Snapshot the day it lands. The Aug 28 notice’s “before” is separate policies and 28-day chat retention. If you didn’t snapshot on Aug 28, snapshot today; the launch hadn’t been announced when we checked on Sep 28.
- Diff the day after the date. A firm date, like Oct 19 or Oct 22, gets one diff. A “no earlier than” date gets a daily diff until the changelog post appears, then one more the day after.
- Re-decide what changed. A diff line with no owner goes to the intake rule in step 5.
- File retention changes in the evidence register. Record the source URL, the date, the old and new values, the data classes affected, and what the notice leaves out. The Aug 28 notice doesn’t say whether life-of-account retention applies to chats created before launch, so that line reads “not documented” until GitHub says otherwise. Retention you signed up for is a boundary question. This register tracks retention that moves under you.
Here is the month on one axis, so the diffs land on the right mornings.
Dates from GitHub’s changelog and docs, and npm publish times for Claude Code. All read Sep 28, 2026.
Step 5: Adopt the default-on intake rule: owner, decision, date
Everything above reduces to one rule you can hand a new admin. Any vendor feature that turns on, syncs or auto-enables gets an owner, a decision and a date. Nothing leaves intake without all three.
The table maps this month’s notices to the rule. Owners and due dates are illustrative; triggers and vendor dates are sourced.
| Trigger in the notice | Example (vendor, date) | Owner | Decision to record | Due |
|---|---|---|---|---|
| Unconfigured follows a global default | GitHub, Sep 24; takes effect Oct 22 | Platform lead | Global default, plus every Unconfigured row | Before Oct 22 |
| “enabled by default after launch” | GitHub, Aug 28; no earlier than Sep 28 | Privacy | Keep, or opt out and lose Copilot on github.com | Launch day |
| Retention change | GitHub, Aug 28: 28 days to life of the account | Privacy | Accept, restrict, or take it to the contract | Launch day |
| Replacements “automatically enabled” | GitHub, Sep 18; retirements Oct 19 | Platform lead | Each replacement model, explicitly | Oct 18 |
| New effort default | GitHub, Aug 28: Default means Balanced |
AppSec | Lite or Balanced, set explicitly | This week |
| Account content syncs into sessions | Claude Code v2.1.275, Sep 17 | Platform lead | Managed sync keys | Now: stable passed 2.1.275 on Sep 28 |
| New starting permission mode | Claude Code v2.1.283, Sep 25 | Platform lead | permissions.defaultMode or disableAutoMode |
Before stable reaches 2.1.283 |
Three decisions need more room than a table row. Which models may become defaults at all is model-default promotion, where Claude Code’s new deniedModels and availableModelsMatch keys live. MCP traffic that never waited for a toggle is shadow MCP. And a default that changes what someone can approve from a phone belongs in the remote-approval policy.
How a default slips past the toggle sweep, and the signal for each
| Failure | Signal | First move |
|---|---|---|
| The enterprise delegates, and an org owner never opens the page | That org’s banner count stays above zero | Put the org owner on the sweep, or take the delegation back |
The sync opt-out lands in a committed .claude/settings.json |
The probe session still lists claude.ai skills | Move both keys to managed settings |
| Stable reaches 2.1.283 overnight | The probe session opens in auto mode; the version column changes | Confirm the managed mode key reached every machine |
| A default changes with no changelog post | The probe PR’s review effort moves while the feed stays quiet | Trust the probe, file the change, decide it |
| Replacement models switch on Oct 19 | New rows in the probe seat’s model list | Decide each replacement explicitly |
| The sweep itself stops | No snapshot for the week | Page the owner; a missing week counts as a failed week |
Every signal in that table comes from your probe or your snapshot, never from the vendor. Vendors announce defaults. They don’t page you when one flips.
A vendor default is a fleet setting, so it gets fleet paperwork
An operating layer keeps one inventory row per lane: its owner, its reach, its cost and its kill switch. An agent admin toggle sets that row for a whole class of agents at once, which makes it the row with the widest reach in the inventory, and usually the least watched. Anthropic’s new starting mode is the plainest case. Claude Code permission modes are fleet policy, and on v2.1.283 the vendor picks yours unless you pick first.
The snapshot pays off on bad days too. When a review bot starts running commands or a session opens in a mode nobody chose, the first question is what changed and when. A dated diff answers that in a minute. Without one, you’re rebuilding a vendor’s month from changelog posts.
FAQ
What happens to unconfigured Copilot features on October 22?
GitHub’s docs say the new default policy is enabled by default, so if you take no action, unconfigured features will be enabled on October 22. Explicit choices are preserved, and preview features stay opt-in. Set the global default to Disabled and configure each Unconfigured row before then.
Can a repo turn off Claude Code’s claude.ai skill sync?
No. Anthropic’s settings docs say a false for syncClaudeAiSkills or syncClaudeAiPlugins in a committed project .claude/settings.json is ignored. It counts from managed settings, the --settings flag, ~/.claude/settings.json or .claude/settings.local.json. For a team-wide opt-out, set both keys in managed settings and verify with a probe session.
Is Claude Code auto mode on by default now?
From v2.1.283, Anthropic’s permission-modes docs make auto mode the built-in starting mode for interactive terminal and VS Code sessions. claude -p and the Agent SDK still start in default. Override it with permissions.defaultMode, or set disableAutoMode to disable. On the evening of Sep 28, npm’s stable channel was 2.1.277, short of 2.1.283.
Sources
- GitHub changelog, Sep 24, 2026: default enablement of Copilot features for Business and Enterprise — the global default policy, effective Oct 22
- GitHub Docs: about default availability of Copilot features and models — “enabled by default”, the banner count, exceptions and the models policy
- GitHub changelog, Aug 28, 2026: upcoming changes to Copilot policies and billing — single policy no earlier than Sep 28, life-of-account chat retention, Balanced review effort
- GitHub changelog, Sep 18, 2026: upcoming deprecation of selected Copilot models — six retirements on Oct 19, replacements enabled automatically
- GitHub changelog, Sep 28, 2026: Claude Sonnet 5.5 in GitHub Copilot — a new model enabled automatically under default model enablement
- GitHub changelog index — last checked Sep 28 at 20:47 UTC; no post on the single policy or the Balanced switch
- Claude Code CHANGELOG — the v2.1.273, v2.1.275 and v2.1.283 entries
- npm: @anthropic-ai/claude-code versions — release dates, and the
stabletag: 2.1.274 earlier on Sep 28, 2.1.277 by evening - Claude Code docs: permission modes — auto mode as the built-in starting mode from v2.1.283
- Claude Code docs: settings — where a
falsefor the sync keys is honored, and where it’s ignored
