Agent terminal commands can run processes with the same operating system permissions as your user account. Agent sandboxing adds an operating system-level boundary that restricts the files and network resources these commands can access.
This article describes where agent terminal sandboxing is available, how to turn it on, and how to configure its file system and network boundaries.
Sandboxing and approvals provide separate layers of protection:
| Protection | Purpose |
|---|---|
| Approvals | Determine whether an action runs automatically or requires your confirmation. |
| Sandboxing | Restricts the file system and network resources that an approved terminal command can access. |
Sandboxing applies to terminal commands and their child processes. It does not apply to built-in file tools or other agent tools, and it does not replace the isolation provided by cloud sessions or Dev Containers. MCP server sandboxing is a separate feature with its own configuration and platform support.
For the security model and threats that sandboxing helps mitigate, see Trust and safety.
Agent terminal sandboxing has different lifecycle states and prerequisites by platform.
| Platform | Status | Enablement setting | Prerequisite |
|---|---|---|---|
| macOS | Preview | chat.agent.sandbox.enabled | None. |
| Linux and WSL2 | Preview | chat.agent.sandbox.enabled | Install bubblewrap and socat. |
| Windows | Experimental | chat.agent.sandbox.enabledWindows | Install the applicable September 8, 2026 Windows security update. |
On Debian and Ubuntu, install the Linux dependencies:
sudo apt-get install bubblewrap socat
On Fedora, install the Linux dependencies:
sudo dnf install bubblewrap socat
WSL version 1 is not supported because it does not provide the Linux kernel features that bubblewrap requires.
On Windows, install the update that applies to your Windows version:
Windows support is Experimental. The Windows lifecycle status in this article applies only to agent terminal sandboxing. MCP server sandboxing is not available on Windows.
Set the enablement setting for your platform to on, or select Sandboxing for terminal in the permissions picker.
| Platform | Setting | Default |
|---|---|---|
| macOS, Linux, and WSL2 | chat.agent.sandbox.enabled | off |
| Windows | chat.agent.sandbox.enabledWindows | off |
Sandboxing is independent of the selected permission level. For example, an enabled sandbox continues to restrict terminal commands even when you select Allow all.
The shield indicator in the permissions picker shows the effective sandbox state for the current session.
If the required operating system dependencies are unavailable, VS Code does not silently run the command without the sandbox. Follow the notification to install the missing dependency, or turn off sandboxing before you run the command.
For a Copilot Agent Host session, the Sandboxing for terminal toggle applies only to the current session:
The effective state uses the following precedence:
off.If a managed setting requires sandboxing without a bypass, the toggle is disabled. If the managed setting permits a bypass, the session starts with sandboxing on and you can turn it off for that session. Learn more about managed agent sandboxing.
With the default file system configuration, sandboxed terminal commands:
Use the file system setting for your platform to add or restrict paths:
| Platform | Setting | Rules | Path syntax |
|---|---|---|---|
| macOS | chat.agent.sandbox.fileSystem.mac | allowRead, allowWrite, denyRead, denyWrite |
Literal paths and Git-style glob patterns. |
| Linux and WSL2 | chat.agent.sandbox.fileSystem.linux | allowRead, allowWrite, denyRead, denyWrite |
Literal paths. |
| Windows | chat.agent.sandbox.fileSystem.windows | allowRead, allowWrite, denyRead |
Literal paths. |
The following example grants read access to an application configuration folder and prevents access to an SSH folder on Linux:
{
"chat.agent.sandbox.fileSystem.linux": {
"allowRead": ["/home/me/.config/myapp"],
"denyRead": ["/home/me/.ssh"]
}
}
Workspace folders, the sandbox runtime temporary folder, and per-command read paths are added automatically. You typically only need allowRead for configuration or data outside the workspace.
File system and network isolation are separate controls. By default,
chat.agent.sandbox.allowNetwork
is true, which permits unrestricted network access while preserving the file system boundary.
Set
chat.agent.sandbox.allowNetwork
to false to apply network isolation. An empty
chat.agent.allowedNetworkDomains
list then blocks all outbound network access. Add only the domains that terminal commands need, and use
chat.agent.deniedNetworkDomains
to block exceptions. Denied domains take precedence over allowed domains.
{
"chat.agent.sandbox.allowNetwork": false,
"chat.agent.allowedNetworkDomains": [
"api.github.com"
],
"chat.agent.deniedNetworkDomains": [
"example.com"
]
}
The same domain lists apply to the fetch tool and integrated browser when you turn on chat.agent.networkFilter .
Restart VS Code after you change chat.agent.networkFilter , chat.agent.allowedNetworkDomains , or chat.agent.deniedNetworkDomains to ensure new integrated browser sessions use the updated network policy.
An agent can perform actions on an allowed domain, not only read data. For example, access to api.github.com can permit repository changes. Allow only domains that are required for the task.
When a sandboxed command is blocked by network isolation,
chat.agent.sandbox.retryWithAllowNetworkRequests
controls whether the agent can ask you to retry the command inside the sandbox with unrestricted network access. The default is true. File system restrictions remain active for the approved retry.
By default, terminal commands that run inside the sandbox are approved automatically. Set
chat.agent.sandbox.allowAutoApprove
to false to use the normal terminal approval flow for sandboxed commands.
If a command cannot run inside the sandbox, the agent can ask for confirmation to run it outside the sandbox. Set
chat.agent.sandbox.allowUnsandboxedCommands
to false to remove this fallback. The default is true.
The agent tries the command inside the sandbox first. Rejecting the confirmation prevents the command from running outside the sandbox.
