Copilot is no longer a completion assistant. It runs terminal commands, edits files, and starts language and tool servers. That convenience raises one question: how far can its commands reach on my machine?

GitHub answered on October 7 with local sandboxing going GA: available in Copilot CLI, the Copilot app, and VS Code Agent Host sessions, included with Copilot at no extra cost, and re-introduced in the October 9 weekly release. This post separates what turns on from what still leaks.

What shipped: lightweight isolation in three places

Local sandbox: watch what Copilot runs on your machine
 → limits files, network, credentials (OS-level isolation, not a full VM)
 → no extra charge, default off

Cloud sandbox: run the whole session in a disposable GitHub-hosted Linux box
 → fully separated from your machine, fresh per session
 → usage-billed, started with copilot --cloud

GA means the experiment label came off, not that it became bulletproof. The docs draw the line plainly: commands run "inside an operating-system-level sandbox," not a full virtual machine. Combined with the local-model discovery flow, the shape is now complete: models move between local and cloud, execution stays caged.

Copilot CLI: one line with /sandbox enable

The CLI is the simplest. Manage it inside a session.

# Turn on (immediate, persists to later sessions)
/sandbox enable

# Check what is actually enforced
/sandbox status

# Inspect effective read, write, and blocked paths
/sandbox policy

# Open settings (/sandbox alone does the same)
/sandbox config

# Turn off (refused under enforced managed policy)
/sandbox disable

# Sandbox for one session only, without changing settings
copilot --sandbox -p "PROMPT"

# One session without sandbox (--no-sandbox cannot beat managed policy)
copilot --no-sandbox

With sandbox ON:
  What Copilot runs (shell, file search, default MCP and LSP servers)
    → executes inside the OS sandbox
    → when blocked: "retry with broader access?" approval prompt
    → approve / keep blocked / disable sandbox for this session

Credentials:
  git push and gh pr create go through a proxy
  → sandboxed processes see placeholder credentials only
  → real ones substituted for approved HTTPS destinations
  → gh scoped to github.com, api.github.com, uploads.github.com

Under enterprise managed settings that require sandboxing, /sandbox disable is refused. Where bypass is permitted, it disables only the current session. Trust status and policy, not memory.

The Copilot app and VS Code Agent Host: off by default

The app is per-session.

/sandbox on   → on immediately for this session (survives restart)
/sandbox off  → off immediately for this session
Project defaults unchanged; unavailable for cloud or remote-host sessions
A "Run outside the sandbox?" prompt appears per effective policy

VS Code Agent Host has the most knobs. The ones that matter:

Setting Default Meaning
chat.agent.sandbox.enabled off isolation starts only after you turn it on, new sessions
chat.agent.sandbox.network.allowNetwork true outbound internet allowed by default — restrict separately
chat.agent.sandbox.network.allowLocalNetwork false host and private network blocked by default
chat.agent.sandbox.fileSystem.userConfiguredPaths empty set read-write, read-only, and denied paths yourself
chat.agent.sandbox.mcpServers / lspServers true MCP and language servers also sandboxed
chat.agent.sandbox.credentials.authenticateGit/gh true pass Git and gh auth into the sandbox
chat.agent.sandbox.allowUnsandboxedCommands true offer outside-sandbox runs (false fails instead of asking) 
Platform prerequisites (on the machine where the agent runs):
 macOS → none
 Linux and WSL2 → install bubblewrap + socat
 Windows → September 8, 2026 security update required

Verify in order:
 1. prerequisites → 2. enabled on → 3. new session
 4. /sandbox policy for the effective policy (exportable report)

The easiest line to miss is allowNetwork: true. Turning the sandbox on does not block the internet. Write allowed and denied domains explicitly. On Windows, proxy, domain limits, and credential masking need local-network access on, which also opens the private network — close it when done.

CodeBridge Mini Lab: verify in a throwaway repo

Before touching your real project, verify in a separate repo — exactly the briefing action.

1. Create one throwaway test repo (never your real project)
2. CLI: /sandbox enable, then confirm with status and policy
3. File boundaries:
   [ ] reads and writes outside the working directory blocked
   [ ] parent paths and home directory denied
4. Network:
   [ ] outbound requests blocked with allowNetwork false
   [ ] allowed and denied domains behave as intended
5. Credentials:
   [ ] git push and gh commands work through the proxy shape
   [ ] keys do not leak in sessions left on
6. Approval flow:
   [ ] blocked commands produce an approval prompt
   [ ] with allowUnsandboxedCommands false, they fail without asking

Attach this checklist to the isolation layer of the four-layer security post. A sandbox is one layer, not the whole wall. It works with scope, approval, and review.

Conclusion: do not leave execution to defaults

One line to close.

A sandbox becomes trustworthy not when you turn it on, but when you confirm what it blocks.

GA means "no longer experimental," not "now safe." Remember three conditions: default off, network allowed by default, OS-level isolation. Turn it on in a test repo, inspect policy, and block files, network, and credentials one by one. That table decides how much you delegate next.

Further reading

References

Go deeper with a course

To attach Agent and Plan modes to a real project including the execution environment, this course applies Copilot to a Java and Spring project — a direct continuation of the verification lab here.