On 18 August, GitHub gave Copilot for JetBrains the same managed-settings controls that VS Code has had: plugin governance, MCP allowlists, OpenTelemetry configuration, and a switch to disable Bypass Approvals and Autopilot. If your organisation runs a mixed editor environment, this closed a real gap — but a closed gap is not the same as a verified one.
This is the order to check it in, rather than a general reminder that the feature exists.
First: confirm the setting actually applies to your IDE
GitHub's announcement refers to "JetBrains IDEs" generically without naming which ones. Before doing anything else, confirm the managed-settings file is actually being read by the specific IDE your team runs — IntelliJ, PyCharm, WebStorm, or whichever it is — rather than assuming the general statement covers your case.
Second: re-check memory and Ollama from 11 August
Copilot memory and Ollama as a BYOK provider landed in JetBrains on 11 August, a full week before there was any way to govern either one centrally. If you audited permissions after that release and found nothing configurable, that was accurate at the time and is now out of date.
Specifically worth checking: whether memory is enabled by default for your organisation, what its scope is now that it is configurable, and whether Ollama as a local-model provider is something you want available by default or something that should require opting in per developer.
Third: match your VS Code plugin policy rather than starting fresh
If you already set enabledPlugins, extraKnownMarketplaces or strictKnownMarketplaces for VS Code, the same values should extend to JetBrains rather than being independently re-derived. A different plugin policy per editor is not a deliberate security decision for most organisations — it is an artefact of one editor getting governance controls seven weeks before the other.
Fourth: the MCP allowlist should not need re-inventing
The same is true of allowedMcpServers and deniedMcpServers. If your organisation already did the harder work of inventorying which MCP servers are actually running — the genuinely time-consuming part of any allowlist — that inventory applies here too. Extend the existing list to cover JetBrains rather than starting the inventory over.
Fifth: bypass permissions deserves its own decision
permissions.disableBypassPermissionsMode is the one control on this list that is not about what an agent can reach, but about whether it can act without per-step confirmation at all. If your organisation has a stated position on unattended agent actions in VS Code, check explicitly whether that position was ever meant to extend to JetBrains, or whether it simply never came up because there was no lever to pull there until now.
What "done" looks like
Not a new policy document — a short confirmation that the policy you already have now genuinely covers every editor your developers use, rather than the editor that happened to get the control first. If your team runs both VS Code and JetBrains, the honest test is: could you currently point to the exact same managed-settings values applying to both? If the answer is no, that is the one action item this release actually creates.