GitHub Copilot 默认策略执行至 10 月 26 日：团队需检查什么

On October 22 GitHub started enforcing the global default policy for generally available Copilot features. The rollout runs through October 26 and lands at different times for different enterprises and organizations. Anything eligible that your org never explicitly configured gets set to whatever that default says. For a lot of teams this means features switching on, or off, with nobody clicking anything. This is the kind of change that turns into a mystery incident three weeks later: an agent suddenly reaches a tool it could not reach on Monday, and nobody remembers authorizing it. So I read the changelog entries on both deadlines, and this is the short version for anyone running Copilot for a team. What started on October 22 GitHub announced the global default policy in September, covering generally available Copilot features and supported client capabilities on Copilot Business and Enterprise plans. Enforcement is the new part. From the October 22 changelog entry: Starting today, we're gradually rolling out enforcement of the policy through October 26, so it may take effect at different times for different enterprises and organizations. Eligible features left unconfigured will be set according to the global policy. Three default positions exist: Enabled, Disabled, and Let organizations decide. Whatever yours says is the value the rollout writes onto unconfigured rows. With Let organizations decide, each organization's own default takes over for its unconfigured features. What actually gets flipped The policy applies to eligible settings on two surfaces: Features & clients, the main list of GA capabilities MCP servers in Copilot The second one is why this matters more than a normal admin-checkbox story. The MCP server surface is the tool surface your Copilot agents can reach. If a capability there ships as generally available and eligible, and your org never made a choice about it, the default policy makes the choice instead. No PR, no diff, nothing your repository sees. What survives untouched The design is narrower than the headline suggests, which is good: Explicit choices are preserved. If you enabled or disabled a feature individually, the rollout does not touch it. Preview features remain opt-in. If you opted into a preview that later became GA, your choice is kept. The flip is one-time. Later changes to the default policy will not rewrite feature policies that are already set. So the rollout only takes choices nobody made. The catch is that "nobody made a choice" is the default posture toward every feature that shipped while the team was not reading the changelog. Where to look, exactly Enterprise and organization owners: AI Controls → Copilot → Default policy for new features. That page shows the current default position. The entry's own screenshot shows the Features and clients page with the default policy set to Enabled and the October 22 banner already up. Then open Features & clients and read down the list. Every row still marked Unconfigured is a row this rollout will set. If your rows still say Unconfigured today, the flip may simply not have reached your org yet; the window runs through October 26. The audit is ten minutes: 1. AI Controls → Copilot → Default policy for new features read the default: Enabled / Disabled / Let organizations decide 2. Features & clients list every row marked Unconfigured 3. MCP servers in Copilot same: list every Unconfigured row 4. For each row you care about, set it explicitly before October 26 explicit choices survive later default-policy changes 5. Save a copy of the final state somewhere outside the admin UI Enter fullscreen mode Exit fullscreen mode Step 5 is the one people skip. The admin UI is a config file you cannot diff. Why this is an agent-config event If you pin agent behavior in config files, and you should, platform-side feature policy just became part of that config. It simply lives in an admin UI instead of a repository. Tool availability for your agents can now change on a schedule you did not pick, which is ordinary config drift with a vendor signature. I wrote about catching that class of drift in your own files before it bites: Your AGENTS.md is lying: how configs drift and how to catch it. The practical rule: anything that changes what tools your agents can call belongs in your config review, wherever the setting physically lives. The second timer: November 16 The same defaults machinery has a second deadline running. On November 16, 2026, three models leave every Copilot experience (chat, inline edits, ask and agent modes, completions), per the deprecation notice: Model Suggested alternative Claude Opus 4.8 Claude Opus 5.5 Claude Opus 5 Claude Opus 5.5 GPT-5.6 Terra GPT-6.1 Sol or GPT-6 Luna Claude Opus 4.8 stays available for individual Copilot subscribers on annual plans. Under default model enablement, the alternatives are automatically enabled for Business and Enterprise unless an administrator turned off the global default or disabled the model. If you did turn the default off, you enable the replacements through model policies in Copilot settings. Until you do, workflows pinned to an outgoing model break on a date you did not schedule. If your team standardized prompts on one of the outgoing models, that is a config migration with a deadline. Which surface decides what actually runs your agents is a question I walked in detail when Haiku 5.5 went GA: Claude Haiku 5.5 is GA in GitHub Copilot: 4 config surfaces decide what runs your subagents. Defaults are still decisions Nothing here is hostile. Default policies are a reasonable answer to feature sprawl, and preserving explicit choices is the right behavior. The part to internalize is smaller: a default applied to an unconfigured setting is still a decision about your agents, recorded nowhere in your repository. Treat admin-UI policy like any other config. Read it before the deadline, write down what it says, and review it when the changelog moves. The October 26 window is a good excuse to start.