Product1 publisher3 min readPublished
GitHub moves Copilot's sandbox lock into the JetBrains plugin itself
Admins can now set filesystem, network, proxy, developer-tool and Keychain limits for Copilot sessions from inside the plugin rather than through a device-management request, and a new diagnostics tool tells them whether the policy reached the laptop.
The Product Desk · Product desk
What happened
- GitHub put enterprise-managed sandbox policies for Copilot in JetBrains IDEs into public preview, covering filesystem and network paths, proxy routing, developer-tool access and, on Mac, the Keychain.
- Settings an admin locks appear in the JetBrains plugin marked "(managed)", and a developer working in that IDE cannot override them locally.
- Enterprises could already enforce some of this sandbox behaviour through Intune or another device management platform, which is where the policy sat before.
- The Copilot CLI's /ide command now wires a terminal agent session into JetBrains context, so it sees the same selections and diagnostics the IDE does.
Compiled by The Product DeskSomething wrong?How this is made
Why it matters
- decision Loosening a network path for one team becomes a plugin setting rather than a device-management change request, which changes both how fast it happens and whose queue the sign-off sits in.
- capability A platform team can now ask a developer's machine whether the policy arrived, instead of inferring enforcement from the console where it was set, which is the precondition for turning on more autonomous agent modes.
- constraint Because the locks ship inside the JetBrains plugin, coverage stops where that plugin does, so anyone supporting a second client needs a separate answer for it.
- exposure Whether an agent session can reach the macOS Keychain is now a value an admin sets and owns, which makes credential reach a named decision rather than whatever the local default was.
For the developer, this arrives as a settings pane with a few rows greyed out and the word "(managed)" printed beside them [2]. Nothing else about Tuesday changes. For whoever owns Copilot configuration, it arrives as six decisions to write down and answer for: sandboxing on or off, which filesystem paths a session can read, which network paths it can reach, which proxy it routes through, whether it can touch developer tools, and on macOS whether it gets the Keychain [1][13].
The relocation matters less as a new power than as a consolidation of the config surface. GitHub opened this managed-settings channel in the JetBrains plugin in August to govern plugins, MCP server allowlists and telemetry routing, and sandbox behaviour is the fourth thing on it [6][14]. Devops.com's framing is that device-management policy is broad and slow to change, while a setting shipped with the tool lets a platform team adjust it in an afternoon instead of filing a change request [7]. That is a genuine difference in cycle time. It also moves the sign-off out of the endpoint team's queue and into the platform team's, and both effects arrive together.
What teams tell themselves is that a policy set centrally is a policy in force. The diagnostics tool concedes those are two different states: it exists so an admin can confirm managed settings are being detected and enforced on a given developer machine [3]. Devops.com puts it as a policy nobody can confirm running being close to no policy at all [10]. Mitch Ashley of The Futurum Group is blunter about who skips the step, calling verification "the part most organizations still skip" [9] and describing an agent-capable IDE as "a runtime that needs the same access controls as any other system touching production code" [8].
The boundary questions land now, rather than in June when local and cloud sandboxes for Copilot CLI went to public preview [4], because the same release widens what one agent action touches. Next-edit suggestions can jump across files instead of stopping at the open one, and chat can pull project-wide context rather than waiting for attached files [11]. A larger blast radius per accepted suggestion is what makes the filesystem and network lists worth arguing over.
Two limits are worth holding onto. The sandbox policies are in public preview [1], and they live in the JetBrains plugin, the same place as the August controls [1][6], so a team standardising on more than one client gets one answer here and needs a separate one elsewhere. The material also carries no adoption or usage figures, which leaves diagnostics output as the only thing a platform team can actually measure on Monday.
The test worth running per lever has two columns. Column one is the value you set. Column two is machine-level evidence that the value is in force, produced by something other than the console where you set it. Levers with only column one should be treated as unset for planning purposes, and those are the ones to name before anyone enables a more autonomous Copilot mode.
What to watch
- Whether these sandbox policies leave public preview, and what the sandbox does on a machine where no admin has set anything.
- Whether GitHub puts the same managed-settings channel and diagnostics behind Copilot in other editors and in the CLI.
- Whether policy diagnostics produces a per-machine record a platform team can keep, or only a live check on the developer's box.