GitHub lets enterprises set Copilot's default model in JetBrains IDEs. A default is not a policy

Most people never change a default. That is why defaults are powerful, and why they are easy to mistake for controls.

GitHub’s October 10 update to Copilot for JetBrains IDEs adds two settings enterprise administrators will notice. Through managed settings, they can now “choose any available Copilot agent model as the default for new conversations.” And a new setting “lets you disable automatic server startup for Copilot and Claude,” meaning MCP servers no longer have to launch the moment the IDE does. The release also adds a Fix action that sends IDE diagnostics to Copilot, reliability work across sessions, worktrees and model switching, and a requirement: JetBrains IDE 2025.2 or later, as support for 2025.1 has ended.

What a default model does

A default steers. If most developers keep the model a new conversation starts with, the enterprise default decides most of the spend and most of the behavior across thousands of sessions. Picking an efficient model as the starting point, with the frontier model one click away, is a sensible cost lever, the same logic we applied to paying for speed only where someone is waiting.

But GitHub is explicit that a user’s explicit choice in the model picker is preserved. The default sets where people start, not where they may go. Restricting which models are available at all is a separate decision, made through the organization’s Copilot model policies. Treating the new default as a restriction would leave a gap between what the administrator believes and what developers can do.

What MCP auto-start does

The MCP setting is similar. Turning off automatic startup changes when configured MCP servers launch: on demand rather than with the IDE. That reduces the number of tool connections running in the background on every developer machine, which is good hygiene. It does not decide which MCP servers are allowed, what they can access or what credentials they hold. The changelog also does not say whether the setting is managed centrally or chosen by each developer.

The questions that govern MCP risk remain where they were: which servers are permitted, under whose identity they act and where their traffic is logged, the gap we described in MCP connectivity without MCP governance.

Use both, label them correctly

None of this diminishes the update. Coding-agent governance is moving into the IDE, where developers actually work, and these settings make a consistent baseline easier to set across a fleet. The discipline is in the labels:

• Defaults set the starting point: which model, which servers launch. They shape cost and consistency.
• Policies set the boundary: which models and tools are permitted at all. They are what an auditor will ask about.
• Versions set the floor: an IDE fleet still on 2025.1 has just lost plugin support, which is its own risk.

Write down which of your Copilot controls are defaults and which are policies. If the list of policies is short, the default model is not a control. It is a suggestion most people will accept.