Copilot for JetBrains gets admin-managed sandbox

The GitHub Changelog announced on September 8, 2026 a package of updates for the Copilot plugin in JetBrains IDEs (IntelliJ, PyCharm, GoLand, WebStorm, and similar). Amid UX improvements and fixes, the change that really alters the governance of AI-generated code is a single one: company-managed sandbox policies entered public preview. This text focuses on that item, because it's the one that changes what the dev can and can't do inside the IDE.

What the managed sandbox does

Until now, Copilot's sandbox in JetBrains was a local control: the developer decided whether to isolate execution of commands and tools triggered by the agent. With the update, enterprise administrators now configure this behavior centrally, and the configuration is pushed down to the dev's machine as policy.

According to the source, the managed policies control:

• activation (or deactivation) of the sandbox;
• access to the filesystem;
• access to the network;
• proxy settings;
• access to developer tools;
• access to the macOS Keychain.

The central governance point lies in the changelog's phrase: "Managed restrictions take precedence over user settings". In other words, the organization's policy overrides the dev's preference. When a control is managed, Copilot locks that field in the IDE and flags that it's under the organization's management. The dev sees the setting but can't loosen it.

There's also an important visibility condition: the options under GitHub Copilot > Sandbox only appear if the organization enables the Editor Preview feature flag or sets a managed configuration that turns the sandbox on or off. Without either condition, the sandbox screen simply doesn't exist in the IDE.

Why this matters for those who build

Discussion about AI assistant security usually stops at source-code exfiltration. The sandbox targets another vector: what happens when the agent executes things. A modern agent doesn't just suggest text; it runs shell commands, triggers MCP servers, reads and writes files, makes network calls. Without isolation, a command generated by a prompt (or by a prompt injection embedded in a repository file) runs with the logged-in user's permissions.

Access to the macOS Keychain on the list of controls is the detail that gives away the real concern: it's the machine's credentials. Blocking network and keychain reads for the agent's process is the kind of barrier that separates "the agent made a mistake with a command" from "the agent leaked a production token".

For Brazilian teams in regulated sectors (banking, fintech, healthcare, government), the update solves a concrete compliance problem: until now, ensuring that every dev ran Copilot with the same restrictions depended on individual discipline or MDM scripts. Now it's a policy the admin defines once and that locks in everyone's IDE.

What this replaces and where it still falls short

This announcement doesn't stand alone. It fits into a sequence of enterprise controls GitHub has been rolling out: content exclusions shipped as GA in the Copilot app and CLI, and enterprise-managed settings now accept any default model. The managed sandbox is the runtime piece of that governance, alongside the content pieces (what the model can read) and the model piece (which LLM runs).

It's worth separating the layers, because they solve different things:

| Control | What it protects | Status | |---|---|---| | Content exclusions | Files that Copilot shouldn't read/index | GA | | Enterprise-managed default model | Which model the org uses by default | Available | | Managed sandbox (JetBrains) | Execution: filesystem, network, keychain, proxy | Public preview | | Enterprise policy diagnostics | Check whether policies took effect on the device | New |

Policy diagnostics is the pragmatic complement: without a way to verify that the rule arrived and is being applied on the machine, managed policy becomes an act of faith. The update lets the admin (or the dev) confirm that Copilot's configuration follows the organization's requirements.

The open points that deserve caution:

1. It's public preview. It's not the place to bet production compliance on without validating the behavior in your stack.
2. It's JetBrains-specific. Parity with VS Code isn't guaranteed by this announcement. Teams that mix editors need to check coverage per IDE.
3. Managed keychain only makes sense on macOS. A Linux/Windows fleet has a different credential surface, and the changelog doesn't detail the equivalent.
4. The sandbox reduces friction, it doesn't eliminate it. Locking down filesystem and network can break legitimate flows (an agent that needs to download a dependency, for example). Whoever enables it should map what devs actually execute before locking everything down.

The rest of the release, in context

The same update brought items that help the day-to-day without touching governance. Next edit suggestions now do cursor jumps between files: when a suggested change continues in another file, you can jump straight to the right spot instead of hunting manually, which is useful in refactors that spread changes across several modules.

Global context in chat lets you pin files and folders that apply to the entire project, reducing repetitive context setup on every conversation. And there's a new bridge between Copilot CLI and the IDE: the /ide command connects a terminal session to JetBrains' context, including selections, diagnostics, and file references. Copilot's shell commands now use the IDE terminal's environment variables and the Python interpreter configured in the project, even activating the default local virtualenv, which makes connected execution more consistent with the dev environment.

On the stability side, the release fixes behaviors in MCP servers and agent sessions (BYOK provider persistence, OAuth continuity, GitHub Enterprise authentication) and resolves blank chats, wrong working-set counts, and freezes after automatic compaction. OpenTelemetry settings in chat became GA for all users, which matters to those who want their own telemetry on assistant usage.

For those administering teams: the path here would be to enable the managed sandbox on a pilot group, use policy diagnostics to confirm the restrictions took effect, and only then define the filesystem/network/keychain baseline that makes sense for the repository before extending it to the whole fleet. The reference documentation cited by GitHub is the guide Configuring local sandbox settings for GitHub Copilot.