brig docs

Compare

Brig and gVisor

On this page

Brig gives a coding agent a microVM with a kernel of its own, your project and nothing else, a network rule you write, and its login from your keychain. gVisor runs a container on an application kernel written in Go, which runs as a process on your Linux kernel and answers the container's system calls itself.

gVisor is Google's sandbox for untrusted containers on Linux. It runs code execution in claude.ai, GKE Sandbox and the first generation of Cloud Run. In October 2026, Google announced that it is donating gVisor to the CNCF. Brig runs coding agents on macOS and Linux. Brig compared puts both beside the other tools.

At a glance #

Brig gVisor
Made for Coding agents Untrusted containers, mostly on servers
Runs on macOS 15 or newer on Apple silicon, and Linux with KVM Linux 5.6 or newer, on x86-64 and ARM64
Kernel One Linux kernel per sandbox, under a hypervisor The Sentry, a kernel in Go that runs as a process on the host kernel
Host files The project and the guest home, and nothing else from the host The bind mounts in the container's spec
Network An egress policy of hosts and ranges, enforced outside the guest. offline has no route out Its own network stack with the host's network, host passthrough, or loopback only. No rule by host
Credentials A secret store in the keychain, delivered by name as a file. The agent holds the value. v0.5.0 adds secret brokerage, and the guest then holds a placeholder Environment variables or mounted files, as in any container
Agent setup Eight built-in profiles None. You bring an image and a docker run line. Gemini CLI can run its sandbox under gVisor
Start Boots a kernel Starts the Sentry. No guest kernel boots
Needs Homebrew on macOS. KVM and the runtime bundle on Linux Linux. No KVM on the default platform. Root to install it into Docker
Licence Apache-2.0, three repositories Apache-2.0

What Brig gives you #

A hardware boundary, with a narrow surface behind it. Under Brig, the agent's system calls go to a Linux kernel inside a microVM. That kernel is inside the boundary, so a bug in it gives an attacker the guest and nothing more. Code on your machine sees only what leaves the VM: the hypervisor's exits and the guest's devices. On macOS, those are a console and four virtio devices, for the disk, the network, the exec channel and the shared files. To get out, an attacker needs a bug in the hypervisor or in that device code, and then lands in hvi, which runs inside a Seatbelt profile that denies by default. The boundary in hvi describes it. Under gVisor, the Sentry handles every system call the agent makes, and the Sentry is a process on your kernel. A bug anywhere in its implementation of Linux gives an attacker that process, limited by its seccomp filter and its namespaces. gVisor's README says it is "not a VM in the everyday sense of the term".

A Linux kernel. The guest runs a Linux kernel, so every system call the agent's tools make goes to Linux. gVisor implements the Linux interface in its own code. Its compatibility page says "there are (and always will be) unimplemented features and bugs", and io_uring is off by default.

An egress rule by host. A policy names the hosts the agent can reach:

apiVersion: brig.sh/v1alpha1
name: locked-down
egress:
  default: deny
  allow:
    - host: api.anthropic.com

Brig enforces the policy at the gateway on macOS and in nftables on Linux. Both points are outside the guest's kernel. A run on a backend that cannot enforce the policy is refused with exit code 7. See Networking. gVisor gives the container its own network stack, netstack, and has no rule by host or range. Its security page says network policy "should be applied at the container level", and its external network option leaves egress filtering to the peer.

Your login, from your keychain. Brig keeps your logins in a secret store, backed by the keychain on macOS and the Secret Service on Linux. A profile names which secret reaches the agent, as a file where the agent already reads it. The file sits on a memory-backed mount and does not reach host disk. Credentials states each limit. gVisor has no credential feature. The container gets what you pass to docker run.

The agent in one command. brig run claude ~/code/demo opens Claude Code in its sandbox. Brig ships eight profiles: Claude Code, Claude Desktop, Codex, Cursor, Gemini CLI, Grok, OpenCode and a plain Ubuntu shell. Each names the image, the paths the agent keeps, the credentials it gets and the variables it must not get. Under gVisor, you build or pick an image, install the agent, and write the mounts and variables yourself.

macOS. Brig runs on macOS and Linux. gVisor runs on Linux.

A test for each claim. Claims names the test behind every sentence of the security model, and a check runs on every pull request.

What gVisor does #

gVisor's runtime, runsc, is an OCI runtime, so Docker, containerd and Kubernetes start a container under it as they would under runc. Each container gets a Sentry: a kernel written in Go that implements the Linux interface and runs in user space. The container's system calls go to the Sentry, not to the host kernel.

The Sentry reaches the host through a minimal set of system calls, under a seccomp filter that refuses calls such as exec and connect. gVisor's documentation names Linux namespaces and cgroups as defense in depth, not as the primary layer. It does not protect against hardware side channels, and it relies on cgroups against resource exhaustion.

A platform decides how the Sentry intercepts system calls. Systrap has been the default since mid-2023. It needs no virtualization support from the host. The KVM platform uses the kernel's KVM to let the Sentry act as both guest kernel and VMM.

Files reach the container as the bind mounts in its spec. A companion process, the Gofer, serves them. With directfs, the default, the Sentry opens files directly, inside the same seccomp limits.

Netstack, gVisor's own network stack, carries the container's traffic. --network=host passes the host's network through, which the documentation says "decreases the isolation to the host". --network=none leaves a loopback interface. Rootless mode works mainly with runsc do, and it needs the host network.

gVisor also runs NVIDIA GPU workloads through a proxy driver, nvproxy, on selected driver versions.

When gVisor fits #

  • A Linux host with no KVM. Brig on Linux needs /dev/kvm. gVisor's default platform needs none, so it runs in a cloud VM without nested virtualization.
  • Docker, containerd and Kubernetes. gVisor plugs into each as a runtime. GKE Sandbox runs pods under it with a RuntimeClass. Brig runs on one host today. Work is in progress to run Brig sandboxes on remote Linux hosts, as Kubernetes pods, as compose stacks, and through an NVIDIA OpenShell driver.
  • Start time. gVisor starts a process with no guest kernel to boot. Brig boots a kernel.
  • GPU workloads. nvproxy runs most CUDA applications on selected NVIDIA driver versions.
  • Production use. gVisor runs GKE Sandbox, Cloud Run and App Engine at Google. Its users page also lists Anthropic, OpenAI and Cloudflare.

Run Claude Code under each #

Under Brig:

brig run claude ~/code/demo

Under gVisor, on Linux, with Docker set up for it (sudo runsc install, then restart Docker):

docker run --rm -it --runtime=runsc \
  -v ~/code/demo:/work/demo -w /work/demo \
  -v ~/.claude:/root/.claude -v ~/.claude.json:/root/.claude.json \
  node:22 sh -c 'npm install -g @anthropic-ai/claude-code && claude'

The gVisor line installs Claude Code on every run. It binds your login and settings from ~/.claude, so the credential file is on host disk and visible in the container. The container has the whole network. Gemini CLI runs its own sandbox this way when you set GEMINI_SANDBOX=runsc.

Sources #

Read on 2026-10-08.

Type a command, a flag or an error message.