GitHub made local sandboxing generally available on October 7, 2026. That is a useful change for developers who let Copilot run commands, but availability is not evidence that a particular session is protected. The question to answer before delegating work is narrower: which actions can this session take, against which resources, under which effective policy?
This guide turns that question into a small acceptance record. It is based on current official documentation, not a CoreSecTech reproduction or penetration test. The featured illustration is conceptual.
A release announcement is not your security boundary
The October release announcement covers Copilot CLI, the Copilot app and VS Code sessions using Agent Host. GitHub says the feature restricts agent-initiated tools through filesystem, network and credential policies. It does not mean every editor session automatically uses the same configuration.
GitHub’s sandbox overview distinguishes local policy enforcement from a remotely hosted cloud sandbox. Local isolation is not a separate virtual machine or container. CLI and app settings are separate, and local sandboxing is off by default unless the applicable managed settings require it. Treat a working tree as branch/file organization, not proof of isolation.
CoreSecTech’s recommendation: record the exact product surface alongside every result. A successful CLI check is not acceptance evidence for a different app project or a VS Code session.
Build the acceptance record before granting access
Use a disposable project containing no real credentials, customer information or irreplaceable files. Define one intended task, such as updating a small test file. Write down the allowed project path, any required package host and whether authenticated Git operations are necessary. If you cannot state why a resource is needed, do not add it merely to avoid a future interruption.
| Boundary | Question to settle | Useful evidence |
|---|---|---|
| Files | Where may the task read and write? | Effective paths plus review of the actual changed files |
| Network | Does it need a registry, a local server or neither? | Requested destination and applicable policy—not just a successful build |
| Credentials | Does this task require authenticated access? | Credential availability and approved destinations, without recording secret values |
| Session | Is sandboxing active here, now? | Current-session status after starting or restarting the session |
These are acceptance questions, not a claim that CoreSecTech observed all these controls functioning. Keep the record with the task’s result so someone reviewing a change can see the intended boundary.
Check the current session, not only saved settings
In an interactive Copilot CLI session, the documented read-only commands are /sandbox status and /sandbox policy. The latter shows effective policy for the current directory. /sandbox enable changes the configuration; it is not an observation command. GitHub also warns that enabling sandboxing in one session does not immediately enable it in other already-open sessions. See Using local sandboxing.
Before attempting configuration, check the documented OS prerequisites. Windows requirements are specific to supported Windows 11 releases and updates; Linux requires supported Bubblewrap and slirp4netns availability. Do not treat an up-to-date Copilot client as proof that its host supports every isolation capability.
For the app, the configured policy summary is not confirmation that isolation is running. GitHub’s configuration documentation says project policy changes apply to new or restarted sessions. It also documents different defaults: local-network access is enabled by default in the app but disabled by default in CLI. Record the effective setting rather than copying a result from another surface.
Use a blocked operation as a diagnostic clue
Hypothetical scenario: a demo project builds successfully, but an agent cannot fetch a dependency from a private registry. This does not establish that the sandbox is defective. The task may lack the required destination, authentication or package configuration.
Keep the error, identify the requested host and verify that the dependency belongs to the project. Separate a credentials failure from a network denial before changing permissions. If access is justified, ask the policy owner for the smallest appropriate correction and repeat the same task. Do not approve unrestricted access to your home directory or company network as a general-purpose fix.
A bypass deserves separate review. GitHub documents that a command approved to run outside the sandbox can receive its ordinary environment, including real secrets; sandbox credential-masking restrictions do not protect that command. A blocked result is safer than a retry whose expanded scope you do not understand.
What a successful check still does not prove
A completed task proves only that the observed task completed under the conditions recorded. It does not prove the generated code is correct, that all tools enforce identical boundaries, or that the project has no sensitive data. GitHub notes that built-in CLI file tools check policy in-process on a best-effort basis rather than being constrained by the operating-system sandbox.
Review the resulting diff, external actions and dependency changes separately. If a credential was exposed, enabling a sandbox afterward does not revoke it; follow the revoke-first credential response workflow. If your concern is missing activity in reports, use the separate Copilot metrics diagnostic guide; telemetry completeness is not an isolation test.
The decision to delegate
Delegate when you can identify the active session, explain its needed access and review the outcome. Stop when the host cannot enforce the intended policy, the task needs unexplained broader access or a bypass would expose secrets. Sandbox availability is progress; a documented, narrowly scoped boundary is what makes that progress useful.