Copilot for JetBrains October update: default models and MCP startup controls

What the announcement establishes

The complete October 10 GitHub announcement describes enterprise defaults for new conversations while preserving explicit model choice, a setting to disable automatic MCP startup for Copilot and Claude, and an IDE requirement of 2025.2 or later after support for 2025.1 ended.

These affect different layers. The model default concerns a session’s starting point; startup control concerns when a configured service becomes active; the IDE requirement concerns support. Their appearance in one announcement does not turn them into a single automatic safety configuration.

Plan an upgrade for a small team

Consider this fictional adoption case. Team A still has a 2025.1 IDE, while Team B uses 2025.2; both have MCP configured. A must resolve IDE compatibility before evaluating the plugin. B can begin a pilot in a supported environment. B’s successful experience does not replace A’s version check.

Editorial advice: choose a recoverable sample project and record IDE, plugin, account, default model and configured services. After updating, inspect the default in a new conversation, explicitly select a model and record the actual state. Disable automatic startup, re-enter the session and observe the service state. If unclear, consult current settings and logs rather than guessing hidden paths or setting names.

A Fix proposal still needs repair evidence

The announcement also describes a diagnostic Fix action opening inline chat, with agent mode when available and ask mode otherwise. That establishes an entry point and fallback, rather than proving that selecting it fixes the problem.

Editorial advice: retain the original diagnostic, file location and reproduction condition. Inspect the proposed diff and its scope, then run a relevant check. An explanation is a suggestion; an actual file change is a modification awaiting acceptance. Saving a file, clearing a diagnostic and producing correct behavior are different pieces of evidence.

Material supplied to AI can contain text that resembles instructions. The document instruction and task-boundary guide helps separate information from authorization. Avoid widening service access simply to make a demonstration pass.

Keep dates separate from observed environment state

Model choice, tools and resource access are separate layers. The Windows agent-boundary article explains containment concepts; it does not establish identical automatic containment for every JetBrains session.

Inspect a new conversation, not an old thread, for the default

The announcement scopes the managed default to the starting model in new conversations while preserving explicit model choice. In an invented adoption case, a developer keeps Monday’s thread, an administrator changes the default on Tuesday, and the developer continues the old thread on Wednesday. Seeing something other than the expected new starting model does not alone prove the setting failed: that observation did not test the announced new-conversation condition.

Record the old thread separately, start a new conversation and inspect its initial selection, then explicitly choose an available model in the same supported environment. These observations answer different questions about the default starting point and the current explicit choice; they do not require every existing thread to be rewritten. If the new conversation differs from approved configuration, investigate the account, plugin, IDE and managed settings before changing organization-wide model permissions to chase a default.

Keep MCP separate too. Disabling automatic startup changes activation timing, not whether previously held credentials were revoked. No tool activity in one new conversation describes that observation only. A task that needs tools still requires a check of when the service starts, what it accesses and whether its result stays within authorization. A correct model default plus no automatic startup does not establish safe code behavior.

A cleared diagnostic can still leave 2 × 40 equal to 42

This is an invented TypeScript acceptance case, not an observed Copilot response. A function accepts numeric quantity and unitPrice but incorrectly returns quantity + unitPrice. An unused currency variable produces a diagnostic. If a Fix proposal only removes that variable, the diagnostic may be addressed while quantity=2 and unitPrice=40 still return 42 instead of the required 80.

Identify the diagnostic being addressed, then verify actual task behavior. Removing an unused variable is not a repair of the amount calculation. If the requested repair concerns totals, inspect the multiplication rule and a zero-quantity case expected to return 0. A successful type check reports its own scope; it cannot establish that addition satisfies the business definition.

The announced agent/ask fallback matters for acceptance too: an explanation or proposed patch may leave the working copy unchanged. An actual edit provides a diff to review and behavior to run. Hand over the original diagnostic, change scope and results for 2×40 and zero quantity together. If a proposal spreads into unrelated files, narrow the repair before accepting it rather than merging everything because the interface says complete.

Keep unresolved adoption questions visible

This article does not report a trial in your tenant or measure speed or defect reductions. Confirm unspecified model lists, exact setting names, regional availability and organizational rules in the current interface and administrator configuration. A news article cannot substitute for that evidence.

Older projects may also depend on SDKs, build plugins and test environments. Meeting the Copilot IDE requirement does not establish compatibility for all project dependencies. Retain the original configuration and upgrade record so another person can review the result.