Copilot Sandboxes Are Live. Your Merge Gate Still Matters.

On June 2, GitHub put cloud and local sandboxes for GitHub Copilot into public preview. Copilot can now run shell commands, modify files, and hit the network inside an isolated environment — either a local sandbox on your machine via Microsoft MXC, or an ephemeral Linux VM hosted by GitHub in the cloud.

This is a real step forward for agentic development. But it solves one specific problem — execution isolation — and leaves another one wide open: is the code the agent produced actually safe to merge?

What the sandboxes actually do

There are two flavors. Local sandboxes use /sandbox enable to restrict what Copilot can touch on your filesystem, network, and system capabilities. They're built on Microsoft's MXC isolation layer and work across macOS, Linux, and Windows. Enterprise teams can enforce sandbox policies centrally through Intune or other MDM platforms.

Cloud sandboxes go further. Run copilot --cloud and Copilot spins up a fully isolated, ephemeral Linux environment hosted by GitHub. Sessions inherit your existing Copilot cloud agent policies automatically. You can continue sessions across devices, run multiple tasks in parallel, and offload compute-intensive work without burning local resources.

Both approaches solve the same core concern: when Copilot runs a command or modifies a file during agentic work, it shouldn't have unconstrained access to your machine or your organization's infrastructure. That's a security win.

The gap sandboxes don't close

Sandboxes protect the machine while the agent works. They don't evaluate the output. An agent can run inside a perfectly isolated environment and still produce code that introduces a SQL injection, breaks an API contract, or quietly drops error handling from a critical path.

Think of it this way: the sandbox confirms the agent ran safely. It says nothing about whether the code it wrote is correct, secure, or aligned with your team's standards. Those are two fundamentally different questions.

The first is about runtime isolation. The second is about code quality. Sandboxes handle the first. The second needs a review layer that sits between the agent's output and your main branch.

Agent PR volume changes the math

Sandboxed agents don't just change how code gets written. They change how much code gets submitted. Cloud sandboxes let developers run multiple Copilot tasks in parallel, each producing changes that eventually land as pull requests. A team of five developers running two or three concurrent agent sessions each can easily double or triple their normal PR output in a day.

Human reviewers don't scale that way. A senior engineer reviewing eight PRs a day is already at capacity. Bump that to 20 or 25 and reviews get shallower, turnaround times stretch, and the merge queue backs up. That's the exact environment where bugs slip through — not because anyone was careless, but because the review bottleneck can't absorb the volume.

The more agents produce, the more you need an automated quality gate that doesn't get tired, doesn't skip files, and can block a merge when the code doesn't meet your threshold.

Where a pre-merge review gate fits

A pre-merge gate runs after the PR is opened and before the code can merge. It evaluates the diff independently of who or what wrote it — human developer, Copilot agent, or any other tool. If the review finds issues above a configured severity threshold, the merge is blocked until those issues are addressed.

This is what Tenki Code Reviewer does. It plugs into your existing GitHub setup as a required status check, reviews every PR against your codebase context, and assigns severity levels to the issues it finds. There's no distinction between a PR authored by a person and one produced by an agent. The same thresholds, the same analysis, the same pass/fail decision.

That uniformity matters. If you introduce an "agent bypass" mode where bot PRs get lighter scrutiny, you're betting that agents produce consistently safe code. That's a bet most engineering leads aren't ready to make, and for good reason. Agent output quality varies by prompt, by model version, by the complexity of the task. A gate that treats every PR equally is the safer default.

Tuning thresholds for higher agent volume

When your team starts using sandboxed agents regularly, PR volume goes up and the review gate needs to handle that without becoming a bottleneck itself. Tenki's severity thresholds are configurable per repository, so you can tune what blocks a merge and what gets flagged as a warning.

A practical starting point:

• Block on critical and high severity. Security flaws, data loss risks, and broken contracts shouldn't merge regardless of who wrote the code.
• Warn on medium. Style issues, minor refactoring opportunities, and non-critical suggestions stay visible without gating the merge.
• Silence low-severity noise. When you're processing 3x the normal PR volume, nitpick-level comments create more friction than value. Suppress them or batch them into weekly summaries.

The goal is to catch the things that matter without adding review latency that cancels out the speed gains agents provide. If your gate takes 90 seconds per review and blocks only genuine problems, the throughput increase from sandboxed agents actually sticks.

Sandboxes and gates are complements, not alternatives

GitHub's sandbox announcement fills a real gap in the agentic workflow. Before this, Copilot's tool execution ran with whatever permissions your local environment or CI runner had. Now there's proper isolation. That's worth adopting.

But don't confuse execution safety with code quality. The sandbox is the wall around the construction site. The review gate is the building inspector. You need both, especially when the pace of construction just tripled.

If you're evaluating Copilot's new sandbox features, pair them with a pre-merge review gate that holds every PR to the same standard. Your agents get to work faster. Your main branch stays protected.