Isolation

The point of a sandbox is that the agent inside it has almost nothing to lose you. This page is the inventory: what it can reach, what it cannot, and what that buys you.

What it can reach

The folders you mounted. Read-write, and nothing else of your filesystem. See Mount folders.

The model gateway, through a broker on the host. The guest has no route to the internet of its own. A host-side egress broker exposes exactly one path, which forwards to your configured LLM gateway; the real gateway token is attached on the host, so it never enters the sandbox at all. The upstream call is made with the host's proxy settings, PAC scripts and enterprise trust roots, so it works wherever the app itself works.

Whatever an administrator has allowed. See Named egress rules.

A sandbox created without a gateway login has no egress at all.

What it cannot reach

On macOS and Linux the guest has no network device whatsoever, so there is nothing to confine — it can only speak to the host through the channels the app opens for it.

Windows is different: a WSL guest shares Windows' network, so a Windows sandbox could otherwise reach the internet directly. Its processes are confined by a firewall inside the guest. They can reach the sandbox's own server and the app's model-traffic relay, and nothing else — connections anywhere else fail immediately. Other WSL distributions on the machine are unaffected.

The firewall is mandatory. A sandbox that cannot set it up refuses to start rather than run open.

Who it runs as

The server inside a sandbox does not run as root. It drops to the image's ordinary codev account once the guest has finished mounting, so an escape from the sandbox has one less privilege to work with. Project files, the guest home and the bundled skills all stay fully usable.

Why permissions are skipped

Everything the agent does inside a sandbox is confined to the guest and the folders you mounted, so permission prompts have nothing left to protect — sandbox projects behave as if auto-accept were switched on. That is what lets you hand a sandbox a long task and leave.

You can still turn it off: the directory-level auto-accept toggle works as it does anywhere, and a project config inside the workspace can set stricter rules. See Permissions.

Named egress rules

An administrator can grant sandboxes extra brokered destinations beyond the model gateway by creating sandbox-egress.json in the app's data directory — an object of name to upstream URL:

{
  "npm": "https://registry.npmjs.org",
  "pypi": "https://pypi.org"
}

Each name is then reachable inside every sandbox at http://127.0.0.1:8788/<name>/....

This is an allowlist of named upstreams. There is deliberately no general proxy mode, and a malformed file fails the sandbox start with the parse error rather than silently granting less than intended.

The broker's own secret

Every running sandbox gets its own random token, injected into the guest and required on every brokered request.

It matters most on Windows, where the broker has to listen on TCP for the guest to reach the host: without the token, any other process able to reach that port could spend the real gateway credential the broker attaches on the host side. Each sandbox also gets its own relay port, because all WSL distributions share one loopback and two sandboxes would otherwise land on each other's relay.

What a sandbox does not protect

A sandbox is a boundary around the agent, not around your data. Anything you mount into it is fair game for whatever runs inside — that is the point of mounting it. Mount the folder you want worked on, not your home directory.