Skip to content

Locale en · ko

Don't Leave JetBrains Outside the Policy — Copilot Enterprise Managed Settings

By PapaCoder · Published 27 Aug 2026 · Updated 24 Aug 2026

Summary

GitHub Copilot for JetBrains now honors enterprise managed settings (2026-08-18). Close the IntelliJ gap for MCP allowlists, plugins, OpenTelemetry, and Bypass/Autopilot.

Don't Leave JetBrains Outside the Policy — Copilot Enterprise Managed Settings

On 18 August 2026, GitHub announced that GitHub Copilot for JetBrains now honors enterprise managed settings for plugin governance, MCP server access, OpenTelemetry, and permission modes (Bypass Approvals / Autopilot).

Core takeaway: If you locked down VS Code and the CLI but left IntelliJ as “developer preference,” your Copilot agent policy already had a hole. JetBrains can finally sit on the same control plane.

Why it matters

Agent surfaces have been expanding faster than admin surfaces. Agent Plugins 1.0 made plugins portable across clients. Slack and Teams let @GitHub steer cloud agents from chat. Many enterprises polished managed-settings.json for VS Code and deferred JetBrains because the docs used to read like a VS Code story.

That deferral is not a niche exception. The same GitHub identity and Copilot seat can behave differently when the IDE changes. An MCP server allowed only “by accident” in IntelliJ, or Autopilot left on because nobody could flip a central switch, quietly undoes the guardrails you paid to design for VS Code.

The 18 August release closes that asymmetry for four concrete controls: plugins and marketplaces (enabledPlugins, extraKnownMarketplaces, strictKnownMarketplaces), MCP (allowedMcpServers, deniedMcpServers), managed OpenTelemetry, and permissions.disableBypassPermissionsMode.

How it compares

AxisBefore (JetBrains gap)After 2026-08-18
MCPAllowlists on other clients; JetBrains softSame allow/deny keys on JetBrains
PluginsPortable plugins without JetBrains marketplace teethEnable/disable + marketplace restrictions
Permission modesBypass/Autopilot often per-developerOrg-enforced disable
DeliveryServer / MDM / file mature elsewhereJetBrains joins the same plane

The lesson matches what Cursor teams already learn with MCP allowlists and Run Mode: certification and policy reduce residual risk; they do not remove the need to inventory every client. Claude Code’s folder trust and credential stripping are a different layer (runtime). Managed settings are the admin distribution layer. You want both.

I first treated the changelog as a paperwork update. Then we counted seats: IntelliJ and WebStorm were a non-trivial slice of Copilot usage, and our VS Code-only rollout checklist had no JetBrains column. That is when the work became “fleet,” not “IDE preference.”

Code / config example

A minimal enterprise baseline (typically copilot/managed-settings.json in a .github-private repo). Replace matchers with your org standards.

{
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  },
  "allowedMcpServers": [
    { "serverUrl": "https://api.githubcopilot.com/*" },
    { "serverCommand": ["npx", "@playwright/mcp@latest"] }
  ],
  "deniedMcpServers": [
    {
      "serverCommand": [
        "npx",
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/"
      ]
    }
  ],
  "enabledPlugins": {},
  "extraKnownMarketplaces": {},
  "strictKnownMarketplaces": true
}

Operational details that matter:

  • An allowlist means unmatched servers are blocked.
  • A deny entry is unconditional — it still wins if the server also matches the allowlist.
  • Malformed JSON is treated as an empty allowedMcpServers list, which fail-closes toward blocking non-default servers. Broken edits can lock the floor.
  • enabledPlugins / extraKnownMarketplaces can be additive via team files; MCP and Bypass keys can be marked { "overridable": ... } for deliberate team specialization.

Delivery channels are commonly ordered MDM → server-managed → file-based → user. Server-managed is the default for audit history and reaches cloud agent; MDM/file keep device policy even before sign-in or across account switches.

Practical use

  1. Inventory the fleet. If JetBrains Copilot usage is non-zero, it is in scope now.
  2. Reuse the MCP page you already have. Copy allow/deny matchers from VS Code into the shared schema, then verify in IntelliJ.
  3. Kill Bypass/Autopilot early. permissions.disableBypassPermissionsMode: "disable" turns off the YOLO switch; it does not define every tool approval.
  4. Pin OpenTelemetry. Managed values override developer settings. Devs can inspect applied config under Settings → Tools → GitHub Copilot → Chat → OpenTelemetry.
  5. Pilot file-based where server round-trips are awkward (containers, Codespaces): well-known paths, root-owned, not world-writable.
  6. Rehearse broken JSON in staging so on-call knows the fail-closed symptom and rollback.

Senior-engineer perspective

The recurring failure mode is locking the loudest IDE first. VS Code gets the long runbook; JetBrains gets a footnote — and incidents love footnotes.

Also: do not write “security complete” next to disableBypassPermissionsMode. That is one of four boxes — plugins, MCP, OTel, permission modes. Portable plugins make marketplace governance more urgent, not less.

Keep overridable narrow. If every team can reopen Bypass or widen MCP, you rebuilt the JetBrains exception with extra steps. Default locked; exceptions ticketed with expiry.

Using it in Cursor

Even Cursor-only teams should steal the checklist:

  • Version-control MCP allowlists and Run Mode with the same seriousness as managed-settings.json.
  • Dual-stack orgs (Cursor + Copilot on JetBrains) should define the intersection of allowed MCP servers first, then encode it in each product’s syntax. “Blocked only in Cursor” is just risk relocation.
  • Put “latest JetBrains Copilot plugin + managed settings applied” in acceptance criteria when an agent drafts policy changes. Changelogs do not patch fleets.

FAQ

Q. Can we reuse the VS Code managed-settings file as-is?
A. Shared keys (MCP, Bypass, etc.) use the same logical schema. Still verify the JetBrains-scoped controls from the 18 August changelog, upgrade the plugin, and confirm applied values in the IDE.

Q. Is an allowlist enough?
A. An allowlist blocks non-matches. Explicitly deny dangerous patterns (for example root filesystem MCP). Deny wins over allow when both match.

Q. Does disabling Bypass replace tool policy?
A. No. It prevents Bypass Approvals or Autopilot. Per-action approvals remain a separate design.

Q. Server-managed or MDM?
A. Prefer server-managed for audit and cloud agent coverage. Use MDM for device-group enforcement before sign-in; use file-based for containers and similar.

Sources

Closing

In the agent era, IDE policy means every client that burns a seat, not the editor your runbook mentions first. On 18 August, JetBrains joined that list officially. Next step: prove managed settings on one IntelliJ machine — not another summary of the changelog.

Portable plugins and chat-native agents will keep expanding. Leaving JetBrains as the exception only gets more expensive.

Related posts

More in Cursor

Comments

Checking sign-in…

No comments yet.