Copilot's default switch lands October 22. Decide what your reviewer turns on before it does.

On a small team, the code reviewer is usually one tired person plus whatever bot is switched on. This week GitHub gave Copilot Business and Enterprise customers a deadline for deciding what that bot is allowed to do. If you never set the policy, GitHub says unconfigured features will be enabled on October 22.

What changed

On September 24, GitHub announced a new “Default policy for new features” for Copilot Business and Enterprise. Admins pick one of three options:

• Enabled. Current and future eligible features are available by default.
• Disabled. Current eligible features stay unavailable, and future eligible features need an administrator to approve them.
• Let organizations decide. Organization administrators can choose whether to enable or disable eligible features.

You can set the policy before October 22, and until then GitHub says it does not change what your users can access. The policy takes effect on October 22. From then, in GitHub’s words, “Eligible generally available features and capabilities left Unconfigured will follow your selected global default of enabled, disabled, or let organizations decide.”

Three details matter:

1. Scope. The policy covers eligible generally available features on the enterprise “Features & clients” page, the Copilot Code Review policy on the “Agents” page, and the MCP servers in Copilot policy.
2. Explicit choices survive. If you already turned a feature on or off, GitHub says it will keep your choice.
3. Previews stay opt-in. Features in preview are not switched on by this policy. If you opt into a preview and it later becomes generally available, GitHub says it keeps that choice.

The changelog does not name the fallback. GitHub’s default-availability docs, linked from that changelog, do. The policy is enabled by default, and GitHub says, “If you don’t take action, unconfigured features will be enabled on October 22.”

Why a small team should care this week

The default decides whether an eligible, generally available feature is available. Features in preview stay opt-in.

On September 25, GitHub said agentic autofix now reads Copilot Memory when Memory is enabled. After it writes a fix, it saves the fix pattern as a memory. GitHub says those memories can teach Copilot code review and the Copilot cloud agent about secure development patterns unique to that repository. Both autofix and Memory are in public preview.

This is useful when the patterns are right. Nobody has to explain the same injection fix three times. It is a problem when a pattern is wrong. GitHub stores that fix pattern, and Copilot code review can draw on the same memory. If you are the only human reviewer, you are also the only check on what gets remembered.

GitHub’s September 25 weekly release is a separate changelog post, and it includes local sandboxing in the Copilot app, in public preview. It limits an agent’s access to files, networks and credentials. Together, these are three decisions a small team should make on purpose: what the reviewer checks, how you set the MCP servers policy, and what Memory keeps.

A rule for picking the default

For a team of one to ten engineers:

• Choose Disabled if you work in client repositories, handle regulated data, or cannot say today which MCP servers your developers connect. New features then arrive as a decision, not a surprise.
• Choose Enabled only if every repository is your own, you already review every bot comment before merging, and you would notice a new tool call in your logs.
• Choose Let organizations decide if you run separate organizations for client work and internal work. Keep client organizations strict and let the internal one move faster.

When in doubt, choose Disabled and turn features on one at a time. Turning something on later costs a click. If nobody chooses, GitHub says the unconfigured features will be enabled, and finding out what they did costs a review of every pull request since October 22.

The 20-minute audit

Run this once before October 22:

1. Open AI Controls → Copilot and write down every eligible feature still marked Unconfigured. On October 22 that list follows the global default you selected, or Enabled if you never select one. A feature you already turned on or off stays that way.
2. On the Agents page, set the Copilot Code Review policy yourself. Whatever you choose, it will then count as an explicit choice.
3. Set the MCP servers in Copilot policy explicitly. If it stays on, list the servers you allow and who owns each one.
4. Check who has Copilot Memory turned on. It is enabled per user, not per repository. On individual plans it is on by default. On Business and Enterprise plans, an administrator has to enable the policy first, and then individual users can opt out. Once it is on for a user, it applies in any repository where that user works with Copilot. Repository owners can review and manually delete the repository-level facts stored for that repository.
5. Pick the global default using the rule above, and record the reason in your repository’s contributing notes, so the next person knows it was a decision.

Then run one check on a scratch repository. Open a pull request that brings back a bug you have fixed before, and see what the reviewer says. If it misses the bug or suggests the old fix, you know how much weight its comments can carry.

What to do this week

• List every eligible Copilot feature marked Unconfigured and set each one explicitly.
• Set the code review and MCP server policies by hand, not by default.
• Decide whether Copilot Memory is on for your users, and write the decision down. It follows each user into any repository where they work with Copilot.
• Try local sandboxing on one agent session that touches credentials.
• Choose before October 22, the day the policy takes effect.

The setting takes a few minutes. Deciding what your reviewer is allowed to learn is harder, and it is the kind of question we work through with teams in a consult block.