GitHub Copilot for JetBrains adds model and MCP startup controls

The release separates three controls that teams should test separately

GitHub's October 10 Copilot for JetBrains release adds three changes with different consequences: an enterprise‑managed starting model for new conversations, a local setting that disables automatic MCP server startup, and a diagnostic Fix action that opens inline chat and asks Copilot to propose a repair. The same release also ends support for JetBrains IDE 2025.1, making 2025.2 or later the new minimum.

These controls solve different problems. The model setting standardizes where a conversation starts. The MCP switch changes when configured external tools become active. The Fix action reduces the steps between seeing a diagnostic and asking an agent to edit code. None of them, by itself, decides which models a member may use, which MCP servers are allowed, or whether a proposed change can be applied without review.

That distinction matters for rollout. A team can enable the new plugin and still have three separate acceptance failures: the selected model may be unavailable under organization policy, an allowed MCP server may expose more tools than intended, or an agent‑generated fix may change a wider boundary than the diagnostic suggested.

A managed default model is a starting point, not a model lock

GitHub says enterprise administrators can choose any available Copilot agent model as the default for new conversations while preserving the user's explicit model picker. Its enterprise managed‑settings reference describes the top‑level model key in managed‑settings.json: it can name a specific model or use auto, and it can be made overridable for selected enterprise teams.

The practical consequence is that a default does not establish an exclusive model boundary. GitHub's separate model‑access documentation says availability also depends on the plan, client and organization or enterprise policy. Admins who need a constrained model set must verify those availability policies as well as the starting selection delivered to JetBrains.

A clean acceptance test uses two new conversations. Confirm that the managed model appears first, then check whether the picker exposes only models the organization intended to permit. If teams receive overrides, repeat the test with one member inside and one outside the mapped team. Existing conversations are a separate state and should not be assumed to inherit the new default.

Stopping MCP auto‑start reduces ambient exposure but does not define trust

The new JetBrains MCP setting can disable automatic server startup for Copilot and Claude. That is useful when a developer has several configured servers but wants tools to remain dormant until a task needs them. It can reduce accidental launches and make startup behavior easier to inspect.

It is not an allowlist. GitHub's managed‑settings reference separately defines allowedMcpServers and deniedMcpServers; a server not matched by an allowlist is blocked, while a denied server remains blocked even if another rule would allow it. Teams should therefore treat startup timing and server authorization as two independent controls.

A practical test begins with auto‑start disabled. Open a clean IDE session and verify that no configured MCP process starts. Then deliberately start one approved server and confirm its identity, transport and exposed tools. Repeat with a server outside the enterprise allowlist and expect it to stay blocked. The OpenTools MCP directory can help identify candidate servers, but a listing is discovery evidence rather than permission or compatibility proof.

The diagnostic Fix action shortens the path to an agent‑made edit

Diagnostic intention menus now include a Fix action. GitHub says it opens inline chat and asks Copilot to repair the issue, using agent mode when available and ask mode otherwise. This turns a compiler, inspection or language‑server finding into an agent request without requiring the developer to restate the problem.

The shorter path increases the value of checking execution mode. Ask mode may return guidance, while agent mode can have a broader ability to inspect files and propose or make changes depending on the client's configured permissions. The diagnostic is context for the task, not proof that the suggested edit is correct or limited to one file.

For rollout, choose a harmless diagnostic with a known expected repair. Record which mode opens, inspect every changed file, run the relevant test, and verify that unrelated formatting or dependency files remain untouched. Teams should also test a diagnostic that cannot be fixed safely without a design decision; the desired outcome is a clear limitation or review point rather than a plausible but unsupported edit.

Upgrade order determines whether the new controls are observable

GitHub ended support for JetBrains IDE 2025.1 in this release and now requires 2025.2 or later. Its Copilot feature matrix also tracks capabilities by plugin version and recommends current stable IDE and extension releases. An administrator cannot validate the new settings reliably on an unsupported client.

The safest order is to inventory IDE and plugin versions, upgrade a small managed cohort, verify receipt of the enterprise settings, and then run the model, MCP and Fix tests independently. Preserve one control account without a team override so that a local success is not mistaken for enterprise‑wide policy delivery. If a setting fails, separate client‑version drift from policy propagation and server authorization before changing all three at once.

GitHub's update also improves account switching, chat navigation, browser authorization cancellation and reliability around model/provider changes, customizations, file changes and worktrees. Those are useful quality claims from the vendor, but the changelog publishes no incident rate or independent before‑and‑after measurement. Teams should use their own failed‑session and support‑ticket baseline before calling the release a reliability improvement. Follow GitHub's OpenTools organization page for related developer tools.

Figure: Three separate acceptance gates for the new JetBrains controls. Sources: GitHub's October 10 changelog, enterprise managed settings, model‑access controls and the Copilot feature matrix. Figure by OpenTools Team; no third‑party expressive material used.

Share this article

Related News

Tora lets AI apps read playbooks and unfinished meeting steps

CloudKeeper’s AI cost dashboard includes licences and GPU spending

Triskell SP2 adds MCP actions and provider-data exclusions

GitHub Copilot for JetBrains adds model and MCP startup controls

The release separates three controls that teams should test separately

A managed default model is a starting point, not a model lock

Stopping MCP auto‑start reduces ambient exposure but does not define trust

The diagnostic Fix action shortens the path to an agent‑made edit

Upgrade order determines whether the new controls are observable

Sources

Tags

GitHub Copilot for JetBrains adds model and MCP startup controls

The release separates three controls that teams should test separately

A managed default model is a starting point, not a model lock

Stopping MCP auto‑start reduces ambient exposure but does not define trust

The diagnostic Fix action shortens the path to an agent‑made edit

Upgrade order determines whether the new controls are observable

Sources

Tags