GitHub Copilot Local Sandboxing Is Now Generally Available

GitHub has made local sandboxing generally available for Copilot CLI, the GitHub Copilot app and supported VS Code sessions using Agent Host. The feature creates a restricted execution boundary around commands and tools that Copilot runs on a developer's machine.

This is becoming increasingly important as coding assistants move from suggesting code to running commands, editing files and using local tools. The more autonomy an agent has, the more useful it becomes to define exactly which parts of the computer it is allowed to touch.

What local sandboxing controls

GitHub says sandbox policies can limit which files and directories agent-run commands can read or modify. Policies can also control access to the internet, local networks, Git credentials and GitHub CLI credentials.

Those controls apply to tool execution rather than to one specific AI model, which means the security boundary remains useful even when teams change the model behind the agent.

The feature works across operating systems

GitHub's local sandboxing is powered by Microsoft eXecution Container, or MXC. GitHub says MXC translates a common sandbox policy into native operating-system controls across Windows, macOS and Linux.

A shared policy model matters for organizations where developers use different operating systems but security teams still need consistent rules.

Local tools can also sit inside the boundary

GitHub says the sandbox can apply to local tools and services, including supported local MCP servers and language servers.

That is important because an agent's real capability often comes from the tools around it. Restricting the model while leaving every connected tool unrestricted would leave a large part of the risk unmanaged.

Enterprise policies can be enforced centrally

Organizations can require local sandboxing through enterprise-managed settings and define policies developers cannot weaken.

That makes the feature more practical for companies that want agentic coding without relying on every developer to configure the same security boundaries manually.

Sandboxes make more autonomous workflows realistic

Agents become more useful when they can run tests, inspect files, execute commands and fix problems without stopping for every small step. But broad machine access can make that autonomy difficult to approve.

A sandbox changes the tradeoff. Teams can give the agent room to work while keeping sensitive directories, credentials and networks outside the permitted area.

What developers should still review

Sandboxing reduces the impact of mistakes, but it does not make agent-generated commands automatically correct. Developers still need to review important changes and avoid giving broader permissions than the task requires.

The most reliable approach is least privilege: start with a narrow policy and expand access only when the workflow genuinely needs it.

Sources and further reading

Read GitHub's local sandboxing announcement

Explore more articles on the Nejma Blog

Visit Nejma