GitHub let JetBrains admins choose the default model. MCP finally got an off switch

THE SIGNAL IN ONE SENTENCE

A default is a suggestion wearing an administrator badge. GitHub's October 10 update to Copilot for JetBrains gives enterprise administrators a way to choose the default agent model for new conversations. Developers still keep an explicit model picker. The same release adds a setting that can stop configured MCP servers from starting automatically for Copilot and Claude, plus a diagnostic Fix action that opens inline chat and asks the assistant to propose a repair. None of those changes is enormous by itself. Together they expose the real shape of enterprise coding assistants. The model is one control. The tool servers are another. The permissions carried by those servers are a third. The person who reviews the resulting code is a fourth. Software teams get into trouble when one knob is mistaken for the whole control panel. Start with the model default. GitHub's enterprise-managed settings documentation says the top-level model key sets the preferred model for new conversations. It can point to auto selection or to a specific available model and version. The setting can also be made overridable for particular enterprise teams. That is useful administration. It can reduce random starting choices, align a team with an evaluated model and make support less chaotic. A company can tell developers, in effect, this is the model we have tested for ordinary work. But GitHub deliberately preserves the user's model picker. The default is not a lock. That distinction belongs in every rollout document. If a security review approves one model for a sensitive repository, setting it as the default does not prove that every conversation used it. If a finance team budgets around one model's cost, a user override may change the economics. If a benchmark supports one language or task, another model may still be better for a particular job. The control should be described honestly: a starting position with a visible escape hatch. That can be the right design. Developers need room to choose a stronger model for a difficult migration or a faster one for routine questions. Central governance does not need to flatten every task into one answer. It does need to record what actually ran. A useful audit entry would capture the selected model, how it was chosen, whether the user changed it, which repository and policy applied, which tools were available and what files or systems were touched. Otherwise an administrator can point to a default while the incident record points somewhere else. The MCP startup control is the more interesting change. Model Context Protocol servers can expose tools and data sources to an assistant. GitHub's own MCP server can work with repositories, issues and pull requests from Copilot Chat. Other configured servers may reach databases, internal documentation, cloud systems, ticketing tools or local services. The value is obvious: the assistant can do more than autocomplete a sentence. So is the hazard. A server that starts automatically may create a live connection before the developer intends to use it. The server may load tool definitions, authenticate, consume local resources, expose a listening process or make sensitive capabilities available to an agent session. Turning off automatic startup reduces that background activation. It is a good off switch. It is not the same thing as disabling MCP across the company. GitHub's enterprise documentation describes a separate MCP servers in Copilot policy that determines whether MCP servers can run across Copilot clients. GitHub recommends keeping the policy enabled when appropriate and restricting servers through an approved list. It says a managed settings file provides stronger enforcement than relying on a custom registry alone. The new JetBrains switch lives lower in the stack. It controls whether configured servers start automatically in that client. An enterprise policy controls whether MCP may run. An allowlist controls which servers are approved. Server credentials control what each server can reach. Tool-level approval determines which action may proceed. Those layers should not be compressed into one reassuring checkbox. A parked server is quieter. Once someone starts it, the old questions return. Which process launches? Which binary or container version? Who published it? Which network destinations can it reach? Which token does it receive? What scopes does that token carry? Can the server write to a repository, create an issue, merge a pull request, query production data or call another service? Does a developer see the exact action before it runs? Are requests and results logged? Can the organization revoke the server without waiting for every laptop to update? The least exciting answer is usually the right one: start nothing until it is needed, authorize only the required server, issue a narrow credential, expose the smallest useful tool set and ask again before consequential writes. GitHub's own JetBrains documentation makes the action boundary visible. In agent mode, developers can inspect the available tools exposed by the GitHub MCP server and may be asked for additional permissions or information before an action completes. That is better than invisible capability. It still depends on the quality of the permission prompt and the time a person has to understand it. An approval dialog that says use tool is not enough. The reviewer should see the server, action, destination, affected repository or system, data leaving the editor and whether the change is reversible. Repeated low-information prompts train people to approve by reflex. The diagnostic Fix action deserves the same restraint. GitHub says a diagnostic intention menu can now open inline chat and ask Copilot to repair the reported issue. It uses agent mode when available and ask mode otherwise. That removes several clicks between seeing a warning and getting a proposed fix. Fewer clicks are not evidence of a correct repair. A compiler error, linter warning or language-server diagnostic can be precise. The surrounding intent may not be. A change that removes the warning can alter behavior, weaken a test, hide an exception or silence the rule instead of fixing the cause. The assistant should present a diff, cite the triggering diagnostic, explain which files it changed and run the narrowest relevant checks. A developer should be able to reject the repair without losing the original context. The word proposed matters. GitHub's changelog describes a proposed fix, not a guaranteed one. The release also bundles reliability and interface improvements. GitHub says it improved language-server startup, model and provider switching, MCP configuration, customization refreshes, file changes and worktree workflows. It also changed account labels, chat navigation, message actions and sign-in behavior. Those are vendor descriptions, not published performance measurements. The announcement does not provide crash rates, repair accuracy, latency comparisons, security tests, adoption numbers or controlled productivity results. Teams should verify the behaviors in their own repositories before treating the release note as an outcome report. There is also a blunt compatibility change. Copilot no longer supports JetBrains IDE 2025.1. The plugin now requires version 2025.2 or later. That makes rollout an inventory problem before it becomes an AI problem. Find every supported JetBrains product in use. Record the IDE version, Copilot plugin version, operating system, managed-settings delivery method, available models, configured MCP servers and repository sensitivity. Upgrade a pilot group first. Confirm that settings arrive, defaults behave as documented, user overrides remain visible, automatic startup stays disabled when requested and the diagnostic flow produces reviewable changes. Then test failure. Disconnect the network when managed settings refresh. Remove a model from the allowed set. Give a team an override. Configure an MCP server that should be blocked. Start an approved server with an expired token. Ask a read-only tool to perform a write. Switch accounts. Open a worktree. Trigger a diagnostic in code with a hidden test. Confirm what the product does and what the audit trail remembers. GitHub documents server-managed settings through a private enterprise repository. It also notes that not every supported client implements every property. That caveat should sit beside any fleet-wide promise. The same JSON file can travel to multiple clients while individual keys behave differently or arrive on different release schedules. For the model default, measure actual use rather than policy intent. How often do developers keep the default? Which teams override it? Do overrides correlate with task type, latency, quality or cost? Does a selected model perform consistently across Java, Kotlin, Python, database work and Android projects? For MCP, measure activation and authority. Which servers start, who starts them, which tools are called, which permissions are requested, how often people decline and which actions change an external system? A server count is not a risk measure. One narrowly scoped documentation server may matter less than one broadly credentialed production tool. For diagnostic fixes, measure accepted repairs, test results, reverted changes and defects that escape later. Time from warning to diff is helpful. Time from warning to verified repair is the metric that counts. The plain signal is that GitHub has added useful control surfaces, not finished governance. The enterprise can choose where a conversation begins. The developer can still choose another model. The client can keep MCP servers asleep until needed. The organization can separately decide whether MCP is allowed and which servers belong on the list. Credentials and approvals still decide what a running server may do. Review still decides whether proposed code belongs in the repository. That is a healthy separation. Defaults guide behavior. Gates limit capability. Logs reveal what happened. Tests decide whether the code works. No single toggle gets to impersonate all four.