GitHub Brings Managed Agent Settings to JetBrains IDEs
GitHub Copilot for JetBrains now supports enterprise managed settings for plugin governance, MCP access, OpenTelemetry, and agent permission modes.
Coding-agent governance is becoming a client coverage problem. It is not enough to define a policy for the CLI if half the engineering organization lives inside IntelliJ IDEA, PyCharm, WebStorm, GoLand, or another JetBrains IDE.
On August 18, 2026, GitHub announced that GitHub Copilot for JetBrains now supports enterprise managed settings for four important areas: plugin governance, MCP server access, OpenTelemetry configuration, and permission modes. The change sounds administrative, but it is a meaningful step toward treating AI coding tools as governed execution environments rather than optional editor extensions.
For experienced engineers, the important part is not that another checkbox appeared in an admin UI. The important part is that the same policy model can now reach more of the surfaces where agents read code, invoke tools, connect to MCP servers, emit telemetry, and request approval to run actions.
What Happened
GitHub's August 18 changelog says GitHub Copilot for JetBrains now supports enterprise managed settings for administrators on an enterprise Copilot plan. The release covers several control categories that had already been moving through other Copilot surfaces.
Administrators can manage Copilot plugins and plugin marketplaces in JetBrains IDEs. The supported settings include enabledPlugins for requiring a plugin to be enabled or disabled, extraKnownMarketplaces for adding approved plugin sources, and strictKnownMarketplaces for restricting installation to approved sources.
The same release adds centrally managed MCP controls for JetBrains. Administrators can use allowedMcpServers and deniedMcpServers to decide which MCP servers developers can connect to from Copilot in JetBrains. This matters because MCP is a tool boundary, not just a convenience protocol. An MCP server can expose filesystem operations, issue trackers, databases, browsers, deployment tools, or internal APIs. Letting every developer connect arbitrary local and remote MCP servers is not a sustainable enterprise default.
GitHub also added managed OpenTelemetry configuration for Copilot in JetBrains. Admins can centrally configure the collector endpoint, protocol, service name, resource attributes, and content-capture policy. GitHub says managed values take precedence over developer settings, so telemetry can be routed consistently to the approved collector.
Finally, the release adds organization-controlled permission modes. Administrators can set permissions.disableBypassPermissionsMode to disable, preventing the Copilot agent in JetBrains from using Bypass Approvals or Autopilot. In practical terms, this gives platform and security teams a way to prevent local agent workflows from silently drifting into allow-all execution.
Why It Matters
The industry has spent a lot of attention on model choice, context windows, and benchmark-driven coding performance. Enterprises adopting coding agents tend to discover a different problem first: there are too many execution surfaces.
A developer might use Copilot in VS Code for one repository, Copilot CLI in a terminal for another, the Copilot app for review work, Copilot cloud agent for delegated changes, and JetBrains for a production Java or Python monorepo. If each client has a different policy mechanism, governance becomes documentation theater. You publish guidance, but enforcement depends on client-specific defaults, developer choices, and whether someone remembered to configure a local setting.
This JetBrains update narrows that gap. It extends managed controls to a client family that matters heavily in backend engineering. JetBrains IDEs are common in JVM shops, Python teams, Go services, data engineering, Android development, and larger enterprise codebases. If agent permissions, MCP access, plugin sources, and telemetry controls only work in VS Code and the CLI, the policy is not enterprise-wide in any meaningful sense.
The MCP piece is especially important. MCP turns an assistant into a tool-using system with access to external capabilities. That is exactly why it is useful and exactly why it needs policy. A random MCP server installed from a random marketplace is closer to adding a new integration runtime than adding a theme. It may receive prompts, expose tools, execute local commands, or bridge into privileged systems. Enterprises need allowlists, denylists, marketplace restrictions, and audit-friendly rollout patterns before MCP becomes default infrastructure.
OpenTelemetry support matters for the same reason. Agent observability is moving from novelty to requirement. Teams need to see which clients are active, which workflows are invoking tools, where failures happen, and whether sensitive prompt and response content is being captured. The useful detail in GitHub's reference docs is not just that telemetry can be enabled; it is that admins can configure the endpoint, protocol, service name, resource attributes, headers, and captureContent policy. That is the shape of an operational control, not a product usage statistic.
How It Works
GitHub documents enterprise managed settings as a schema used by supported Copilot clients. The supported client list includes Copilot CLI, VS Code, JetBrains IDEs, the GitHub Copilot app, and Copilot cloud agent, although not every client supports every property.
There are three deployment paths.
Server-managed settings are the default path for most enterprises. Administrators create or update a .github-private repository and place policy in copilot/managed-settings.json. GitHub's docs say users on supported clients receive those settings automatically within about an hour, and signing in again or restarting the client can trigger an immediate refresh. Server-managed settings are associated with the user's signed-in account and can apply to all supported clients, including Copilot cloud agent.
MDM-managed settings are aimed at IT-managed macOS and Windows fleets. Instead of deploying a JSON file directly, admins push operating-system-managed string values through tooling such as Intune, Jamf, or Group Policy. This is useful when device posture matters or when policy needs to exist before a user signs in.
File-based settings are the lowest-level option. Admins place managed-settings.json in a platform-specific system location, such as /etc/github-copilot/managed-settings.json on Linux. GitHub's docs call out containers and Codespaces as places where file-based deployment can be useful when server-managed or MDM-managed rollout is not available.
Precedence is explicit. MDM-managed settings win over server-managed settings, which win over file-based settings, which win over user-level settings. The exception is the Copilot CLI sandbox key, where managed restrictions combine in the most restrictive direction rather than simply replacing one another.
Team-specific policy is supported for server-managed deployments. An enterprise can mark selected keys as overridable in managed-settings.json, then map enterprise teams to files under copilot/teams/ using copilot/team-mappings.json. GitHub's docs say this override mechanism applies to permissions.model, permissions.disableBypassPermissionsMode, allowedMcpServers, and deniedMcpServers. enabledPlugins and extraKnownMarketplaces are additive, so team files can add to an enterprise baseline.
That creates a useful operating model. A platform team can define a conservative enterprise default, then give a trained AI platform group access to additional MCP servers or plugins without opening those capabilities to every Copilot user.
Example
Imagine a company standardizing Copilot across Java services in IntelliJ IDEA, Python services in PyCharm, and TypeScript services in WebStorm. The platform team wants three things.
First, all users should get the company's internal review plugin. Second, MCP access should be limited to the company's hosted MCP gateway and a vetted local Playwright server. Third, tool execution should require approvals; bypass-style operation should not be available from the IDE.
A simplified copilot/managed-settings.json might look like this:
{
"permissions": {
"disableBypassPermissionsMode": "disable",
"model": "auto"
},
"enabledPlugins": {
"internal-review@engineering-tools": true
},
"extraKnownMarketplaces": {
"engineering-tools": {
"source": {
"source": "github",
"repo": "example-org/copilot-marketplace"
}
}
},
"strictKnownMarketplaces": [
{
"source": "github",
"repo": "example-org/copilot-marketplace"
}
],
"allowedMcpServers": [
{
"serverUrl": "https://mcp.example.com/*"
},
{
"serverCommand": ["npx", "@playwright/mcp@latest"]
}
],
"deniedMcpServers": [
{
"serverCommand": ["npx", "-y", "@modelcontextprotocol/server-filesystem", "/"]
}
],
"telemetry": {
"enabled": true,
"endpoint": "https://otel-collector.example.com",
"protocol": "http/protobuf",
"captureContent": false,
"lockCaptureContent": true,
"serviceName": "copilot"
}
}This is not a full production policy, but it shows the shape of one. The policy does not ask developers to voluntarily configure the right collector or avoid risky MCP servers. It makes the approved path the enforced path.
There are a few implementation details worth noticing.
For MCP allowlists, GitHub supports matchers such as serverUrl for remote servers and serverCommand for local stdio servers. serverCommand matching is exact; wildcards and command-line expansion are not supported. That is the right tradeoff for local tool identity. Matching a friendly server name chosen by the user is convenient, but it is weaker than matching the actual command and arguments used to launch a local server.
Deny rules take precedence over allow rules. GitHub's reference docs also note that first-party Copilot servers, such as the built-in GitHub MCP server, are exempt from deny rules. That is an important operational detail if your threat model assumes every MCP endpoint can be blocked the same way.
For telemetry, captureContent and lockCaptureContent deserve explicit review. Turning on traces while accidentally capturing prompt and response content can create a new sensitive-data sink. Turning content capture off and locking that setting is a reasonable default for many enterprises, especially before legal, security, and data governance teams have agreed on retention and access policy.
My Take
This is a governance release, not a glamour release, and that is why it matters.
Coding agents are becoming normal developer infrastructure. Once an agent can invoke tools, connect to MCP servers, install plugins, emit traces, and run code-modifying workflows, it belongs in the same governance conversation as package managers, CI runners, browser automation, developer secrets, and endpoint management.
The strongest part of GitHub's approach is that it uses configuration artifacts an engineering organization can reason about. A .github-private repository containing copilot/managed-settings.json, team mappings, and team-specific files is reviewable, versioned, and auditable. It gives platform teams a control plane that can be changed through code review rather than through a spreadsheet of editor setup instructions.
The weakest part is that policy coverage still needs careful reading. GitHub is explicit that not every property applies to every client. Enterprises should not assume "managed settings" means uniform behavior everywhere. Before rolling this out, someone should build a small compatibility matrix for the clients actually used in the company: VS Code, JetBrains, CLI, Copilot app, cloud agent, Codespaces, and any managed desktop variants.
I would also treat MCP policy as a first-class rollout project. Start with an allowlist, not a broad marketplace. Prefer remote MCP gateways where identity, logging, rate limits, and network boundaries are centrally managed. Use local stdio servers only when the local capability is genuinely needed, and match them by command. If a local MCP server needs filesystem access, decide whether that belongs in the IDE agent path at all or inside a more constrained environment.
For OpenTelemetry, ship the collector path before asking teams to depend on the data. A managed endpoint with inconsistent downstream parsing will only create another pile of noisy traces. Define service names, resource attributes, retention, content-capture policy, and access controls up front. Agent telemetry is useful only if engineers and incident responders can query it without turning it into a surveillance mess.
Conclusion
GitHub's August 18, 2026 JetBrains managed-settings release is a practical signal about where coding agents are headed. The interesting work is shifting from "can the model write code?" to "can the organization safely operate many model-backed tools across many developer surfaces?"
Bringing plugin governance, MCP server policy, OpenTelemetry routing, and permission-mode controls to JetBrains IDEs closes a real coverage gap. For enterprises with serious JetBrains usage, this should move Copilot policy from best-effort guidance toward enforceable baseline configuration.
The next step is not to turn every setting on at once. It is to define the baseline: approved marketplaces, allowed MCP servers, denied high-risk local servers, locked telemetry content policy, and disabled bypass approvals. Then pilot it with one team, verify it in the IDE, and treat changes to the policy file like changes to production infrastructure.