Copilot’s JetBrains update puts the controls up front

A clearer starting point

GitHub’s 10 October update to Copilot for JetBrains puts two useful choices closer to the surface: the model a conversation starts with and when connected tools become active. There is also a compatibility change to check first. GitHub says the plugin now needs a JetBrains IDE from version 2025.2 onwards; support for 2025.1 has ended. [1]

Our reading is that these are useful housekeeping changes. A coding assistant is easier to work with when its starting conditions are understood. Before asking it to change a project, a developer should be able to explain which model is answering and which tools have been made available. That is a sensible place to begin an evaluation.

A default still leaves room for a choice

Enterprise administrators can now select an available Copilot agent model as the starting default for new conversations. GitHub says an explicit model-picker selection is preserved. [1]

For a South African development team considering the update, we would make the default a documented starting point. Choose a small, repeatable task, review the proposed changes and decide whether another model is worth trying. The helpful comparison is the resulting work: can somebody explain it, test it and maintain it? The announcement alone cannot answer those questions.

Decide when tools should start

A new setting lets users disable automatic MCP server startup for Copilot and Claude, according to GitHub. MCP is a way of connecting an assistant to tools. [1]

We would treat that switch as an opportunity to make a workspace easier to understand. Keep a short inventory of each connected tool and the task it is there to perform. Deliberately deciding when a tool starts can make an unexpected connection easier to investigate. It should not be mistaken for evidence that every action an assistant proposes is appropriate; reviewing its work remains a separate job.

Check the setup before the workflow

GitHub’s general configuration guide points JetBrains users to Settings, then Tools and GitHub Copilot, where General and Completions preferences live. It also describes stable and nightly update channels. That guide is background documentation rather than an independently verified test of this release. [2]

Our suggested first run is deliberately modest: use a disposable copy of a project, write down the IDE and plugin versions, start one conversation and inspect the proposed edit before accepting it. Record what changed and whether the project’s normal checks still pass. This is an evaluation approach, not a report of our own hands-on trial or a guarantee that every team will see the same behaviour.

The useful outcome would be a setup that a colleague can reproduce without guessing. Clear defaults, understood tool connections and a small reviewed task provide a concrete basis for deciding whether to adopt the update more widely. We would start there before treating a longer feature list as proof of a better working day.

AI-assisted research, writing and a separate source-checking pass by the same Codex assistant. GitHub’s dated announcement supplies the release claims; GitHub Docs supplies general context. The two domains belong to the same company and are not independent corroboration. Suggested team evaluation steps are our interpretation. No hands-on plugin trial, performance measurement or local adoption claim.