A coding agent can follow your instructions and still run a command that reads the wrong file, reaches the wrong service or exposes a credential. Reviewing its answer afterwards cannot undo every action it took.
Sandboxing addresses a different part of the problem. Rather than relying only on instructions about what the agent should do, it restricts what its tools and commands are allowed to reach while the work is happening.
Decide the boundary before you start the agent
For each task, identify what the agent actually needs to use. A request to change a page in one repository does not automatically require access to your whole home directory, unrelated projects, private credentials or unrestricted network connections.
- Files: which project directories may the agent read, and which may it modify? Consider whether it needs access outside the checked-out repository.
- Network: does the task require internet access, access to internal services or neither? A package download and a request to an internal database are not the same permission.
- Credentials: does the task need Git or GitHub authentication? If not, do not expose those credentials merely because the agent is running locally.
- Tools: consider local services and integrations, including MCP tools, that could provide another route to sensitive data.
A useful rule is to start from the narrowest access that allows the accepted task to complete, then expand it deliberately when a specific step genuinely requires more. Keep the task's expected output and acceptance checks separate from the permissions you give it.
What the GitHub release establishes
In its October 2026 release announcement, GitHub says local sandboxing is generally available for GitHub Copilot CLI, the Copilot app and VS Code sessions using Agent Host. It describes restrictions on filesystem, network, credentials and other capabilities for agent-initiated tool execution, based on developer or organisation policies.
GitHub says the feature uses Microsoft eXecution Container (MXC) to translate a common policy into operating-system controls on Windows, macOS and Linux. It also describes enterprise-managed settings that can require sandboxing and prevent developers from weakening those policies. The announcement says local sandboxing is included with Copilot at no additional cost.
Those are GitHub's claims about the named Copilot environments, not proof that every agent, extension, integration or command on your machine is isolated in the same way. GitHub explicitly qualifies coverage of some local MCP tools and language servers as dependent on support. Check the coverage and policy settings for the environment you actually use.
Sandboxing is not the same as approval
A permission prompt asks whether an action should proceed. A sandbox defines what an action can reach when it proceeds. You can use both, but neither substitutes for the other. An approved command can still be too broad; a sandboxed command can still write incorrect code inside its allowed workspace.
Model selection and execution restrictions are also separate. GitHub says Copilot's sandbox policies apply to tool execution regardless of which model is selected. A more capable model does not remove the need to define what its commands may access.
Claude Code's October 2026 release notes separately list fixes involving sandbox read restrictions and permission bypasses. That supports the broader point that execution boundaries need maintenance and should not be treated as infallible. It does not establish feature equivalence between Claude Code and Copilot.
A practical check before an unattended run
- Write down the required change and which files should be affected.
- Identify the directories, network destinations, tools and credentials the task genuinely needs.
- Inspect the sandbox settings and confirm that unrelated files and services are outside the allowed boundary.
- If you work in a managed organisation, check whether its mandatory policies are enforced rather than relying solely on a local preference.
- Run the task, inspect the changed files and independently test the accepted behaviour before merging or deploying it.
If the agent cannot do the task within that boundary, decide whether the extra access is justified. Do not silently turn off isolation to make the error go away. For sensitive systems, a separate disposable environment and independent review may still be necessary.
Keep the controls separate
Sandboxing limits the effects of tools the agent runs. Clear instructions reduce ambiguous decisions. Testing establishes whether the result works. Review checks whether the change is acceptable for the risk. Each catches a different class of failure.
For the instruction and starting-project side of the problem, see preventing insecure defaults. For deciding how much checking is enough, see how to test code you didn't write. Giving an agent more independence should mean designing stronger boundaries and clearer evidence, not simply trusting its report.