sbx

sbx [--cloud] [-D] [command] [args...]

sbx is the command-line interface for Docker Sandboxes. It creates isolated environments for AI coding agents such as Claude Code, Codex, and Gemini CLI. Each local sandbox is a microVM with its own kernel, filesystem, and private Docker daemon, so the agent can install packages and build containers without using the host Docker engine.With no command, sbx opens a terminal dashboard of sandbox cards (status, CPU, and memory). The same screen is sbx tui. From it you can create, start, stop, attach, shell into, and remove sandboxes, and edit network rules.sbx run creates a sandbox if needed and attaches to the agent. The first argument is a built-in agent name or a sandbox kit (a local directory, a zip, a git repository, or an OCI reference). Extra arguments after `--` are passed to the agent. Repeating sbx run on the same workspace reconnects to the existing sandbox. --name gives the sandbox a stable identity so you can reattach from another directory, or run several sandboxes against one tree.The host directory is mounted at the same absolute path inside the sandbox. That direct mode is the default: the agent can read and write the working tree, and edits show up on the host immediately. --clone instead checks out a private copy inside the sandbox. The host repository is then available read-only at `/run/sandbox/source`. Clone mode is fixed at creation time.--cloud sends supported commands to Docker Cloud Sandboxes instead of the local `sandboxd` daemon. Local and cloud sandboxes have separate credentials, network policy, and lifecycle. The CLI and local compute are free to use. Cloud compute is billed separately, and model-provider charges are separate from Docker.sbx does not require Docker Desktop or Docker Engine on the host.

--cloud

Dispatch to the Docker Cloud Sandboxes API instead of local `sandboxd`. Not every subcommand supports it. `sbx --cloud --help` lists the ones that do.

Enable debug logging.

Sign in to Docker in a browser. Required before creating sandboxes.

Stop running local sandboxes and sign out.

Create a sandbox if it does not exist and attach to the agent. See RUN OPTIONS.

Create a sandbox without attaching. A local sandbox stops when nothing is using it. Files and configuration remain until rm.

List sandboxes, including status, agent, published ports, workspace, and age.

Run a command in a sandbox. The default working directory is the primary workspace. Detached exec is not supported.

Stop one or more sandboxes without deleting them.

Remove one or more sandboxes. Prompts for confirmation. --force skips the prompt and allows removal while a session, SSH connection, or SFTP transfer is active.

Remove stopped local sandboxes. Running sandboxes are kept. --dry-run only prints the list.

Attach to a cloud sandbox, starting it first if it is stopped.

Copy files between the host and one sandbox. One side must be `sandbox:absolute-path`. Copying between two sandboxes is not supported.

Publish or remove a port forward. Publishing a port on a stopped local sandbox starts it. Give only the sandbox port to let the OS pick the host port.

Manage network and filesystem access rules: allow, deny, ls, rm, inspect, check, log, init, and reset.

Store, list, and import credentials. The host proxy injects them so they are not written into the sandbox filesystem.

Save a sandbox filesystem as an image, list images, load a tar, or remove one. Mounted workspaces are not part of the saved image.

Manage the local `sandboxd` daemon.

Move a sandbox between the local machine and Docker's cloud.

Show or extend a cloud sandbox's time to live.

Register MCP servers for sandboxed agents.

Manage persistent volumes. Cloud only.

Manage Docker Sandboxes settings.

Check the local installation.

Print the version.

Print a shell completion script.

Open the interactive dashboard. This is also the default when no command is given.

Remove sandboxes and local state. Prompts unless forced. Can keep stored secrets.

Experimental. Manage sandboxes from an `sbxenv.yaml` file.

Experimental. Manage sandbox kit artifacts.

Experimental. Detect host configuration and prepare Docker Sandboxes.

Experimental. Manage skills available inside sandboxes.

sbx policy init allow-all|balanced|deny-all

Choose the global network preset. `balanced` is the recommended starting point. Later changes use `sbx policy allow`, `sbx policy deny`, and `sbx policy rm`. Rules apply to every sandbox unless --sandbox name is set. `sbx policy reset` clears custom policy and asks for a preset again. Running sandboxes are stopped when the local daemon restarts.

Store a credential for a supported service, a custom host, or a registry (`sbx secret set --registry`). Prefer this to writing tokens into the sandbox or into a saved template.

Inside a sandbox, Bash sources this file for later interactive sessions and for agents started with sbx run. Append `export` lines via `sbx exec` when a variable must outlive a single -e flag. A command passed straight to sbx exec does not start a shell.

--name name

Assign or reattach to a sandbox by name. The agent argument can be omitted when reattaching.

Delete the sandbox when the agent exits, without a prompt. The sbx run exit status is the agent's. Cannot be combined with --detach or --detach-keys.

Start the sandbox and return without an agent session. The sandbox keeps running until stop or rm. Using this on an existing sandbox switches it to detached mode permanently.

Give the agent a private in-sandbox Git clone. Must be set when the sandbox is created. The primary workspace has to be the main checkout of a Git repository, not a linked worktree.

Create the sandbox from a template image. Pass the full reference. sbx does not assume `docker.io`.

Publish a port at creation time. Ignored when run reattaches to an existing sandbox. Use sbx ports for that case.

Set an environment variable in the sandbox. A bare name copies the value from the host. On create, the variable is stored with the sandbox. On reattach, it applies to that session only. Requires sbx 0.39.0 or later.

Load variables from a file. Later files override earlier ones. -e overrides both.

CPUs to assign. `0` means all host CPUs, at most 16 on Linux arm64.

Add a per-sandbox network deny rule at creation. Repeat for more hosts. A local deny can only narrow access.

Network pattern to allow for cloud sandbox egress. Cloud only. Repeatable.

This page is Docker's sbx command. It is unrelated to the Python package `sbx-rl` (Stable Baselines Jax), which is imported as a library and is not this binary.Local sandboxes need a hypervisor. On Linux that is KVM, and the user must be in the `kvm` group. Docker supports local sandboxes on Ubuntu 24.04 or later (x86_64 or arm64). Nested virtualization is required when the host itself is a VM. macOS needs Apple silicon and macOS Sonoma or later. Windows needs Windows 11 and Windows Hypervisor Platform. --cloud does not need KVM.`sbx rm` deletes the sandbox filesystem, including packages installed inside it and a clone-mode worktree. Host workspace files and the shared skills store on the host stay. A saved template includes files from the container filesystem, so credentials written into the sandbox are baked into the image.Network access is denied or limited by policy. A process inside the sandbox is not reachable from the host until a port is published.Sign-in is required. `sbx login` uses a browser OAuth flow.nixpkgs ships this command as `docker-sbx` and marks the package unfree.

docker(1)

Homepage · Documentation · Source code