GitHub Locks Down What Copilot's Agents Can Touch

Every sandboxing and access-policy change GitHub has shipped for Copilot's agents since June, including Friday's, is still labeled public preview.

GitHub added local sandboxing to its standalone Copilot app on Friday, the fourth sandboxing or access-policy change to reach Copilot's changelog since June, and every one of the four is still labeled public preview, according to GitHub's own posts.

The Friday release, posted on GitHub's blog, also added four models across paid plans: Claude Opus 5.5, GPT-6 Sol and GPT-6 Luna for Pro+, Max, Business and Enterprise tiers, and Grok 4.7 for every paid tier including plain Pro. The same post added OpenTelemetry monitoring, letting administrators track what Copilot's agents do through monitoring tools they already run, and local sandboxing in the app itself, restricting an agent's access to files, networks and credentials during a session.

Four months of the same argument

GitHub's changelog shows a consistent pattern: give developers a way to isolate an agent, then give administrators a way to enforce and verify that isolation.

Date	Release	What it added
June 2, 2026	Cloud and local sandboxes	Local isolation via /sandbox enable, built on Microsoft's MXC technology; enforceable only through Intune or other device management
Sept. 8, 2026	Enterprise-managed sandbox in JetBrains	Central policies for filesystem, network, proxy, dev-tool and Keychain access that override a developer's own settings, plus a diagnostics tool
Sept. 22, 2026	Copilot for JetBrains 1.18.0	Assisted Approvals: automatic sign-off on low-risk tool calls, with higher-risk actions still flagged for a human
Sept. 25, 2026	Weekly Copilot release	Local sandboxing added to the standalone Copilot app, plus four new models and OpenTelemetry monitoring

The local sandboxes GitHub shipped in June restricted what a shell command run by Copilot could reach, but only Microsoft Intune or a similar device-management platform could enforce that restriction across a company's machines. The Sept. 8 release moved enforcement into Copilot itself: managed policies now lock the relevant settings inside the JetBrains plugin directly, and administrators get a diagnostics tool to confirm a policy actually reached a given developer's machine rather than existing only in a configuration file.

Why an editor needs a production system's access controls

Mitch Ashley, vice president and practice lead for CIO and technology buyers at The Futurum Group, told DevOps.com the shift reflects what autonomous agents change about what an IDE is. "Once an agent can execute commands, edit across files, and reach the network on its own, the IDE isn't just an editor anymore," Ashley said. "It's a runtime that needs the same access controls as any other system touching production code."

DevOps.com's coverage also pointed to a practical reason GitHub built policy controls into the Copilot plugin rather than relying solely on device management: platform teams can adjust a sandbox policy in an afternoon, rather than filing a change request against a company's broader device-management system. That distinction matters more once an agent is making unattended tool calls, which is what Assisted Approvals, shipped two weeks after the managed-sandbox release, is built to handle at the moment of the call rather than after the fact.

The same Friday post extended agent access in a different direction even as it tightened it elsewhere. VS Code 1.139, released the same day, added agent support inside Dev Containers reached over SSH, Tunnel and WSL hosts, according to the VS Code release notes GitHub linked from its own post, plus a compact view for managing multiple agent sessions at once. Copilot in Slack and Microsoft Teams also picked up mid-conversation model switching and expanded context sharing, including files, attachments and message links, in the same release. Every one of those additions widens what an agent can reach or how many places it can run from, which is exactly the surface the sandboxing and policy releases exist to contain.

What GitHub still has not said

Sandboxing remains opt-in. The June 2 announcement that introduced it made clear it is off by default, and nothing in the three releases since has changed that; a developer who never runs /sandbox enable, or an organization that never configures a managed policy, gets none of the isolation described above. GitHub has not published what share of Copilot sessions run sandboxed, or how many organizations have turned on the enterprise-managed policies that became available on Sept. 8. Compare that to how Docker priced its own agent sandboxes the same month, by the second rather than by policy, a bet that usage data alone would show whether isolation was actually being used.

GitHub's Friday release landed the same day as Microsoft's own overhaul of the consumer and business Copilot apps, which leans on the same underlying agent technology GitHub is now trying to contain. The clearest test of whether this becomes enforcement rather than a setting nobody enables is whether GitHub ever reports adoption numbers for managed sandbox policies, or moves local sandboxing from opt-in to on by default. Neither has a date attached to it yet, and until one does, the honest description of where things stand is that the plumbing for enforcement now exists across JetBrains and the standalone app, while the decision to actually turn it on is still left to whoever configures the machine.

Sources

1. GitHub Copilot weekly releases — September 21 (GitHub)
2. Enterprise-managed sandbox in Copilot for JetBrains (GitHub)
3. Cloud and local sandboxes for GitHub Copilot now in public preview (GitHub)
4. New features and improvements in Copilot for JetBrains (GitHub)
5. GitHub Puts Guardrails on Copilot's Sandbox Inside JetBrains IDEs (DevOps.com)