nprasad2077/docker-docs
1
0 Fork 0
mirror of https://github.com/docker/docs.git synced 2026-11-04 10:01:00 +00:00
Code Issues Packages Projects Releases Wiki Activity

Sync sbx CLI reference from release/v0.51 (#26514)

Browse Source 
Vendor the checked-in CLI YAML from Docker Sandboxes release/v0.51 at
7d55286de0c7. This updates command help, adds `sbx policy check http`,
and replaces seven agent-specific create pages with redirects to `sbx
create`.

Validation: full site build with Hugo 0.169.0; upstream byte-for-byte
comparison; all 115 command pages, reference links, and seven redirects
checked; template formatting and whitespace checks passed.
This commit is contained in:
David Karlsson authored and GitHub committed 2026-11-04 10:10:52 +01:00
1 parent 4a695beb43
commit 1773367159
124 files changed
+844 -1439
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

content/manuals/ai/sandboxes/release-notes.md
+111 -141
View File
@@ -16,6 +16,117 @@ the full release history, including pre-releases and downloads, see the
<!-- BEGIN GENERATED RELEASES -->
## 0.51.0
{{< release-date date="2026-11-03" >}}
[GitHub release](https://github.com/docker/sbx-releases/releases/tag/v0.51.0)
### Highlights
Docker Sandboxes v0.51.0 runs built-in agents from published kits and adds custom mount targets for additional workspaces, environment launch command defaults, and more controls for automation. It also strengthens workspace-copy and credential protections and improves network, MCP, and sandbox startup reliability.
### Breaking changes
#### Built-in agents and shell images
Built-in agent names now resolve to published kits at `docker.io/sbx/<name>:latest`. This applies to Claude, Codex, Cursor, Devin, Docker Agent, OpenCode, Kiro, Copilot, and Droid. `sbx run sbx/<kit>` also accepts published kits, including kits named after built-in agents. The `kit.allowExtractedAgents` setting is removed.
- Sandboxes created by earlier releases from embedded Claude or Codex specifications keep running, but must be recreated before using `sbx kit add`, `sbx run --model`, or `sbx move`. Save files and unpushed commits before removing a sandbox.
- The shell agent now uses a published Debian 13 v3 kit. First use requires registry access. To provide shell sandboxes with provider credentials, add the `shell-credentials` mixin. Existing shell sandboxes keep running.
- V1 and v2 kits cannot be combined with v3 kits. Upgrade older mixins to v3 before combining them with the new built-in kits.
- The `docker/sandbox-templates` images for `codex`, `cursor-agent`, `devin`, `docker-agent`, and `opencode`, including their `-docker` variants, are no longer published.
- The `docker/sandbox-templates:shell` and `:shell-docker` images are no longer refreshed. For custom workloads, use `docker.io/sbx/shell-image` and `docker.io/sbx/shell-docker-image`.
#### Clipboard access and custom secrets
- Copying text from a local sandbox to the host clipboard now requires opting in with the `clipboard.textCopy` setting. Native clients such as Codex are supported.
- Custom secrets without destination hosts no longer substitute credentials. Repair existing mappings by adding explicit destination hosts while preserving their placeholders and other settings.
### What's new
#### Security
- `sbx cp` blocks symbolic links in mounted directories from escaping onto other host paths. On Windows, it also blocks workspace escapes through substituted drives.
- Unix clients verify that daemon sockets belong to the same account before sending requests.
- `sbx kit sign` no longer runs configured Git filter drivers while checking signed file contents. Its recovery guidance preserves committed bytes even when repository attributes request line-ending conversion.
- Files replaced by Sandboxes on Windows retain their existing access control lists.
- Network policy commands reject empty `--sandbox` values instead of applying changes globally.
#### Kits and agents
- `sbx kit add` installs added image content in all-v3 sandboxes while preserving filesystem changes. `sbx run --model` generates a v3 model kit when the base uses v3.
- `sbx kit inspect --resolved` shows the kit with its `extends` parent merged in.
- Kit installation logs are saved inside the sandbox at `/var/log/sbx-kits/<kit>/install-<n>.log`. Progress shows command descriptions, and debug mode streams successful installation output and the startup log. Failed startup commands produce a warning with the log tail instead of failing `sbx run`.
- Kits can request publication of a host-loopback port when granted the required permission. Each request requires user approval and expires after 45 seconds.
- Kits declaring `agent-context@2` guidance work with local and cloud sandboxes, including when they also offer `agent-context@1`.
- Optional kit credentials no longer prevent creation when absent. Kit changes after a daemon restart preserve stored Bedrock profiles, and recovery after a failed kit change preserves access to shared skills.
- Shell kits support custom templates, and v3 kits load correctly when their descriptor is named `spec.yaml`.
- Docker Hardened Images (DHI) kits are accepted by the default kit source allow list.
- GitHub Copilot authentication works when the GitHub secret is stored with `--command` or as a reference.
#### Sandbox lifecycle and workspaces
- Additional workspaces accept `PATH:TARGET[:ro]` with `sbx create` and `sbx run`. Environment files support the same custom targets through `additionalWorkspaces[].target`.
- `sbx run --workdir` starts the agent in a directory inside the workspace, including when reattaching to an existing sandbox.
- Environment files support `entrypoint` and `cmd` defaults for `sbx env run`. Command-line arguments can replace the default command. `sandboxOptions` also accepts `rootSize`, `dockerSize`, and `clonedWorkspaceSize`.
- Interactive `sbx env exec` offers to create a missing environment sandbox. Interactive `sbx env run` can adopt a matching existing sandbox when its environment records have been lost, after confirmation.
- New local sandboxes support FUSE filesystems, controlled through `sandbox.fuse` and the environment option `sandboxOptions.fuse`.
- Sandbox memory limits can be set up to the host's total memory, with a warning above 75%.
- Workspace, clone, kit-volume, and mount targets that would hide the shared skills store are rejected before creation or modification. Startup also explains how to recover when a file occupies the shared skills directory.
- `sbx inspect` shows the Sandboxes version that created a sandbox, for sandboxes created with this release onward. `sbx ls`, `sbx inspect`, and `sbx prune --dry-run` JSON include configured host bind mounts, including workspace, kit, and skills mounts. List and prune output also indicate missing mount sources. Existing workspace fields remain available.
- `sbx ls` reports unreadable sandbox state instead of silently omitting the sandbox. Clone failures include Git's underlying reason, such as dubious ownership.
- Resizing an interactive terminal during startup or shutdown no longer produces spurious errors. On Windows, Ctrl+Z no longer ends input forwarding, and automatically started daemons are less likely to stop when the launching command exits.
#### Networking and policy
- Linux hosts using split-horizon DNS, including VPN configurations with corporate nameservers, can reach internal HTTPS hosts through the sandbox proxy and retrieve proxy auto-configuration files from them.
- The proxy reuses upstream connections when injecting credentials, improving parallel downloads such as package installations.
- Bursts of outbound connections no longer crash the daemon when the host network stalls.
- Failed upstream connections for inspected HTTPS requests return a 502 response identifying the host and reason instead of an empty reply.
- `sbx policy check http` checks HTTP governance policy behavior.
- Policy listings keep the implicit default-deny fallback visible and distinguish it from explicit deny rules. Policy setup correctly identifies the local preset, and Gordon preserves HTTP rule restrictions.
- The policy TUI shows setup guidance after a reset, warns about stale rules, and resumes updates after setup. Storage failures report a server error instead of incorrectly requesting policy initialization.
- `sbx reset` reports how many user-added and approval-granted network rules it will remove, including with `--force`, and points to `sbx policy init` afterward.
- `sbx ports` accepts `-p` for `--publish` and identifies the destination sandbox port when a host port is already published.
#### Authentication, MCP, and models
- `sbx secret set-custom --value-stdin` reads a secret from standard input, avoiding secret values in command arguments.
- Daemon image pulls use the `sbx login` session and stored registry credentials. Published agent kits can be fetched through authenticated registry mirrors.
- Enable `mcp.useServerNamePrefixes` to prefix MCP tool names with their server name.
- `sbx create` and `sbx run` accept `--static-mcp none` to use static MCP mode without attaching servers.
- Approval-gated MCP calls proceed after approval, including with newer MCP clients. Server tools ending in `-authorize` or `-revoke-auth` are available again.
- MCP servers have more time to initialize, reducing startup timeouts. Code-mode sessions cancel in-flight tool calls on exit and handle parallel requests more reliably.
- `sbx mcp auth` and `sbx mcp add` suggest `--client-id` when a server refuses dynamic client registration.
- Set `model.server.enabled` to `false`, then run `sbx daemon restart`, to disable the bundled model server and its inference-runtime download.
#### Cloud sandboxes
- Kit updates no longer fail with “Template has N running sandboxes” while sandboxes using an earlier version are running.
- Building source kits uses less temporary disk space during upload.
- Volume names tolerate surrounding whitespace and reject whitespace-only values. Cloud launches reject local-only model overflow flags instead of silently ignoring them.
- Port listings include the reported protocol in JSON and YAML output. `sbx move --ttl` accepts case-insensitive duration units.
- Help and shell completion identify supported cloud options and explain file-transfer limitations for symbolic links and empty directories.
#### CLI, settings, and diagnostics
- `--no-input` prevents interactive prompts, including Docker sign-in, and reports the command needed to continue.
- `sbx run --no-progress` suppresses creation progress while retaining command results. `sbx create --no-progress` still prompts for cloud network-policy confirmation when needed.
- `sbx --version` prints the client version without starting the daemon. Canceled sandbox and environment creation exits with status 130 and a clear message.
- Persistently disable local CLI and daemon telemetry with `sbx settings set telemetry.disabled true`. The next CLI invocation uses the preference; run `sbx daemon restart` to apply it to a running daemon.
- Compatibility errors and stale engine tasks identify `sbx daemon restart` as the recovery command. Daemon startup failures show only the current attempt's error output, preserving line breaks.
- Windows SSH configuration works with both native OpenSSH and Git Bash OpenSSH. `sbx diagnose` detects missing Windows shell support for Claude Desktop SSH connections and warns when the state directory uses eCryptfs, which can cause image-pull I/O errors.
- Command help and empty-list hints provide clearer next steps for secrets, MCP servers, skills, cloud sandboxes, and template recovery.
## 0.50.1
{{< release-date date="2026-10-28" >}}
[GitHub release](https://github.com/docker/sbx-releases/releases/tag/v0.50.1)
- fixes an issue that prevented sandboxes from starting
## 0.50.0
{{< release-date date="2026-10-26" >}}
@@ -174,147 +285,6 @@ Docker Sandboxes v0.49.1 improves kit compatibility, proxy support for cloud con
- Full templates now include a C/C++ toolchain for compiling native code inside the sandbox.
- The Linux tarball installer works for regular users on systems with AppArmor.
## 0.48.0
{{< release-date date="2026-10-13" >}}
[GitHub release](https://github.com/docker/sbx-releases/releases/tag/v0.48.0)
### Highlights
Docker Sandboxes v0.48.0 updates the CLI across all commands, with consistent terminal output and JSON/YAML formats. This changes flags, structured output, and prompts used by existing scripts. Review the migration details below before upgrading automated workflows.
The release also adds managed Codex and Claude Desktop SSH targets on macOS and Windows, additional v3 kit capabilities, and support for adding kits with startup commands to existing sandboxes.
### Breaking changes
#### CLI flags, output, and automation
The CLI refactor changes both interactive use and scripting interfaces. Existing `--json` parsers may need updates even if their command lines still work. Scripts that parse human-readable output must switch to `--format json` or `--format yaml`.
##### Update command flags
| Command | Previous spelling | Replacement or behavior |
| --- | --- | --- |
| `sbx run`, `sbx env run` | `--detached` | Use `--detach` or `-d`. `--detached` is rejected. |
| `sbx logout` | `--yes`, `-y` | Use `--force` or `-f`. |
| `sbx env plan`, `sbx env create`, `sbx env run` | `--auto-approve`, `-y` | Use `--force` or `-f`. |
| `sbx create` | `--quiet`, `-q` | Use `--no-progress`. This suppresses progress, but still prints the creation summary. |
| `sbx template save` | `-d` for the description | Use `--description`. |
| `sbx diagnose` | `--output`, `-o` | Use `--format table`, `--format json`, `--format yaml`, or `--format github-issue`. |
| `sbx secret ls`, `sbx secret rm` | `--env` | Use `--env-name`. |
| `sbx policy log` | `--quiet`, `-q` | Removed; there is no replacement. |
`--format`, `--json`, and `-q` are mutually exclusive on commands that use the shared output flags. Even `--json --format json` is rejected. Unsupported format values fail during flag parsing instead of falling back to human-readable output.
`sbx settings ls` is the primary spelling; `sbx settings list` remains an alias. `sbx kit builder history rm` keeps `--yes` / `-y` because its `--force` flag is forwarded to Buildx. The deprecated `--global` and `mcp add --skip_auth` flags remain accepted but hidden, with a deprecation warning on stderr; use `--skip-auth` instead of `--skip_auth`.
##### Update structured-output parsers
`--json` is an alias of `--format json` and emits the same document. JSON output structures have changed for the commands listed in the following table. Output uses `snake_case` field names; YAML is derived from the same representation.
| Command | Output change |
| --- | --- |
| `sbx ls` | Returns the sandbox array directly instead of `{"sandboxes": [...]}`. Fields use `snake_case`, `created_at` and `last_used_at` use RFC 3339 timestamps, and rows include `detached`. |
| `sbx template ls` | Returns the image array directly instead of `{"images": [...]}`, for local and cloud sandboxes. |
| `sbx mcp ls` locally | Returns the server array directly instead of `{"gateway": {...}, "servers": [...]}`. Each server row carries `gateway`. |
| `sbx policy log` | Local and cloud output use `{updated_at, allowed: [...], blocked: [...]}`. Entries contain `sandbox_id`, `host`, `proxy_type`, `rule`, `reason`, `count`, `first_seen`, and `last_seen`. `--limit` applies. This replaces local `allowed_hosts` / `blocked_hosts` and the cloud camelCase document. |
| `sbx --cloud policy ls` | Field names change from camelCase to `snake_case`. |
| `sbx ports` | Cloud rows use `sandbox_port` instead of `port`, alongside `url`. Local rows use `host_ip`, `host_port`, `sandbox_port`, and `protocol`. |
| `sbx ports --publish` / `--unpublish` locally | Structured formats emit result rows with `action: published` or `action: unpublished` instead of human-readable lines. Warnings go to stderr. |
| Cloud `volume create`, `volume ls`, and `volume inspect` | Fields such as `ID`, `Name`, and `CreatedAt` become `id`, `name`, and `created_at`. `volume inspect` defaults to a human-readable details view; request `--format json` for JSON. |
| `sbx rm`, `sbx stop`, `sbx template rm`, `sbx volume rm` | Structured formats return an array of results with `action`, `resource`, `name`, and optional `id` and `error`. Actions are lowercase: `removed`, `stopped`, `removing`, `stopping`, or `failed`. Missing and failed targets are included. |
For example, a script that extracts sandbox names from `sbx ls --json` must change its filter from `.sandboxes[].name` to `.[].name`.
Local and cloud output follow the same conventions. MCP list output still represents different resources: local registrations versus server usage across cloud sandboxes, so those rows differ beyond their shared `name` and `type` fields.
`sbx prune --dry-run` accepts `--format json` and `--format yaml`. Cloud `ttl --format yaml` emits YAML instead of JSON, and `sbx diagnose` supports YAML. `sbx events --json` remains an NDJSON stream, and `sbx mcp auth --format text|json` retains its command-specific formats.
##### Update non-interactive workflows
- Confirmation prompts require terminal input. Piping an answer, such as `echo y | sbx secret set …`, no longer confirms the operation. Use `--force` / `-f` where the command provides it. Commands that require confirmation fail with exit status 1 when stdin is not a terminal.
- Declining a confirmation returns a non-zero exit status consistently, including for removal, reset, and prune operations.
- Read-only invocations and runs with `--force` do not start an interactive sign-in flow. Sign in before running automation that requires authentication. Read-only examples include `ports SANDBOX`, `ttl SANDBOX`, `prune --dry-run`, and `diagnose`; their modifying or upload variants are not read-only.
- Without a terminal, `sbx diagnose --upload` saves the diagnostic bundle but skips uploading it and exits with status 0. A successful exit does not mean that an upload occurred.
- Without a terminal, `sbx create` and `sbx run` fail if the workspace directory does not exist and print a `mkdir -p` hint. Create the directory before invoking the command.
- Ctrl-D at a selection or free-text prompt cancels instead of accepting the default. Enter still accepts the default.
##### Terminal output and streams
Human-readable output changes across all commands: headings, status marks, indentation, progress, and result messages use a consistent format. `sbx ls` includes state marks and a creation-time column; `sbx ls` and `sbx inspect` identify detached sandboxes.
Results go to stdout. Errors, warnings, corrective hints, daemon-start progress, image pulls, and kit-build progress go to stderr. Update scripts that depend on exact message text or capture only one stream.
### What's new
#### Security
- Fixed sign-in enforcement ignoring `allowedOrgs` on macOS.
- `sbx cp` blocks local paths that escape a sandbox workspace through symbolic links.
- Cloud `sbx cp` downloads and `sbx kit pack` preserve restrictive destination permissions without temporarily exposing the replacement file. They account for permissions at completion and do not widen them. On Unix, cloud `sbx cp` refuses to replace files owned by another user; on Windows, permission preservation covers the read-only attribute. Special permission bits are retained where the kernel permits. This cloud-copy change does not affect local `sbx cp`.
- `sbx kit add` checks the filesystem mount policy before recreating a sandbox and refuses the operation if its workspace or a saved mount is denied, matching `sbx start`.
- Fixed the daemon crashing on a malformed request sent through an intercepted HTTPS connection.
#### SSH and desktop integration
- On macOS and Windows, `sbx setup ssh --auto-create` registers Docker Sandbox connections in Codex and Claude Desktop. Each connection creates a dedicated sandbox on first use and reuses it on subsequent connections. These sandboxes have no host workspace mounted. Clone or copy your project into the sandbox to work on it.
- Desktop SSH setup warns about missing authentication and provides local sign-in guidance for Codex and Claude. Repeating `sbx setup ssh` recognizes existing registrations even while the applications are running.
- Closing a Cursor or VS Code window connected over SSH no longer stops the daemon and other running sandboxes.
- SSH connections no longer fail because the CLI's initial feature lookup timed out before starting the daemon.
- SSH-agent forwarding supports Windows OpenSSH and 1Password agents when `SSH_AUTH_SOCK` is not set.
#### Kits
- V3 kits support capability groups, `kit.env` references, bundled agent skills, and the `ssh-agent@1` and `git-identity@1` capabilities. Selected optional groups retain their network rules, lifecycle files, and context; unsupported optional groups are skipped. Bundled skills can use directories outside the agent's home.
- `sbx kit add` accepts kits with startup commands. Those commands run after the kit is added and on each subsequent sandbox start.
- Sandbox containers expose the provisioned agent's name through `SBX_AGENT` for kit hooks and scripts.
- `sbx kit validate` rejects kits whose credentials route the same host, identifying the conflicting services. The daemon logs the collision during sandbox creation.
- Sandbox creation supports kits whose resolved lock exceeds Docker's container-label size limit.
- `sbx kit pack` excludes its output from the archive, prevents writes into the kit's `files/` directory, and handles Windows 8.3 output paths without renaming the destination or including a previous archive. The output path must end in `.zip` and cannot be a named pipe, socket, or device node.
- An unresolvable kit-file path no longer causes `sbx kit push` to fail.
- Kits that declare an agent-context directory now have their agent instructions file written in that directory instead of beside the workspace, and large workload and mixin kit combinations no longer fail to create with "failed to run sandbox container".
#### Sandbox lifecycle and workspaces
- Creating a sandbox from a local snapshot saved with this version avoids registry requests by default, including when using the daemon API.
- `sbx exec`, `sbx run`, `sbx cp`, and SSH report an unresponsive guest with stop-and-start guidance instead of hanging. `sbx ls` marks the sandbox as not responding.
- Commands against an already-running sandbox reuse guest setup instead of repeating it on every `exec`, `run`, or `cp` invocation. Setup runs once per container start or daemon restart.
- `sbx reset` no longer leaves stray sandbox resources or stalls when another sandbox operation is in progress.
- Sandbox startup identifies files still in use from a previous run instead of reporting a generic failure.
- `sbx exec` accepts empty command arguments.
- `sbx cp` preserves dot-prefixed paths and restrictive directory permissions. On Windows, downloads can replace a read-only destination instead of failing with “Access is denied”.
- `sbx run` and `sbx create` support workspace directories whose names start with a dot.
#### Cloud sandboxes
- `sbx move --to cloud` and `sbx --cloud env create` accept `--ttl` and `--on-timeout restart`, extending always-on support beyond `sbx --cloud create`.
- Fixed `on_timeout` response decoding errors when using `--on-timeout`.
#### Authentication, agents, and MCP
- Sandbox-scoped custom secrets can override global secrets that use the same environment variable name.
- Fixed Docker Hub sign-outs on macOS when the host sleeps or wakes during login-token refresh.
- The built-in Codex kit registers the MCP gateway with supported settings, removing ignored-setting warnings and sending the gateway its Authorization header. Recreate existing Codex sandboxes with `sbx rm` and `sbx create` to receive the change.
- `sbx mcp unload NAME --sandbox SANDBOX` detaches a loaded MCP server without restarting the sandbox's agent.
- MCP connections and discovery probes identify as `docker-sbx`, and backend recovery respects rate limits to avoid reconnect storms.
- `sbx run --model --provider` uses the API key stored with `sbx secret set <provider>` without exposing it to the sandbox. `sbx run --variant` selects a model thinking variant.
- Fixed `sbx run --model` failing with “401 Unauthorized” when pulling from Docker Hub after a browser-based `docker login`.
#### Networking and policy
- The proxy handles trailing-dot hostnames and mixed-case `host.docker.internal` consistently, fixing refused requests and missing credential injection.
- Sandbox image pulls retry temporary registry failures reported as HTTP 5xx errors, including when the original error type is lost across API or progress-stream boundaries.
- Fixed WebSocket connections through the proxy occasionally losing the first bytes sent by the client.
- `sbx policy ls SANDBOX` returns an error when the sandbox does not exist.
- `sbx policy inspect` accepts policy names that match one of their own rule names, such as `default-deny-all`.
- Removing a kit-managed network rule by resource explains that the kit manages it instead of asking for a rule ID.
#### CLI and diagnostics
- Shell completion scripts generate without starting telemetry, reducing generation time.
- `sbx diagnose` checks for `mkfs.ext4`.
<!-- END GENERATED RELEASES -->
## Earlier releases
data/redirects.yml
+10
View File
@@ -1459,3 +1459,13 @@
- /engine/reference/commandline/volume_rm/
"/reference/cli/docker/volume/update/":
- /engine/reference/commandline/volume_update/
"/reference/cli/sbx/create/":
- /reference/cli/sbx/create/claude/
- /reference/cli/sbx/create/codex/
- /reference/cli/sbx/create/cursor/
- /reference/cli/sbx/create/devin/
- /reference/cli/sbx/create/docker-agent/
- /reference/cli/sbx/create/gemini/
- /reference/cli/sbx/create/opencode/
- /reference/cli/sbx/create/shell/
data/sbx_cli/sbx.yaml
+7
View File
@@ -18,6 +18,13 @@ options:
shorthand: h
default_value: "false"
usage: help for sbx
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
- name: version
default_value: "false"
usage: Show version information
see_also:
- sbx attach - Attach to a cloud sandbox, starting it first if it is stopped
- sbx completion - Generate the autocompletion script for the specified shell
data/sbx_cli/sbx_attach.yaml
+4
View File
@@ -29,6 +29,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
# Attach to a sandbox by ID or name
sbx --cloud attach sbx_abc123
data/sbx_cli/sbx_completion.yaml
+4
View File
@@ -18,6 +18,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
see_also:
- sbx - Manage AI coding agent sandboxes.
- sbx completion bash - Generate the autocompletion script for bash
data/sbx_cli/sbx_completion_bash.yaml
+4
View File
@@ -39,6 +39,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
# Load completions in the current shell
source <(sbx completion bash)
data/sbx_cli/sbx_completion_fish.yaml
+4
View File
@@ -30,6 +30,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
# Load completions in the current shell
sbx completion fish | source
data/sbx_cli/sbx_completion_powershell.yaml
+4
View File
@@ -27,6 +27,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
# Load completions in the current session
sbx completion powershell | Out-String | Invoke-Expression
data/sbx_cli/sbx_completion_zsh.yaml
+4
View File
@@ -41,6 +41,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
# Load completions in the current shell
source <(sbx completion zsh)
data/sbx_cli/sbx_cp.yaml
+16 -4
View File
@@ -6,19 +6,27 @@ description: |-
ID (sbx_*) or name from "sbx --cloud ls". Cloud transfers go through the Docker
Sandboxes Cloud file API instead of the local sandboxd.
Cloud copies transfer files, not symbolic links or empty directories. A symbolic
link passed as SRC is always followed on upload. Links inside an uploaded
directory are skipped unless --follow-link is set. On download, --follow-link
follows SRC only when it names a symbolic link to a file. Downloads of directories
skip symbolic links even with --follow-link.
When copying a directory, the directory itself is placed at the destination.
If the destination path does not exist it is created; if it already exists
as a directory, the source is placed inside it.
When a local path is inside a sandbox workspace, sbx cp refuses symbolic
links that lead out of the workspace, even with --follow-link, including
when the workspace is reached through a symbolic link or junction to it.
For local paths inside workspace directories or other host directories mounted
into the sandbox, sbx cp refuses symbolic links that escape those directories,
even with --follow-link, including when a directory is reached through a
symbolic link, junction or substituted drive.
usage: sbx cp SRC DST [flags]
options:
- name: follow-link
shorthand: L
default_value: "false"
usage: Follow symbolic links in the source path
usage: |
Follow symbolic links in the source path (cloud: does not follow links inside downloaded directories)
- name: help
shorthand: h
default_value: "false"
@@ -32,6 +40,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
# Copy a file from host to sandbox
sbx cp ./config.json my-sandbox:/home/user/
data/sbx_cli/sbx_create.yaml
+10 -11
View File
@@ -7,7 +7,7 @@ description: |-
reference. Sandbox kit references may be local directories, ZIP files, git
repositories, or OCI references. Relative local references must be explicit
paths such as ./my-kit or ../my-kit.zip. A kit.shortcuts.<agent> setting
(sbx settings set kit.shortcuts.claude sbx/claude:latest) makes that agent name
(sbx settings set kit.shortcuts.claude myorg/claude:latest) makes that agent name
resolve to the configured kit reference instead for local sandboxes; cloud
sandboxes ignore it.
@@ -82,7 +82,7 @@ options:
- name: memory
shorthand: m
usage: |
Memory limit in binary units (e.g., 512m, 8g). Minimum: 512 MiB. Default: 50% of host memory, clamped to 512 MiB–32 GiB. Maximum: max(75% of host memory, 512 MiB)
Memory limit in binary units (e.g., 512m, 8g). Minimum: 512 MiB. Default: 50% of host memory, clamped to 512 MiB–32 GiB. Maximum: host memory. Warns above 75% of host memory
- name: mount
default_value: '[]'
usage: |
@@ -113,7 +113,7 @@ options:
- name: static-mcp
default_value: '[]'
usage: |
MCP server names that form the sandbox's fixed (static) MCP set. Accepts a comma-separated list (--static-mcp notion,atlassian), repeated flags (--static-mcp notion --static-mcp atlassian), or a mix; all forms accumulate into the same set. The set is chosen once at creation time. Local sandboxes take names registered with 'sbx mcp add'. Cloud sandboxes resolve names on the cloud MCP gateway.
MCP server names that form the sandbox's fixed (static) MCP set. Accepts a comma-separated list (--static-mcp notion,atlassian), repeated flags (--static-mcp notion --static-mcp atlassian), or a mix; all forms accumulate into the same set. Use none for a static set with no servers, local sandboxes only. The set is chosen once at creation time. Local sandboxes take names registered with 'sbx mcp add'. Cloud sandboxes resolve names on the cloud MCP gateway.
- name: template
shorthand: t
usage: |
@@ -136,6 +136,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
# Create a sandbox for Claude in the current directory
sbx create claude .
@@ -146,6 +150,9 @@ example: |4-
# Create with additional read-only workspaces
sbx create claude . /path/to/docs:ro
# Mount an additional workspace at a chosen path inside the sandbox
sbx create claude . /path/to/data:/workspace/data
# Create without a workspace bind mount
sbx create claude
@@ -168,11 +175,3 @@ example: |4-
sbx --cloud create -t TEMPLATE
see_also:
- sbx - Manage AI coding agent sandboxes.
- sbx create claude - Create a sandbox for claude
- sbx create codex - Create a sandbox for codex
- sbx create cursor - Create a sandbox for cursor
- sbx create devin - Create a sandbox for devin
- sbx create docker-agent - Create a sandbox for docker-agent
- sbx create gemini - Create a sandbox for gemini
- sbx create opencode - Create a sandbox for opencode
- sbx create shell - Create a sandbox for shell
data/sbx_cli/sbx_create_claude.yaml
-156
View File
@@ -1,156 +0,0 @@
name: sbx create claude
synopsis: Create a sandbox for claude
description: |-
Create a sandbox with access to a host workspace for claude.
The workspace path is mounted inside the sandbox at the same path as on the
host. Additional workspaces can be provided as extra arguments. Append ":ro" to
mount them read-only; a read-only argument may name a single file, which holds
that one path out of reach inside a workspace the sandbox can otherwise write.
Omit the path to create a sandbox without a workspace bind mount: the agent
then works in the container's own filesystem instead of on your files.
Use "sbx run --name SANDBOX" to attach to the agent after creation.
With --cloud:
Create a cloud sandbox for claude.
Cloud sandboxes have no host workspace, so no path follows the agent. Sizing
comes from --cpus and --memory and must land on a billable shape; without them
a cloud sandbox gets 2 CPUs and 4 GiB. A template named with -t / --template
must already exist in the cloud registry.
Cloud sandboxes use cloud network policies. Host network and HTTP policies
do not apply. Set cloud account defaults with
"sbx --cloud policy init <allow-all|balanced|deny-all>".
Use "sbx --cloud run <agent> --name SANDBOX" to attach to the agent after
creation: cloud needs the agent, since a name alone is not a unique handle.
usage: sbx create claude [PATH...] [flags]
options:
- name: help
shorthand: h
default_value: "false"
usage: help for claude
inherited_options:
- name: allow-network
usage: |
Network pattern to allow for cloud sandbox egress (cloud only; can be specified multiple times)
- name: clone
default_value: "false"
usage: |
Run the agent on a private in-container clone of the host Git repository (mounted read-only) instead of bind-mounting the workspace; the agent's commits are accessible via the sandbox-<name> git remote on the host
- name: cloud
default_value: "false"
usage: |
Dispatch to Docker Cloud Sandboxes API instead of local sandboxd (supported by a growing set of verbs — run 'sbx --cloud --help' for the current list)
- name: cpus
default_value: "0"
usage: |
Number of CPUs to allocate to the sandbox (0 = auto: all host CPUs, at most 16 on Linux arm64)
- name: debug
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: deny-network
usage: |
Add a per-sandbox network deny rule at creation time. Can be specified multiple times. The rule applies only to the new sandbox and can be listed or removed later with 'sbx policy ls <NAME>' or 'sbx policy rm network --sandbox <NAME> --resource <HOST>'. Safe under centralized governance because a local deny can only narrow, never widen, egress.
- name: env
shorthand: e
default_value: '[]'
usage: |
Set an environment variable in the sandbox (can be repeated): KEY=VALUE, or a bare KEY to take the value from the current environment
- name: env-file
default_value: '[]'
usage: |
Read environment variables from a file (can be repeated). --env wins over any file; a later file wins over an earlier one
- name: image-ref
usage: |
OCI image reference for inline-mode cloud create (mutually exclusive with --template; requires --cpus and --memory)
- name: kit
default_value: '[]'
experimental: true
usage: |
Additional kit reference (must be a mixin; directory, ZIP, git, or OCI). Can be specified multiple times
- name: kit-arg
default_value: '[]'
experimental: true
usage: |
Value for an argument the kit declares, as name=value for every kit or kit.name=value for one (can be repeated)
- name: kit-args-file
default_value: '[]'
experimental: true
usage: |
File of name=value kit arguments, one per line (can be repeated); --kit-arg overrides
- name: memory
shorthand: m
usage: |
Memory limit in binary units (e.g., 512m, 8g). Minimum: 512 MiB. Default: 50% of host memory, clamped to 512 MiB–32 GiB. Maximum: max(75% of host memory, 512 MiB)
- name: mount
default_value: '[]'
usage: |
Bind a host directory to a kit host-mount@1 path (can be repeated): HOST:SANDBOX_PATH. Can only be used when creating a new sandbox.
- name: name
usage: |
Name for the sandbox (defaults to <agent>-<workdir>; at least two characters, starting with a letter or number, containing only letters, numbers, hyphens and periods (periods are rejected with --cloud); 'default' is reserved)
- name: no-progress
default_value: "false"
usage: Suppress progress output
- name: on-timeout
usage: |
What happens when --ttl lapses: 'stop' stops the sandbox in place so it can be started again later, 'restart' keeps it running by stopping and immediately starting it, or 'delete' removes it. Omit the flag and the server stops the sandbox when it can be started again later, and deletes it otherwise. With 'restart' a supplied --ttl must be at least 1h (cloud only).
- name: platform
usage: |
Target platform: linux/amd64 or linux/arm64 (cloud only). With --image-ref, omitting it lets the server resolve the platform from the image and the CLI sends the local CPU as a hint for multi-platform images. With --template, omitting it inherits the template platform. With a sandbox kit, the kit's template is built for this platform and cached apart from other platforms; omitting it keeps the server's choice.
- name: publish
shorthand: p
default_value: '[]'
usage: |
Publish a sandbox port to the host (can be repeated): [[HOST_IP:]HOST_PORT:]SANDBOX_PORT[/PROTOCOL]
- name: pull
usage: |
Image pull policy (always|missing|never; default: never for saved local snapshots, missing for v3 kit compositions, otherwise always)
- name: skills
usage: |
Shared skills store mode for the agent's skills directory (e.g. ~/.claude/skills): off, readonly (store linked in read-only, directory stays writable), or readwrite (store mounted over it, writes are shared). Default: readonly, or the configured skills.defaultMode setting.
- name: static-mcp
default_value: '[]'
usage: |
MCP server names that form the sandbox's fixed (static) MCP set. Accepts a comma-separated list (--static-mcp notion,atlassian), repeated flags (--static-mcp notion --static-mcp atlassian), or a mix; all forms accumulate into the same set. The set is chosen once at creation time. Local sandboxes take names registered with 'sbx mcp add'. Cloud sandboxes resolve names on the cloud MCP gateway.
- name: template
shorthand: t
usage: |
Container image to use for the sandbox (default: agent-specific image)
- name: ttl
usage: |
Cloud sandbox time-to-live before it times out (e.g. 30m, 2h, 1h30m; units are case-insensitive; cloud only; default: server-side)
- name: volume
shorthand: v
default_value: '[]'
experimental: true
usage: |
Attach an existing persistent volume, NAME:MOUNTPATH (cloud only, experimental; repeatable)
example: |4-
# Create in the current directory
sbx create claude .
# Create with a specific path
sbx create claude /path/to/project
# Create with additional read-only workspaces
sbx create claude . /path/to/docs:ro
# Create without a workspace bind mount
sbx create claude
# Create a cloud sandbox for claude
sbx --cloud create claude
# Create a named cloud sandbox with a mixin baked in
sbx --cloud create --name my-project claude --kit ./my-mixin/
# Create from a template that already exists in the cloud registry
sbx --cloud create -t TEMPLATE
see_also:
- sbx create - Create a sandbox for an agent
data/sbx_cli/sbx_create_codex.yaml
-156
View File
@@ -1,156 +0,0 @@
name: sbx create codex
synopsis: Create a sandbox for codex
description: |-
Create a sandbox with access to a host workspace for codex.
The workspace path is mounted inside the sandbox at the same path as on the
host. Additional workspaces can be provided as extra arguments. Append ":ro" to
mount them read-only; a read-only argument may name a single file, which holds
that one path out of reach inside a workspace the sandbox can otherwise write.
Omit the path to create a sandbox without a workspace bind mount: the agent
then works in the container's own filesystem instead of on your files.
Use "sbx run --name SANDBOX" to attach to the agent after creation.
With --cloud:
Create a cloud sandbox for codex.
Cloud sandboxes have no host workspace, so no path follows the agent. Sizing
comes from --cpus and --memory and must land on a billable shape; without them
a cloud sandbox gets 2 CPUs and 4 GiB. A template named with -t / --template
must already exist in the cloud registry.
Cloud sandboxes use cloud network policies. Host network and HTTP policies
do not apply. Set cloud account defaults with
"sbx --cloud policy init <allow-all|balanced|deny-all>".
Use "sbx --cloud run <agent> --name SANDBOX" to attach to the agent after
creation: cloud needs the agent, since a name alone is not a unique handle.
usage: sbx create codex [PATH...] [flags]
options:
- name: help
shorthand: h
default_value: "false"
usage: help for codex
inherited_options:
- name: allow-network
usage: |
Network pattern to allow for cloud sandbox egress (cloud only; can be specified multiple times)
- name: clone
default_value: "false"
usage: |
Run the agent on a private in-container clone of the host Git repository (mounted read-only) instead of bind-mounting the workspace; the agent's commits are accessible via the sandbox-<name> git remote on the host
- name: cloud
default_value: "false"
usage: |
Dispatch to Docker Cloud Sandboxes API instead of local sandboxd (supported by a growing set of verbs — run 'sbx --cloud --help' for the current list)
- name: cpus
default_value: "0"
usage: |
Number of CPUs to allocate to the sandbox (0 = auto: all host CPUs, at most 16 on Linux arm64)
- name: debug
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: deny-network
usage: |
Add a per-sandbox network deny rule at creation time. Can be specified multiple times. The rule applies only to the new sandbox and can be listed or removed later with 'sbx policy ls <NAME>' or 'sbx policy rm network --sandbox <NAME> --resource <HOST>'. Safe under centralized governance because a local deny can only narrow, never widen, egress.
- name: env
shorthand: e
default_value: '[]'
usage: |
Set an environment variable in the sandbox (can be repeated): KEY=VALUE, or a bare KEY to take the value from the current environment
- name: env-file
default_value: '[]'
usage: |
Read environment variables from a file (can be repeated). --env wins over any file; a later file wins over an earlier one
- name: image-ref
usage: |
OCI image reference for inline-mode cloud create (mutually exclusive with --template; requires --cpus and --memory)
- name: kit
default_value: '[]'
experimental: true
usage: |
Additional kit reference (must be a mixin; directory, ZIP, git, or OCI). Can be specified multiple times
- name: kit-arg
default_value: '[]'
experimental: true
usage: |
Value for an argument the kit declares, as name=value for every kit or kit.name=value for one (can be repeated)
- name: kit-args-file
default_value: '[]'
experimental: true
usage: |
File of name=value kit arguments, one per line (can be repeated); --kit-arg overrides
- name: memory
shorthand: m
usage: |
Memory limit in binary units (e.g., 512m, 8g). Minimum: 512 MiB. Default: 50% of host memory, clamped to 512 MiB–32 GiB. Maximum: max(75% of host memory, 512 MiB)
- name: mount
default_value: '[]'
usage: |
Bind a host directory to a kit host-mount@1 path (can be repeated): HOST:SANDBOX_PATH. Can only be used when creating a new sandbox.
- name: name
usage: |
Name for the sandbox (defaults to <agent>-<workdir>; at least two characters, starting with a letter or number, containing only letters, numbers, hyphens and periods (periods are rejected with --cloud); 'default' is reserved)
- name: no-progress
default_value: "false"
usage: Suppress progress output
- name: on-timeout
usage: |
What happens when --ttl lapses: 'stop' stops the sandbox in place so it can be started again later, 'restart' keeps it running by stopping and immediately starting it, or 'delete' removes it. Omit the flag and the server stops the sandbox when it can be started again later, and deletes it otherwise. With 'restart' a supplied --ttl must be at least 1h (cloud only).
- name: platform
usage: |
Target platform: linux/amd64 or linux/arm64 (cloud only). With --image-ref, omitting it lets the server resolve the platform from the image and the CLI sends the local CPU as a hint for multi-platform images. With --template, omitting it inherits the template platform. With a sandbox kit, the kit's template is built for this platform and cached apart from other platforms; omitting it keeps the server's choice.
- name: publish
shorthand: p
default_value: '[]'
usage: |
Publish a sandbox port to the host (can be repeated): [[HOST_IP:]HOST_PORT:]SANDBOX_PORT[/PROTOCOL]
- name: pull
usage: |
Image pull policy (always|missing|never; default: never for saved local snapshots, missing for v3 kit compositions, otherwise always)
- name: skills
usage: |
Shared skills store mode for the agent's skills directory (e.g. ~/.claude/skills): off, readonly (store linked in read-only, directory stays writable), or readwrite (store mounted over it, writes are shared). Default: readonly, or the configured skills.defaultMode setting.
- name: static-mcp
default_value: '[]'
usage: |
MCP server names that form the sandbox's fixed (static) MCP set. Accepts a comma-separated list (--static-mcp notion,atlassian), repeated flags (--static-mcp notion --static-mcp atlassian), or a mix; all forms accumulate into the same set. The set is chosen once at creation time. Local sandboxes take names registered with 'sbx mcp add'. Cloud sandboxes resolve names on the cloud MCP gateway.
- name: template
shorthand: t
usage: |
Container image to use for the sandbox (default: agent-specific image)
- name: ttl
usage: |
Cloud sandbox time-to-live before it times out (e.g. 30m, 2h, 1h30m; units are case-insensitive; cloud only; default: server-side)
- name: volume
shorthand: v
default_value: '[]'
experimental: true
usage: |
Attach an existing persistent volume, NAME:MOUNTPATH (cloud only, experimental; repeatable)
example: |4-
# Create in the current directory
sbx create codex .
# Create with a specific path
sbx create codex /path/to/project
# Create with additional read-only workspaces
sbx create codex . /path/to/docs:ro
# Create without a workspace bind mount
sbx create codex
# Create a cloud sandbox for codex
sbx --cloud create codex
# Create a named cloud sandbox with a mixin baked in
sbx --cloud create --name my-project codex --kit ./my-mixin/
# Create from a template that already exists in the cloud registry
sbx --cloud create -t TEMPLATE
see_also:
- sbx create - Create a sandbox for an agent
data/sbx_cli/sbx_create_cursor.yaml
-156
View File
@@ -1,156 +0,0 @@
name: sbx create cursor
synopsis: Create a sandbox for cursor
description: |-
Create a sandbox with access to a host workspace for cursor.
The workspace path is mounted inside the sandbox at the same path as on the
host. Additional workspaces can be provided as extra arguments. Append ":ro" to
mount them read-only; a read-only argument may name a single file, which holds
that one path out of reach inside a workspace the sandbox can otherwise write.
Omit the path to create a sandbox without a workspace bind mount: the agent
then works in the container's own filesystem instead of on your files.
Use "sbx run --name SANDBOX" to attach to the agent after creation.
With --cloud:
Create a cloud sandbox for cursor.
Cloud sandboxes have no host workspace, so no path follows the agent. Sizing
comes from --cpus and --memory and must land on a billable shape; without them
a cloud sandbox gets 2 CPUs and 4 GiB. A template named with -t / --template
must already exist in the cloud registry.
Cloud sandboxes use cloud network policies. Host network and HTTP policies
do not apply. Set cloud account defaults with
"sbx --cloud policy init <allow-all|balanced|deny-all>".
Use "sbx --cloud run <agent> --name SANDBOX" to attach to the agent after
creation: cloud needs the agent, since a name alone is not a unique handle.
usage: sbx create cursor [PATH...] [flags]
options:
- name: help
shorthand: h
default_value: "false"
usage: help for cursor
inherited_options:
- name: allow-network
usage: |
Network pattern to allow for cloud sandbox egress (cloud only; can be specified multiple times)
- name: clone
default_value: "false"
usage: |
Run the agent on a private in-container clone of the host Git repository (mounted read-only) instead of bind-mounting the workspace; the agent's commits are accessible via the sandbox-<name> git remote on the host
- name: cloud
default_value: "false"
usage: |
Dispatch to Docker Cloud Sandboxes API instead of local sandboxd (supported by a growing set of verbs — run 'sbx --cloud --help' for the current list)
- name: cpus
default_value: "0"
usage: |
Number of CPUs to allocate to the sandbox (0 = auto: all host CPUs, at most 16 on Linux arm64)
- name: debug
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: deny-network
usage: |
Add a per-sandbox network deny rule at creation time. Can be specified multiple times. The rule applies only to the new sandbox and can be listed or removed later with 'sbx policy ls <NAME>' or 'sbx policy rm network --sandbox <NAME> --resource <HOST>'. Safe under centralized governance because a local deny can only narrow, never widen, egress.
- name: env
shorthand: e
default_value: '[]'
usage: |
Set an environment variable in the sandbox (can be repeated): KEY=VALUE, or a bare KEY to take the value from the current environment
- name: env-file
default_value: '[]'
usage: |
Read environment variables from a file (can be repeated). --env wins over any file; a later file wins over an earlier one
- name: image-ref
usage: |
OCI image reference for inline-mode cloud create (mutually exclusive with --template; requires --cpus and --memory)
- name: kit
default_value: '[]'
experimental: true
usage: |
Additional kit reference (must be a mixin; directory, ZIP, git, or OCI). Can be specified multiple times
- name: kit-arg
default_value: '[]'
experimental: true
usage: |
Value for an argument the kit declares, as name=value for every kit or kit.name=value for one (can be repeated)
- name: kit-args-file
default_value: '[]'
experimental: true
usage: |
File of name=value kit arguments, one per line (can be repeated); --kit-arg overrides
- name: memory
shorthand: m
usage: |
Memory limit in binary units (e.g., 512m, 8g). Minimum: 512 MiB. Default: 50% of host memory, clamped to 512 MiB–32 GiB. Maximum: max(75% of host memory, 512 MiB)
- name: mount
default_value: '[]'
usage: |
Bind a host directory to a kit host-mount@1 path (can be repeated): HOST:SANDBOX_PATH. Can only be used when creating a new sandbox.
- name: name
usage: |
Name for the sandbox (defaults to <agent>-<workdir>; at least two characters, starting with a letter or number, containing only letters, numbers, hyphens and periods (periods are rejected with --cloud); 'default' is reserved)
- name: no-progress
default_value: "false"
usage: Suppress progress output
- name: on-timeout
usage: |
What happens when --ttl lapses: 'stop' stops the sandbox in place so it can be started again later, 'restart' keeps it running by stopping and immediately starting it, or 'delete' removes it. Omit the flag and the server stops the sandbox when it can be started again later, and deletes it otherwise. With 'restart' a supplied --ttl must be at least 1h (cloud only).
- name: platform
usage: |
Target platform: linux/amd64 or linux/arm64 (cloud only). With --image-ref, omitting it lets the server resolve the platform from the image and the CLI sends the local CPU as a hint for multi-platform images. With --template, omitting it inherits the template platform. With a sandbox kit, the kit's template is built for this platform and cached apart from other platforms; omitting it keeps the server's choice.
- name: publish
shorthand: p
default_value: '[]'
usage: |
Publish a sandbox port to the host (can be repeated): [[HOST_IP:]HOST_PORT:]SANDBOX_PORT[/PROTOCOL]
- name: pull
usage: |
Image pull policy (always|missing|never; default: never for saved local snapshots, missing for v3 kit compositions, otherwise always)
- name: skills
usage: |
Shared skills store mode for the agent's skills directory (e.g. ~/.claude/skills): off, readonly (store linked in read-only, directory stays writable), or readwrite (store mounted over it, writes are shared). Default: readonly, or the configured skills.defaultMode setting.
- name: static-mcp
default_value: '[]'
usage: |
MCP server names that form the sandbox's fixed (static) MCP set. Accepts a comma-separated list (--static-mcp notion,atlassian), repeated flags (--static-mcp notion --static-mcp atlassian), or a mix; all forms accumulate into the same set. The set is chosen once at creation time. Local sandboxes take names registered with 'sbx mcp add'. Cloud sandboxes resolve names on the cloud MCP gateway.
- name: template
shorthand: t
usage: |
Container image to use for the sandbox (default: agent-specific image)
- name: ttl
usage: |
Cloud sandbox time-to-live before it times out (e.g. 30m, 2h, 1h30m; units are case-insensitive; cloud only; default: server-side)
- name: volume
shorthand: v
default_value: '[]'
experimental: true
usage: |
Attach an existing persistent volume, NAME:MOUNTPATH (cloud only, experimental; repeatable)
example: |4-
# Create in the current directory
sbx create cursor .
# Create with a specific path
sbx create cursor /path/to/project
# Create with additional read-only workspaces
sbx create cursor . /path/to/docs:ro
# Create without a workspace bind mount
sbx create cursor
# Create a cloud sandbox for cursor
sbx --cloud create cursor
# Create a named cloud sandbox with a mixin baked in
sbx --cloud create --name my-project cursor --kit ./my-mixin/
# Create from a template that already exists in the cloud registry
sbx --cloud create -t TEMPLATE
see_also:
- sbx create - Create a sandbox for an agent
data/sbx_cli/sbx_create_devin.yaml
-156
View File
@@ -1,156 +0,0 @@
name: sbx create devin
synopsis: Create a sandbox for devin
description: |-
Create a sandbox with access to a host workspace for devin.
The workspace path is mounted inside the sandbox at the same path as on the
host. Additional workspaces can be provided as extra arguments. Append ":ro" to
mount them read-only; a read-only argument may name a single file, which holds
that one path out of reach inside a workspace the sandbox can otherwise write.
Omit the path to create a sandbox without a workspace bind mount: the agent
then works in the container's own filesystem instead of on your files.
Use "sbx run --name SANDBOX" to attach to the agent after creation.
With --cloud:
Create a cloud sandbox for devin.
Cloud sandboxes have no host workspace, so no path follows the agent. Sizing
comes from --cpus and --memory and must land on a billable shape; without them
a cloud sandbox gets 2 CPUs and 4 GiB. A template named with -t / --template
must already exist in the cloud registry.
Cloud sandboxes use cloud network policies. Host network and HTTP policies
do not apply. Set cloud account defaults with
"sbx --cloud policy init <allow-all|balanced|deny-all>".
Use "sbx --cloud run <agent> --name SANDBOX" to attach to the agent after
creation: cloud needs the agent, since a name alone is not a unique handle.
usage: sbx create devin [PATH...] [flags]
options:
- name: help
shorthand: h
default_value: "false"
usage: help for devin
inherited_options:
- name: allow-network
usage: |
Network pattern to allow for cloud sandbox egress (cloud only; can be specified multiple times)
- name: clone
default_value: "false"
usage: |
Run the agent on a private in-container clone of the host Git repository (mounted read-only) instead of bind-mounting the workspace; the agent's commits are accessible via the sandbox-<name> git remote on the host
- name: cloud
default_value: "false"
usage: |
Dispatch to Docker Cloud Sandboxes API instead of local sandboxd (supported by a growing set of verbs — run 'sbx --cloud --help' for the current list)
- name: cpus
default_value: "0"
usage: |
Number of CPUs to allocate to the sandbox (0 = auto: all host CPUs, at most 16 on Linux arm64)
- name: debug
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: deny-network
usage: |
Add a per-sandbox network deny rule at creation time. Can be specified multiple times. The rule applies only to the new sandbox and can be listed or removed later with 'sbx policy ls <NAME>' or 'sbx policy rm network --sandbox <NAME> --resource <HOST>'. Safe under centralized governance because a local deny can only narrow, never widen, egress.
- name: env
shorthand: e
default_value: '[]'
usage: |
Set an environment variable in the sandbox (can be repeated): KEY=VALUE, or a bare KEY to take the value from the current environment
- name: env-file
default_value: '[]'
usage: |
Read environment variables from a file (can be repeated). --env wins over any file; a later file wins over an earlier one
- name: image-ref
usage: |
OCI image reference for inline-mode cloud create (mutually exclusive with --template; requires --cpus and --memory)
- name: kit
default_value: '[]'
experimental: true
usage: |
Additional kit reference (must be a mixin; directory, ZIP, git, or OCI). Can be specified multiple times
- name: kit-arg
default_value: '[]'
experimental: true
usage: |
Value for an argument the kit declares, as name=value for every kit or kit.name=value for one (can be repeated)
- name: kit-args-file
default_value: '[]'
experimental: true
usage: |
File of name=value kit arguments, one per line (can be repeated); --kit-arg overrides
- name: memory
shorthand: m
usage: |
Memory limit in binary units (e.g., 512m, 8g). Minimum: 512 MiB. Default: 50% of host memory, clamped to 512 MiB–32 GiB. Maximum: max(75% of host memory, 512 MiB)
- name: mount
default_value: '[]'
usage: |
Bind a host directory to a kit host-mount@1 path (can be repeated): HOST:SANDBOX_PATH. Can only be used when creating a new sandbox.
- name: name
usage: |
Name for the sandbox (defaults to <agent>-<workdir>; at least two characters, starting with a letter or number, containing only letters, numbers, hyphens and periods (periods are rejected with --cloud); 'default' is reserved)
- name: no-progress
default_value: "false"
usage: Suppress progress output
- name: on-timeout
usage: |
What happens when --ttl lapses: 'stop' stops the sandbox in place so it can be started again later, 'restart' keeps it running by stopping and immediately starting it, or 'delete' removes it. Omit the flag and the server stops the sandbox when it can be started again later, and deletes it otherwise. With 'restart' a supplied --ttl must be at least 1h (cloud only).
- name: platform
usage: |
Target platform: linux/amd64 or linux/arm64 (cloud only). With --image-ref, omitting it lets the server resolve the platform from the image and the CLI sends the local CPU as a hint for multi-platform images. With --template, omitting it inherits the template platform. With a sandbox kit, the kit's template is built for this platform and cached apart from other platforms; omitting it keeps the server's choice.
- name: publish
shorthand: p
default_value: '[]'
usage: |
Publish a sandbox port to the host (can be repeated): [[HOST_IP:]HOST_PORT:]SANDBOX_PORT[/PROTOCOL]
- name: pull
usage: |
Image pull policy (always|missing|never; default: never for saved local snapshots, missing for v3 kit compositions, otherwise always)
- name: skills
usage: |
Shared skills store mode for the agent's skills directory (e.g. ~/.claude/skills): off, readonly (store linked in read-only, directory stays writable), or readwrite (store mounted over it, writes are shared). Default: readonly, or the configured skills.defaultMode setting.
- name: static-mcp
default_value: '[]'
usage: |
MCP server names that form the sandbox's fixed (static) MCP set. Accepts a comma-separated list (--static-mcp notion,atlassian), repeated flags (--static-mcp notion --static-mcp atlassian), or a mix; all forms accumulate into the same set. The set is chosen once at creation time. Local sandboxes take names registered with 'sbx mcp add'. Cloud sandboxes resolve names on the cloud MCP gateway.
- name: template
shorthand: t
usage: |
Container image to use for the sandbox (default: agent-specific image)
- name: ttl
usage: |
Cloud sandbox time-to-live before it times out (e.g. 30m, 2h, 1h30m; units are case-insensitive; cloud only; default: server-side)
- name: volume
shorthand: v
default_value: '[]'
experimental: true
usage: |
Attach an existing persistent volume, NAME:MOUNTPATH (cloud only, experimental; repeatable)
example: |4-
# Create in the current directory
sbx create devin .
# Create with a specific path
sbx create devin /path/to/project
# Create with additional read-only workspaces
sbx create devin . /path/to/docs:ro
# Create without a workspace bind mount
sbx create devin
# Create a cloud sandbox for devin
sbx --cloud create devin
# Create a named cloud sandbox with a mixin baked in
sbx --cloud create --name my-project devin --kit ./my-mixin/
# Create from a template that already exists in the cloud registry
sbx --cloud create -t TEMPLATE
see_also:
- sbx create - Create a sandbox for an agent
data/sbx_cli/sbx_create_docker-agent.yaml
-156
View File
@@ -1,156 +0,0 @@
name: sbx create docker-agent
synopsis: Create a sandbox for docker-agent
description: |-
Create a sandbox with access to a host workspace for docker-agent.
The workspace path is mounted inside the sandbox at the same path as on the
host. Additional workspaces can be provided as extra arguments. Append ":ro" to
mount them read-only; a read-only argument may name a single file, which holds
that one path out of reach inside a workspace the sandbox can otherwise write.
Omit the path to create a sandbox without a workspace bind mount: the agent
then works in the container's own filesystem instead of on your files.
Use "sbx run --name SANDBOX" to attach to the agent after creation.
With --cloud:
Create a cloud sandbox for docker-agent.
Cloud sandboxes have no host workspace, so no path follows the agent. Sizing
comes from --cpus and --memory and must land on a billable shape; without them
a cloud sandbox gets 2 CPUs and 4 GiB. A template named with -t / --template
must already exist in the cloud registry.
Cloud sandboxes use cloud network policies. Host network and HTTP policies
do not apply. Set cloud account defaults with
"sbx --cloud policy init <allow-all|balanced|deny-all>".
Use "sbx --cloud run <agent> --name SANDBOX" to attach to the agent after
creation: cloud needs the agent, since a name alone is not a unique handle.
usage: sbx create docker-agent [PATH...] [flags]
options:
- name: help
shorthand: h
default_value: "false"
usage: help for docker-agent
inherited_options:
- name: allow-network
usage: |
Network pattern to allow for cloud sandbox egress (cloud only; can be specified multiple times)
- name: clone
default_value: "false"
usage: |
Run the agent on a private in-container clone of the host Git repository (mounted read-only) instead of bind-mounting the workspace; the agent's commits are accessible via the sandbox-<name> git remote on the host
- name: cloud
default_value: "false"
usage: |
Dispatch to Docker Cloud Sandboxes API instead of local sandboxd (supported by a growing set of verbs — run 'sbx --cloud --help' for the current list)
- name: cpus
default_value: "0"
usage: |
Number of CPUs to allocate to the sandbox (0 = auto: all host CPUs, at most 16 on Linux arm64)
- name: debug
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: deny-network
usage: |
Add a per-sandbox network deny rule at creation time. Can be specified multiple times. The rule applies only to the new sandbox and can be listed or removed later with 'sbx policy ls <NAME>' or 'sbx policy rm network --sandbox <NAME> --resource <HOST>'. Safe under centralized governance because a local deny can only narrow, never widen, egress.
- name: env
shorthand: e
default_value: '[]'
usage: |
Set an environment variable in the sandbox (can be repeated): KEY=VALUE, or a bare KEY to take the value from the current environment
- name: env-file
default_value: '[]'
usage: |
Read environment variables from a file (can be repeated). --env wins over any file; a later file wins over an earlier one
- name: image-ref
usage: |
OCI image reference for inline-mode cloud create (mutually exclusive with --template; requires --cpus and --memory)
- name: kit
default_value: '[]'
experimental: true
usage: |
Additional kit reference (must be a mixin; directory, ZIP, git, or OCI). Can be specified multiple times
- name: kit-arg
default_value: '[]'
experimental: true
usage: |
Value for an argument the kit declares, as name=value for every kit or kit.name=value for one (can be repeated)
- name: kit-args-file
default_value: '[]'
experimental: true
usage: |
File of name=value kit arguments, one per line (can be repeated); --kit-arg overrides
- name: memory
shorthand: m
usage: |
Memory limit in binary units (e.g., 512m, 8g). Minimum: 512 MiB. Default: 50% of host memory, clamped to 512 MiB–32 GiB. Maximum: max(75% of host memory, 512 MiB)
- name: mount
default_value: '[]'
usage: |
Bind a host directory to a kit host-mount@1 path (can be repeated): HOST:SANDBOX_PATH. Can only be used when creating a new sandbox.
- name: name
usage: |
Name for the sandbox (defaults to <agent>-<workdir>; at least two characters, starting with a letter or number, containing only letters, numbers, hyphens and periods (periods are rejected with --cloud); 'default' is reserved)
- name: no-progress
default_value: "false"
usage: Suppress progress output
- name: on-timeout
usage: |
What happens when --ttl lapses: 'stop' stops the sandbox in place so it can be started again later, 'restart' keeps it running by stopping and immediately starting it, or 'delete' removes it. Omit the flag and the server stops the sandbox when it can be started again later, and deletes it otherwise. With 'restart' a supplied --ttl must be at least 1h (cloud only).
- name: platform
usage: |
Target platform: linux/amd64 or linux/arm64 (cloud only). With --image-ref, omitting it lets the server resolve the platform from the image and the CLI sends the local CPU as a hint for multi-platform images. With --template, omitting it inherits the template platform. With a sandbox kit, the kit's template is built for this platform and cached apart from other platforms; omitting it keeps the server's choice.
- name: publish
shorthand: p
default_value: '[]'
usage: |
Publish a sandbox port to the host (can be repeated): [[HOST_IP:]HOST_PORT:]SANDBOX_PORT[/PROTOCOL]
- name: pull
usage: |
Image pull policy (always|missing|never; default: never for saved local snapshots, missing for v3 kit compositions, otherwise always)
- name: skills
usage: |
Shared skills store mode for the agent's skills directory (e.g. ~/.claude/skills): off, readonly (store linked in read-only, directory stays writable), or readwrite (store mounted over it, writes are shared). Default: readonly, or the configured skills.defaultMode setting.
- name: static-mcp
default_value: '[]'
usage: |
MCP server names that form the sandbox's fixed (static) MCP set. Accepts a comma-separated list (--static-mcp notion,atlassian), repeated flags (--static-mcp notion --static-mcp atlassian), or a mix; all forms accumulate into the same set. The set is chosen once at creation time. Local sandboxes take names registered with 'sbx mcp add'. Cloud sandboxes resolve names on the cloud MCP gateway.
- name: template
shorthand: t
usage: |
Container image to use for the sandbox (default: agent-specific image)
- name: ttl
usage: |
Cloud sandbox time-to-live before it times out (e.g. 30m, 2h, 1h30m; units are case-insensitive; cloud only; default: server-side)
- name: volume
shorthand: v
default_value: '[]'
experimental: true
usage: |
Attach an existing persistent volume, NAME:MOUNTPATH (cloud only, experimental; repeatable)
example: |4-
# Create in the current directory
sbx create docker-agent .
# Create with a specific path
sbx create docker-agent /path/to/project
# Create with additional read-only workspaces
sbx create docker-agent . /path/to/docs:ro
# Create without a workspace bind mount
sbx create docker-agent
# Create a cloud sandbox for docker-agent
sbx --cloud create docker-agent
# Create a named cloud sandbox with a mixin baked in
sbx --cloud create --name my-project docker-agent --kit ./my-mixin/
# Create from a template that already exists in the cloud registry
sbx --cloud create -t TEMPLATE
see_also:
- sbx create - Create a sandbox for an agent
data/sbx_cli/sbx_create_gemini.yaml
-156
View File
@@ -1,156 +0,0 @@
name: sbx create gemini
synopsis: Create a sandbox for gemini
description: |-
Create a sandbox with access to a host workspace for gemini.
The workspace path is mounted inside the sandbox at the same path as on the
host. Additional workspaces can be provided as extra arguments. Append ":ro" to
mount them read-only; a read-only argument may name a single file, which holds
that one path out of reach inside a workspace the sandbox can otherwise write.
Omit the path to create a sandbox without a workspace bind mount: the agent
then works in the container's own filesystem instead of on your files.
Use "sbx run --name SANDBOX" to attach to the agent after creation.
With --cloud:
Create a cloud sandbox for gemini.
Cloud sandboxes have no host workspace, so no path follows the agent. Sizing
comes from --cpus and --memory and must land on a billable shape; without them
a cloud sandbox gets 2 CPUs and 4 GiB. A template named with -t / --template
must already exist in the cloud registry.
Cloud sandboxes use cloud network policies. Host network and HTTP policies
do not apply. Set cloud account defaults with
"sbx --cloud policy init <allow-all|balanced|deny-all>".
Use "sbx --cloud run <agent> --name SANDBOX" to attach to the agent after
creation: cloud needs the agent, since a name alone is not a unique handle.
usage: sbx create gemini [PATH...] [flags]
options:
- name: help
shorthand: h
default_value: "false"
usage: help for gemini
inherited_options:
- name: allow-network
usage: |
Network pattern to allow for cloud sandbox egress (cloud only; can be specified multiple times)
- name: clone
default_value: "false"
usage: |
Run the agent on a private in-container clone of the host Git repository (mounted read-only) instead of bind-mounting the workspace; the agent's commits are accessible via the sandbox-<name> git remote on the host
- name: cloud
default_value: "false"
usage: |
Dispatch to Docker Cloud Sandboxes API instead of local sandboxd (supported by a growing set of verbs — run 'sbx --cloud --help' for the current list)
- name: cpus
default_value: "0"
usage: |
Number of CPUs to allocate to the sandbox (0 = auto: all host CPUs, at most 16 on Linux arm64)
- name: debug
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: deny-network
usage: |
Add a per-sandbox network deny rule at creation time. Can be specified multiple times. The rule applies only to the new sandbox and can be listed or removed later with 'sbx policy ls <NAME>' or 'sbx policy rm network --sandbox <NAME> --resource <HOST>'. Safe under centralized governance because a local deny can only narrow, never widen, egress.
- name: env
shorthand: e
default_value: '[]'
usage: |
Set an environment variable in the sandbox (can be repeated): KEY=VALUE, or a bare KEY to take the value from the current environment
- name: env-file
default_value: '[]'
usage: |
Read environment variables from a file (can be repeated). --env wins over any file; a later file wins over an earlier one
- name: image-ref
usage: |
OCI image reference for inline-mode cloud create (mutually exclusive with --template; requires --cpus and --memory)
- name: kit
default_value: '[]'
experimental: true
usage: |
Additional kit reference (must be a mixin; directory, ZIP, git, or OCI). Can be specified multiple times
- name: kit-arg
default_value: '[]'
experimental: true
usage: |
Value for an argument the kit declares, as name=value for every kit or kit.name=value for one (can be repeated)
- name: kit-args-file
default_value: '[]'
experimental: true
usage: |
File of name=value kit arguments, one per line (can be repeated); --kit-arg overrides
- name: memory
shorthand: m
usage: |
Memory limit in binary units (e.g., 512m, 8g). Minimum: 512 MiB. Default: 50% of host memory, clamped to 512 MiB–32 GiB. Maximum: max(75% of host memory, 512 MiB)
- name: mount
default_value: '[]'
usage: |
Bind a host directory to a kit host-mount@1 path (can be repeated): HOST:SANDBOX_PATH. Can only be used when creating a new sandbox.
- name: name
usage: |
Name for the sandbox (defaults to <agent>-<workdir>; at least two characters, starting with a letter or number, containing only letters, numbers, hyphens and periods (periods are rejected with --cloud); 'default' is reserved)
- name: no-progress
default_value: "false"
usage: Suppress progress output
- name: on-timeout
usage: |
What happens when --ttl lapses: 'stop' stops the sandbox in place so it can be started again later, 'restart' keeps it running by stopping and immediately starting it, or 'delete' removes it. Omit the flag and the server stops the sandbox when it can be started again later, and deletes it otherwise. With 'restart' a supplied --ttl must be at least 1h (cloud only).
- name: platform
usage: |
Target platform: linux/amd64 or linux/arm64 (cloud only). With --image-ref, omitting it lets the server resolve the platform from the image and the CLI sends the local CPU as a hint for multi-platform images. With --template, omitting it inherits the template platform. With a sandbox kit, the kit's template is built for this platform and cached apart from other platforms; omitting it keeps the server's choice.
- name: publish
shorthand: p
default_value: '[]'
usage: |
Publish a sandbox port to the host (can be repeated): [[HOST_IP:]HOST_PORT:]SANDBOX_PORT[/PROTOCOL]
- name: pull
usage: |
Image pull policy (always|missing|never; default: never for saved local snapshots, missing for v3 kit compositions, otherwise always)
- name: skills
usage: |
Shared skills store mode for the agent's skills directory (e.g. ~/.claude/skills): off, readonly (store linked in read-only, directory stays writable), or readwrite (store mounted over it, writes are shared). Default: readonly, or the configured skills.defaultMode setting.
- name: static-mcp
default_value: '[]'
usage: |
MCP server names that form the sandbox's fixed (static) MCP set. Accepts a comma-separated list (--static-mcp notion,atlassian), repeated flags (--static-mcp notion --static-mcp atlassian), or a mix; all forms accumulate into the same set. The set is chosen once at creation time. Local sandboxes take names registered with 'sbx mcp add'. Cloud sandboxes resolve names on the cloud MCP gateway.
- name: template
shorthand: t
usage: |
Container image to use for the sandbox (default: agent-specific image)
- name: ttl
usage: |
Cloud sandbox time-to-live before it times out (e.g. 30m, 2h, 1h30m; units are case-insensitive; cloud only; default: server-side)
- name: volume
shorthand: v
default_value: '[]'
experimental: true
usage: |
Attach an existing persistent volume, NAME:MOUNTPATH (cloud only, experimental; repeatable)
example: |4-
# Create in the current directory
sbx create gemini .
# Create with a specific path
sbx create gemini /path/to/project
# Create with additional read-only workspaces
sbx create gemini . /path/to/docs:ro
# Create without a workspace bind mount
sbx create gemini
# Create a cloud sandbox for gemini
sbx --cloud create gemini
# Create a named cloud sandbox with a mixin baked in
sbx --cloud create --name my-project gemini --kit ./my-mixin/
# Create from a template that already exists in the cloud registry
sbx --cloud create -t TEMPLATE
see_also:
- sbx create - Create a sandbox for an agent
data/sbx_cli/sbx_create_opencode.yaml
-156
View File
@@ -1,156 +0,0 @@
name: sbx create opencode
synopsis: Create a sandbox for opencode
description: |-
Create a sandbox with access to a host workspace for opencode.
The workspace path is mounted inside the sandbox at the same path as on the
host. Additional workspaces can be provided as extra arguments. Append ":ro" to
mount them read-only; a read-only argument may name a single file, which holds
that one path out of reach inside a workspace the sandbox can otherwise write.
Omit the path to create a sandbox without a workspace bind mount: the agent
then works in the container's own filesystem instead of on your files.
Use "sbx run --name SANDBOX" to attach to the agent after creation.
With --cloud:
Create a cloud sandbox for opencode.
Cloud sandboxes have no host workspace, so no path follows the agent. Sizing
comes from --cpus and --memory and must land on a billable shape; without them
a cloud sandbox gets 2 CPUs and 4 GiB. A template named with -t / --template
must already exist in the cloud registry.
Cloud sandboxes use cloud network policies. Host network and HTTP policies
do not apply. Set cloud account defaults with
"sbx --cloud policy init <allow-all|balanced|deny-all>".
Use "sbx --cloud run <agent> --name SANDBOX" to attach to the agent after
creation: cloud needs the agent, since a name alone is not a unique handle.
usage: sbx create opencode [PATH...] [flags]
options:
- name: help
shorthand: h
default_value: "false"
usage: help for opencode
inherited_options:
- name: allow-network
usage: |
Network pattern to allow for cloud sandbox egress (cloud only; can be specified multiple times)
- name: clone
default_value: "false"
usage: |
Run the agent on a private in-container clone of the host Git repository (mounted read-only) instead of bind-mounting the workspace; the agent's commits are accessible via the sandbox-<name> git remote on the host
- name: cloud
default_value: "false"
usage: |
Dispatch to Docker Cloud Sandboxes API instead of local sandboxd (supported by a growing set of verbs — run 'sbx --cloud --help' for the current list)
- name: cpus
default_value: "0"
usage: |
Number of CPUs to allocate to the sandbox (0 = auto: all host CPUs, at most 16 on Linux arm64)
- name: debug
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: deny-network
usage: |
Add a per-sandbox network deny rule at creation time. Can be specified multiple times. The rule applies only to the new sandbox and can be listed or removed later with 'sbx policy ls <NAME>' or 'sbx policy rm network --sandbox <NAME> --resource <HOST>'. Safe under centralized governance because a local deny can only narrow, never widen, egress.
- name: env
shorthand: e
default_value: '[]'
usage: |
Set an environment variable in the sandbox (can be repeated): KEY=VALUE, or a bare KEY to take the value from the current environment
- name: env-file
default_value: '[]'
usage: |
Read environment variables from a file (can be repeated). --env wins over any file; a later file wins over an earlier one
- name: image-ref
usage: |
OCI image reference for inline-mode cloud create (mutually exclusive with --template; requires --cpus and --memory)
- name: kit
default_value: '[]'
experimental: true
usage: |
Additional kit reference (must be a mixin; directory, ZIP, git, or OCI). Can be specified multiple times
- name: kit-arg
default_value: '[]'
experimental: true
usage: |
Value for an argument the kit declares, as name=value for every kit or kit.name=value for one (can be repeated)
- name: kit-args-file
default_value: '[]'
experimental: true
usage: |
File of name=value kit arguments, one per line (can be repeated); --kit-arg overrides
- name: memory
shorthand: m
usage: |
Memory limit in binary units (e.g., 512m, 8g). Minimum: 512 MiB. Default: 50% of host memory, clamped to 512 MiB–32 GiB. Maximum: max(75% of host memory, 512 MiB)
- name: mount
default_value: '[]'
usage: |
Bind a host directory to a kit host-mount@1 path (can be repeated): HOST:SANDBOX_PATH. Can only be used when creating a new sandbox.
- name: name
usage: |
Name for the sandbox (defaults to <agent>-<workdir>; at least two characters, starting with a letter or number, containing only letters, numbers, hyphens and periods (periods are rejected with --cloud); 'default' is reserved)
- name: no-progress
default_value: "false"
usage: Suppress progress output
- name: on-timeout
usage: |
What happens when --ttl lapses: 'stop' stops the sandbox in place so it can be started again later, 'restart' keeps it running by stopping and immediately starting it, or 'delete' removes it. Omit the flag and the server stops the sandbox when it can be started again later, and deletes it otherwise. With 'restart' a supplied --ttl must be at least 1h (cloud only).
- name: platform
usage: |
Target platform: linux/amd64 or linux/arm64 (cloud only). With --image-ref, omitting it lets the server resolve the platform from the image and the CLI sends the local CPU as a hint for multi-platform images. With --template, omitting it inherits the template platform. With a sandbox kit, the kit's template is built for this platform and cached apart from other platforms; omitting it keeps the server's choice.
- name: publish
shorthand: p
default_value: '[]'
usage: |
Publish a sandbox port to the host (can be repeated): [[HOST_IP:]HOST_PORT:]SANDBOX_PORT[/PROTOCOL]
- name: pull
usage: |
Image pull policy (always|missing|never; default: never for saved local snapshots, missing for v3 kit compositions, otherwise always)
- name: skills
usage: |
Shared skills store mode for the agent's skills directory (e.g. ~/.claude/skills): off, readonly (store linked in read-only, directory stays writable), or readwrite (store mounted over it, writes are shared). Default: readonly, or the configured skills.defaultMode setting.
- name: static-mcp
default_value: '[]'
usage: |
MCP server names that form the sandbox's fixed (static) MCP set. Accepts a comma-separated list (--static-mcp notion,atlassian), repeated flags (--static-mcp notion --static-mcp atlassian), or a mix; all forms accumulate into the same set. The set is chosen once at creation time. Local sandboxes take names registered with 'sbx mcp add'. Cloud sandboxes resolve names on the cloud MCP gateway.
- name: template
shorthand: t
usage: |
Container image to use for the sandbox (default: agent-specific image)
- name: ttl
usage: |
Cloud sandbox time-to-live before it times out (e.g. 30m, 2h, 1h30m; units are case-insensitive; cloud only; default: server-side)
- name: volume
shorthand: v
default_value: '[]'
experimental: true
usage: |
Attach an existing persistent volume, NAME:MOUNTPATH (cloud only, experimental; repeatable)
example: |4-
# Create in the current directory
sbx create opencode .
# Create with a specific path
sbx create opencode /path/to/project
# Create with additional read-only workspaces
sbx create opencode . /path/to/docs:ro
# Create without a workspace bind mount
sbx create opencode
# Create a cloud sandbox for opencode
sbx --cloud create opencode
# Create a named cloud sandbox with a mixin baked in
sbx --cloud create --name my-project opencode --kit ./my-mixin/
# Create from a template that already exists in the cloud registry
sbx --cloud create -t TEMPLATE
see_also:
- sbx create - Create a sandbox for an agent
data/sbx_cli/sbx_create_shell.yaml
-156
View File
@@ -1,156 +0,0 @@
name: sbx create shell
synopsis: Create a sandbox for shell
description: |-
Create a sandbox with access to a host workspace for shell.
The workspace path is mounted inside the sandbox at the same path as on the
host. Additional workspaces can be provided as extra arguments. Append ":ro" to
mount them read-only; a read-only argument may name a single file, which holds
that one path out of reach inside a workspace the sandbox can otherwise write.
Omit the path to create a sandbox without a workspace bind mount: the agent
then works in the container's own filesystem instead of on your files.
Use "sbx run --name SANDBOX" to attach to the agent after creation.
With --cloud:
Create a cloud sandbox for shell.
Cloud sandboxes have no host workspace, so no path follows the agent. Sizing
comes from --cpus and --memory and must land on a billable shape; without them
a cloud sandbox gets 2 CPUs and 4 GiB. A template named with -t / --template
must already exist in the cloud registry.
Cloud sandboxes use cloud network policies. Host network and HTTP policies
do not apply. Set cloud account defaults with
"sbx --cloud policy init <allow-all|balanced|deny-all>".
Use "sbx --cloud run <agent> --name SANDBOX" to attach to the agent after
creation: cloud needs the agent, since a name alone is not a unique handle.
usage: sbx create shell [PATH...] [flags]
options:
- name: help
shorthand: h
default_value: "false"
usage: help for shell
inherited_options:
- name: allow-network
usage: |
Network pattern to allow for cloud sandbox egress (cloud only; can be specified multiple times)
- name: clone
default_value: "false"
usage: |
Run the agent on a private in-container clone of the host Git repository (mounted read-only) instead of bind-mounting the workspace; the agent's commits are accessible via the sandbox-<name> git remote on the host
- name: cloud
default_value: "false"
usage: |
Dispatch to Docker Cloud Sandboxes API instead of local sandboxd (supported by a growing set of verbs — run 'sbx --cloud --help' for the current list)
- name: cpus
default_value: "0"
usage: |
Number of CPUs to allocate to the sandbox (0 = auto: all host CPUs, at most 16 on Linux arm64)
- name: debug
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: deny-network
usage: |
Add a per-sandbox network deny rule at creation time. Can be specified multiple times. The rule applies only to the new sandbox and can be listed or removed later with 'sbx policy ls <NAME>' or 'sbx policy rm network --sandbox <NAME> --resource <HOST>'. Safe under centralized governance because a local deny can only narrow, never widen, egress.
- name: env
shorthand: e
default_value: '[]'
usage: |
Set an environment variable in the sandbox (can be repeated): KEY=VALUE, or a bare KEY to take the value from the current environment
- name: env-file
default_value: '[]'
usage: |
Read environment variables from a file (can be repeated). --env wins over any file; a later file wins over an earlier one
- name: image-ref
usage: |
OCI image reference for inline-mode cloud create (mutually exclusive with --template; requires --cpus and --memory)
- name: kit
default_value: '[]'
experimental: true
usage: |
Additional kit reference (must be a mixin; directory, ZIP, git, or OCI). Can be specified multiple times
- name: kit-arg
default_value: '[]'
experimental: true
usage: |
Value for an argument the kit declares, as name=value for every kit or kit.name=value for one (can be repeated)
- name: kit-args-file
default_value: '[]'
experimental: true
usage: |
File of name=value kit arguments, one per line (can be repeated); --kit-arg overrides
- name: memory
shorthand: m
usage: |
Memory limit in binary units (e.g., 512m, 8g). Minimum: 512 MiB. Default: 50% of host memory, clamped to 512 MiB–32 GiB. Maximum: max(75% of host memory, 512 MiB)
- name: mount
default_value: '[]'
usage: |
Bind a host directory to a kit host-mount@1 path (can be repeated): HOST:SANDBOX_PATH. Can only be used when creating a new sandbox.
- name: name
usage: |
Name for the sandbox (defaults to <agent>-<workdir>; at least two characters, starting with a letter or number, containing only letters, numbers, hyphens and periods (periods are rejected with --cloud); 'default' is reserved)
- name: no-progress
default_value: "false"
usage: Suppress progress output
- name: on-timeout
usage: |
What happens when --ttl lapses: 'stop' stops the sandbox in place so it can be started again later, 'restart' keeps it running by stopping and immediately starting it, or 'delete' removes it. Omit the flag and the server stops the sandbox when it can be started again later, and deletes it otherwise. With 'restart' a supplied --ttl must be at least 1h (cloud only).
- name: platform
usage: |
Target platform: linux/amd64 or linux/arm64 (cloud only). With --image-ref, omitting it lets the server resolve the platform from the image and the CLI sends the local CPU as a hint for multi-platform images. With --template, omitting it inherits the template platform. With a sandbox kit, the kit's template is built for this platform and cached apart from other platforms; omitting it keeps the server's choice.
- name: publish
shorthand: p
default_value: '[]'
usage: |
Publish a sandbox port to the host (can be repeated): [[HOST_IP:]HOST_PORT:]SANDBOX_PORT[/PROTOCOL]
- name: pull
usage: |
Image pull policy (always|missing|never; default: never for saved local snapshots, missing for v3 kit compositions, otherwise always)
- name: skills
usage: |
Shared skills store mode for the agent's skills directory (e.g. ~/.claude/skills): off, readonly (store linked in read-only, directory stays writable), or readwrite (store mounted over it, writes are shared). Default: readonly, or the configured skills.defaultMode setting.
- name: static-mcp
default_value: '[]'
usage: |
MCP server names that form the sandbox's fixed (static) MCP set. Accepts a comma-separated list (--static-mcp notion,atlassian), repeated flags (--static-mcp notion --static-mcp atlassian), or a mix; all forms accumulate into the same set. The set is chosen once at creation time. Local sandboxes take names registered with 'sbx mcp add'. Cloud sandboxes resolve names on the cloud MCP gateway.
- name: template
shorthand: t
usage: |
Container image to use for the sandbox (default: agent-specific image)
- name: ttl
usage: |
Cloud sandbox time-to-live before it times out (e.g. 30m, 2h, 1h30m; units are case-insensitive; cloud only; default: server-side)
- name: volume
shorthand: v
default_value: '[]'
experimental: true
usage: |
Attach an existing persistent volume, NAME:MOUNTPATH (cloud only, experimental; repeatable)
example: |4-
# Create in the current directory
sbx create shell .
# Create with a specific path
sbx create shell /path/to/project
# Create with additional read-only workspaces
sbx create shell . /path/to/docs:ro
# Create without a workspace bind mount
sbx create shell
# Create a cloud sandbox for shell
sbx --cloud create shell
# Create a named cloud sandbox with a mixin baked in
sbx --cloud create --name my-project shell --kit ./my-mixin/
# Create from a template that already exists in the cloud registry
sbx --cloud create -t TEMPLATE
see_also:
- sbx create - Create a sandbox for an agent
data/sbx_cli/sbx_daemon.yaml
+4
View File
@@ -15,6 +15,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
see_also:
- sbx - Manage AI coding agent sandboxes.
- sbx daemon log-level - Show or change sandboxd's per-category log levels
data/sbx_cli/sbx_daemon_log-level.yaml
+4
View File
@@ -15,6 +15,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
see_also:
- sbx daemon - Manage sandboxd daemon
- 'sbx daemon log-level set - Set a category''s log level (target: proxy, general, or all)'
data/sbx_cli/sbx_daemon_log-level_set.yaml
+4
View File
@@ -15,6 +15,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
sbx daemon log-level set proxy debug
data/sbx_cli/sbx_daemon_restart.yaml
+4
View File
@@ -15,6 +15,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: ' sbx daemon restart'
see_also:
- sbx daemon - Manage sandboxd daemon
data/sbx_cli/sbx_daemon_start.yaml
+4
View File
@@ -22,6 +22,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
sbx daemon start
data/sbx_cli/sbx_daemon_status.yaml
+4
View File
@@ -20,6 +20,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
sbx daemon status
data/sbx_cli/sbx_daemon_stop.yaml
+4
View File
@@ -15,6 +15,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: ' sbx daemon stop'
see_also:
- sbx daemon - Manage sandboxd daemon
data/sbx_cli/sbx_diagnose.yaml
+4
View File
@@ -23,6 +23,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
sbx diagnose
data/sbx_cli/sbx_env.yaml
+4
View File
@@ -50,6 +50,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
see_also:
- sbx - Manage AI coding agent sandboxes.
- sbx env create - Create a sandbox environment from sbxenv.yaml
data/sbx_cli/sbx_env_create.yaml
+4
View File
@@ -73,6 +73,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
# Create the environment described in the current directory
sbx env create
data/sbx_cli/sbx_env_exec.yaml
+7 -2
View File
@@ -3,8 +3,9 @@ synopsis: Execute a command inside a sandbox environment
experimental: true
description: |-
Run COMMAND in the sandbox declared in sbxenv.yaml. The sandbox
must already exist (see "sbx env create" and "sbx env run"); a stopped sandbox is
started first.
is started first if stopped. If it does not exist, an interactive terminal prompts
to create it and approve the environment plan before running COMMAND. Without an
interactive terminal, or with --no-input, create it first with "sbx env create".
Arguments before `--` are environment-file paths, following the same rules as
the other "sbx env" subcommands: each PATH may be a directory (the file is
@@ -81,6 +82,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
# Run a command in the environment declared in the current directory
sbx env exec go test ./...
data/sbx_cli/sbx_env_plan.yaml
+4
View File
@@ -67,6 +67,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
sbx env plan
sbx env plan ./project
data/sbx_cli/sbx_env_rm.yaml
+4
View File
@@ -58,6 +58,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
sbx env rm
data/sbx_cli/sbx_env_run.yaml
+19 -2
View File
@@ -3,7 +3,7 @@ synopsis: Create (if needed) and attach to a sandbox environment
experimental: true
description: |-
Read the environment file from PATH (default: current directory)
and drop into the sandbox shell. If the sandbox already exists it is started
and launch its agent. If the sandbox already exists it is started
and re-attached without re-provisioning; otherwise it is created first
(provisioning secrets and bindings) and then attached.
@@ -14,11 +14,21 @@ description: |-
supplied by --env-arg, plus ${{ env.projectDir }} and ${{ env.fileDir }}.
Nothing else is expanded, so a "$" is literal text.
Optional entrypoint and cmd arrays override the agent launch for this environment
only. Omitted or null fields inherit defaults; empty arrays clear
them. Later files replace these arrays rather than concatenate them. Arguments
after -- replace cmd when an override is configured; otherwise they are forwarded
to the agent's saved launcher. No shell expansion is performed on array elements.
Overrides bypass the saved launcher, apply on each env run, and leave env exec,
plain sbx run, the published kit, and the sandbox's PID 1 unchanged. A detached
run starts only the sandbox, not the configured command. Inheriting launch
defaults may require resolving the environment's workload kit again.
A directory PATH selects sbxenv.yaml; a file PATH selects that file.
With no PATH, ~/.sbxenv.yaml supplies shared defaults when present.
Explicit PATHs skip those defaults. Later files override earlier values;
lists such as ports and mcp.servers are concatenated.
usage: sbx env run [PATH...] [flags]
usage: sbx env run [PATH...] [-- ARG...] [flags]
options:
- name: clone
default_value: "false"
@@ -78,10 +88,17 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
sbx env run
# Start without attaching
sbx env run --detach ./project
# Replace cmd while keeping the configured entrypoint
sbx env run . -- --base HEAD
see_also:
- sbx env - (Experimental) Manage sandboxes declaratively from an sbxenv.yaml file
data/sbx_cli/sbx_exec.yaml
+4
View File
@@ -57,6 +57,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
# Open a shell inside a sandbox
sbx exec -it my-sandbox bash
data/sbx_cli/sbx_kit.yaml
+4
View File
@@ -22,6 +22,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
see_also:
- sbx - Manage AI coding agent sandboxes.
- sbx kit add - Add a mixin to a sandbox
data/sbx_cli/sbx_kit_add.yaml
+4
View File
@@ -41,6 +41,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
# Add a local mixin directory to a sandbox
sbx kit add my-sandbox ./mcp-postgres/
data/sbx_cli/sbx_kit_builder.yaml
+4
View File
@@ -24,6 +24,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
see_also:
- sbx kit - (Experimental) Manage kit artifacts
- sbx kit builder history - Show kit build history in the builder sandbox
data/sbx_cli/sbx_kit_builder_history.yaml
+4
View File
@@ -22,6 +22,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
see_also:
- sbx kit builder - Manage the kit builder sandbox
- sbx kit builder history export - Export a kit build record into a bundle
data/sbx_cli/sbx_kit_builder_history_export.yaml
+4
View File
@@ -16,6 +16,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: ' sbx kit builder history export 3b6l9x --output build.dockerbuild'
see_also:
- sbx kit builder history - Show kit build history in the builder sandbox
data/sbx_cli/sbx_kit_builder_history_inspect.yaml
+4
View File
@@ -16,6 +16,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
# The most recent build
sbx kit builder history inspect
data/sbx_cli/sbx_kit_builder_history_logs.yaml
+4
View File
@@ -16,6 +16,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
sbx kit builder history logs
sbx kit builder history logs 3b6l9x
data/sbx_cli/sbx_kit_builder_history_ls.yaml
+4
View File
@@ -16,6 +16,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: ' sbx kit builder history ls'
see_also:
- sbx kit builder history - Show kit build history in the builder sandbox
data/sbx_cli/sbx_kit_builder_history_rm.yaml
+4
View File
@@ -20,6 +20,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
sbx kit builder history rm 3b6l9x
data/sbx_cli/sbx_kit_builder_history_trace.yaml
+4
View File
@@ -16,6 +16,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
sbx kit builder history trace
sbx kit builder history trace 3b6l9x
data/sbx_cli/sbx_kit_builder_rm.yaml
+4
View File
@@ -20,6 +20,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
sbx kit builder rm
data/sbx_cli/sbx_kit_builder_status.yaml
+4
View File
@@ -16,6 +16,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: ' sbx kit builder status'
see_also:
- sbx kit builder - Manage the kit builder sandbox
data/sbx_cli/sbx_kit_inspect.yaml
+13
View File
@@ -9,6 +9,9 @@ description: |-
Pass --kit-arg to preview how the kit resolves with a given set of
arguments; the output shows the substituted content.
--resolved merges the kit's extends: parent into it, so the output is what
sbx applies rather than only what the kit declares.
--offline skips the daemon-backed kit policy (kit.allowedSources,
kit.allowLocalKits, kit.requireSignature) so the command needs neither
sandboxd nor a signed-in session; it only accepts a local directory or
@@ -38,6 +41,9 @@ options:
default_value: "false"
usage: |
Skip the daemon-backed kit policy check; local directory or ZIP references only
- name: resolved
default_value: "false"
usage: 'Merge the kit''s extends: parent into the output'
inherited_options:
- name: cloud
default_value: "false"
@@ -47,6 +53,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
sbx kit inspect ./my-kit
sbx kit inspect ghcr.io/myorg/my-kit:1.0
@@ -54,6 +64,9 @@ example: |4-
# Machine-readable output
sbx kit inspect ghcr.io/myorg/my-kit:1.0 --format json
# Show the kit with its extends: parent merged in
sbx kit inspect ./my-kit --resolved --format yaml
# Inspect without sandboxd running or a Docker sign-in
sbx kit inspect ./my-kit --offline
see_also:
data/sbx_cli/sbx_kit_pack.yaml
+4
View File
@@ -23,6 +23,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
sbx kit pack ./my-kit
data/sbx_cli/sbx_kit_provenance.yaml
+4
View File
@@ -49,6 +49,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
# Show provenance (unsigned attestations are printed as-is)
sbx kit provenance ghcr.io/org/my-kit:1.0
data/sbx_cli/sbx_kit_pull.yaml
+4
View File
@@ -29,6 +29,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
sbx kit pull ghcr.io/myorg/my-kit:1.0
data/sbx_cli/sbx_kit_push.yaml
+4
View File
@@ -43,6 +43,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
sbx kit push ./my-kit ghcr.io/myorg/my-kit:1.0
data/sbx_cli/sbx_kit_sign.yaml
+4
View File
@@ -53,6 +53,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
# Keyless-sign a local kit directory
sbx kit sign ./my-kit/
data/sbx_cli/sbx_kit_validate.yaml
+4
View File
@@ -48,6 +48,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
sbx kit validate ./my-kit
sbx kit validate ./my-kit.zip
data/sbx_cli/sbx_kit_verify.yaml
+4
View File
@@ -53,6 +53,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
# Verify a key-based signature
sbx kit verify --key cosign.pub ghcr.io/org/my-kit:1.0
data/sbx_cli/sbx_login.yaml
+4
View File
@@ -20,6 +20,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
sbx login
data/sbx_cli/sbx_logout.yaml
+4
View File
@@ -19,6 +19,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
sbx logout
data/sbx_cli/sbx_ls.yaml
+4
View File
@@ -26,6 +26,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
sbx ls
data/sbx_cli/sbx_mcp.yaml
+4
View File
@@ -17,6 +17,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
see_also:
- sbx - Manage AI coding agent sandboxes.
- sbx mcp add - Register an MCP server
data/sbx_cli/sbx_mcp_add.yaml
+4
View File
@@ -85,6 +85,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
# Remote MCP endpoint (OAuth auto-detected)
sbx mcp add notion --url https://mcp.notion.com/mcp
data/sbx_cli/sbx_mcp_auth.yaml
+15 -10
View File
@@ -1,19 +1,20 @@
name: sbx mcp auth
synopsis: Authorize MCP servers
description: |-
Authorize registered remote MCP servers through the hosted MCP control plane.
Authorize registered MCP servers with OAuth.
Commands use the Docker Hub account from 'sbx login' as the request principal.
User and tenant identity are derived by the control plane; they are not sent in
the request body.
With a local gateway or an OAuth override in the server registration, credentials
are stored locally. Otherwise, the hosted MCP control plane manages them.
Running 'sbx mcp auth <server>' authorizes or reauthorizes one server. If the
stored credential is expired, sbx asks the control plane to refresh it first and
only falls back to interactive OAuth when refresh needs user consent.
Hosted operations use the Docker Hub account from 'sbx login'. The control plane
derives user and tenant identity; they are not sent in the request body.
Use 'sbx mcp auth status' to inspect hosted credential status without starting
OAuth, and 'sbx mcp auth rm' to remove hosted credentials without removing
local MCP server registrations.
Running 'sbx mcp auth <server>' authorizes or reauthorizes one server, even if it
already has stored credentials.
Use 'sbx mcp auth status' to inspect credential status without starting OAuth,
and 'sbx mcp auth rm' to remove credentials without removing local MCP server
registrations.
Pass --scope (repeatable) to authorize a specific set of scopes for this run,
overriding the default recorded at 'sbx mcp add' time. Precedence is --no-scope >
@@ -83,6 +84,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
sbx mcp auth status --all
sbx mcp auth status notion
data/sbx_cli/sbx_mcp_auth_rm.yaml
+8 -1
View File
@@ -1,7 +1,10 @@
name: sbx mcp auth rm
synopsis: Remove MCP server OAuth credentials
description: |-
Remove hosted OAuth credentials for registered MCP servers.
Remove OAuth credentials for registered MCP servers.
With a local gateway or an OAuth override in the server registration, credentials
are stored locally. Otherwise, the hosted MCP control plane manages them.
This command does not remove local MCP server registrations. Use 'sbx mcp rm'
to remove a registration.
@@ -33,6 +36,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
sbx mcp auth rm --all
sbx mcp auth rm notion
data/sbx_cli/sbx_mcp_auth_status.yaml
+8 -1
View File
@@ -1,7 +1,10 @@
name: sbx mcp auth status
synopsis: Show MCP server OAuth status
description: |-
Show hosted OAuth credential status for registered MCP servers.
Show OAuth credential status for registered MCP servers.
With a local gateway or an OAuth override in the server registration, credentials
are stored locally. Otherwise, the hosted MCP control plane manages them.
This command does not start OAuth or refresh expired credentials.
usage: sbx mcp auth status [SERVER] [flags]
@@ -28,6 +31,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
sbx mcp auth status --all
sbx mcp auth status notion
data/sbx_cli/sbx_mcp_inspect.yaml
+4
View File
@@ -20,6 +20,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
sbx mcp inspect notion
data/sbx_cli/sbx_mcp_load.yaml
+4
View File
@@ -32,6 +32,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
# Register, then load into the running sandbox 'my-sbx'.
sbx mcp add notion --url https://mcp.notion.com/mcp
data/sbx_cli/sbx_mcp_ls.yaml
+4
View File
@@ -48,6 +48,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
sbx mcp ls
data/sbx_cli/sbx_mcp_rm.yaml
+4
View File
@@ -33,6 +33,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
sbx mcp rm notion
sbx mcp rm --registration-only notion
data/sbx_cli/sbx_mcp_unload.yaml
+4
View File
@@ -25,6 +25,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
# Unload the 'notion' server from the running sandbox 'my-sbx'.
sbx mcp unload notion --sandbox my-sbx
data/sbx_cli/sbx_move.yaml
+5 -2
View File
@@ -80,9 +80,8 @@ options:
usage: |
Destination of the move: 'local' (cloud to local) or 'cloud' (local to cloud)
- name: ttl
default_value: 0s
usage: |
Time-to-live for the destination cloud sandbox (15s to 24h, e.g. 30m, 2h; only with --to cloud; default: server-side)
Time-to-live for the destination cloud sandbox (15s to 24h, e.g. 30m, 2h; units are case-insensitive; only with --to cloud; default: server-side)
inherited_options:
- name: cloud
default_value: "false"
@@ -92,6 +91,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
# Move a cloud sandbox down to the local host
sbx move sbx_abc123 --to local
data/sbx_cli/sbx_policy.yaml
+4
View File
@@ -21,6 +21,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
see_also:
- sbx - Manage AI coding agent sandboxes.
- sbx policy allow - Add an allow rule for sandboxes
data/sbx_cli/sbx_policy_allow.yaml
+14
View File
@@ -6,6 +6,16 @@ description: |-
Allowed resources are accessible within the selected policy scope. If a
resource matches both an allow and a deny rule, the deny rule takes
precedence.
Without --cloud, a rule is refused, and nothing is added, when the same scope
already holds the opposite decision for the same resource on any of the same
protocols (for HTTP rules, the same methods, path, and query constraints).
Remove the existing rule with "sbx policy rm network --id RULE_ID" first, adding
--sandbox SANDBOX if the rule is sandbox-scoped. Rules in different scopes, such
as a global allow and a sandbox-scoped deny, can coexist, and the deny rule
takes precedence. Rules from your organization's policy never cause this
refusal. With --cloud, the new rule replaces the opposite rule in the same scope
instead.
usage: sbx policy allow COMMAND
options:
- name: help
@@ -21,6 +31,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
see_also:
- sbx policy - Manage sandbox policies
- sbx policy allow network - Allow network access to specified hosts
data/sbx_cli/sbx_policy_allow_network.yaml
+32
View File
@@ -17,9 +17,31 @@ description: |-
The rule applies globally to all sandboxes by default. Use --sandbox to add
the rule to policy "local" scoped to a single sandbox instead.
Without --cloud, a rule is refused, and nothing is added, when the same scope
already holds the opposite decision for the same resource on any of the same
protocols (for HTTP rules, the same methods, path, and query constraints).
Remove the existing rule with "sbx policy rm network --id RULE_ID" first, adding
--sandbox SANDBOX if the rule is sandbox-scoped. Rules in different scopes, such
as a global allow and a sandbox-scoped deny, can coexist, and the deny rule
takes precedence. Rules from your organization's policy never cause this
refusal. With --cloud, the new rule replaces the opposite rule in the same scope
instead.
Use --method to add an HTTP rule. --method accepts comma-separated HTTP
methods or ANY; --path defaults to /**. Repeat --query name=value to require
query parameters.
With --cloud:
Allow cloud sandbox network access to the specified hosts.
A matching deny entry in the same scope is replaced by the allow entry.
RESOURCES is a comma-separated list of network patterns, such as api.example.com,
*.example.com, 10.0.0.0/8, or api.example.com:443. HTTP method, path, query, and
transport protocol selectors are not supported.
Rules apply to the account by default. Use --sandbox with a sandbox name or ID
to change one sandbox's policy. Use "sbx --cloud policy ls" to list the rules.
usage: sbx policy allow network [--sandbox SANDBOX] RESOURCES [flags]
options:
- name: help
@@ -52,6 +74,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
# Allow access to a single host (all sandboxes)
sbx policy allow network api.example.com
@@ -70,5 +96,11 @@ example: |4-
# Allow GET and HEAD requests to a path
sbx policy allow network api.example.com --method GET,HEAD --path '/v1/**'
# Allow a host in the account policy
sbx --cloud policy allow network api.example.com
# Allow a host for one sandbox
sbx --cloud policy allow network --sandbox my-sandbox api.example.com
see_also:
- sbx policy allow - Add an allow rule for sandboxes
data/sbx_cli/sbx_policy_check.yaml
+5
View File
@@ -20,6 +20,11 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
see_also:
- sbx policy - Manage sandbox policies
- sbx policy check http - Check HTTP access to a URL
- sbx policy check network - Check network access to a host
data/sbx_cli/sbx_policy_check_http.yaml
+56
View File
@@ -0,0 +1,56 @@
name: sbx policy check http
synopsis: Check HTTP access to a URL
description: |-
Evaluate current policy for an HTTP request to URL.
URL must be an absolute HTTP or HTTPS URL. The check evaluates network access
first, then evaluates HTTP method, path, and query policy when it applies. It
does not resolve hostnames, make a network request, or account for runtime
transport behavior. Transparent connections that require HTTP authorization are
blocked at runtime, while daemon-managed aliases can be reachable regardless of
the policy result. Results for hostnames do not include policy applied to their
resolved IP addresses. The displayed URL retains the target's host spelling;
with --verbose, Resource shows the normalized host and port evaluated by policy.
usage: sbx policy check http [--sandbox SANDBOX] [--method METHOD] URL [flags]
options:
- name: format
usage: 'Output format: table, json or yaml'
- name: help
shorthand: h
default_value: "false"
usage: help for http
- name: json
default_value: "false"
usage: Output in JSON format
- name: method
default_value: GET
usage: HTTP method to evaluate
- name: sandbox
usage: Evaluate in a specific sandbox policy context
- name: verbose
default_value: "false"
usage: Show the policy action and resource
inherited_options:
- name: cloud
default_value: "false"
usage: |
Dispatch to Docker Cloud Sandboxes API instead of local sandboxd (supported by a growing set of verbs — run 'sbx --cloud --help' for the current list)
- name: debug
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
# Check a GET request
sbx policy check http https://api.example.com/v1/items
# Check a POST request in a sandbox context
sbx policy check http --sandbox my-sandbox --method POST https://api.example.com/v1/items
# Check a query-qualified request and output JSON
sbx policy check http --json 'https://api.example.com/search?team=platform'
see_also:
- sbx policy check - Check whether policy allows an access request
data/sbx_cli/sbx_policy_check_network.yaml
+5 -1
View File
@@ -24,7 +24,7 @@ options:
usage: Evaluate in a specific sandbox policy context
- name: verbose
default_value: "false"
usage: Show the exact policy request fields
usage: Show the policy action and resource
inherited_options:
- name: cloud
default_value: "false"
@@ -34,6 +34,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
# Check global network policy
sbx policy check network api.example.com
data/sbx_cli/sbx_policy_deny.yaml
+19 -2
View File
@@ -3,8 +3,21 @@ synopsis: Add a deny rule for sandboxes
description: |-
Add a rule that blocks sandboxes from accessing specified resources.
Deny rules take precedence over allow rules for the same hostname or CIDR. An
allowed hostname isn't checked against CIDR rules for its resolved IP address.
Deny rules take precedence over allow rules for the same hostname or CIDR. A
direct connection to an allowed hostname is also checked against CIDR rules for
its resolved IP address, and a deny on either takes precedence. Connections
through an upstream proxy that resolves the hostname are checked by hostname
only.
Without --cloud, a rule is refused, and nothing is added, when the same scope
already holds the opposite decision for the same resource on any of the same
protocols (for HTTP rules, the same methods, path, and query constraints).
Remove the existing rule with "sbx policy rm network --id RULE_ID" first, adding
--sandbox SANDBOX if the rule is sandbox-scoped. Rules in different scopes, such
as a global allow and a sandbox-scoped deny, can coexist, and the deny rule
takes precedence. Rules from your organization's policy never cause this
refusal. With --cloud, the new rule replaces the opposite rule in the same scope
instead.
usage: sbx policy deny COMMAND
options:
- name: help
@@ -20,6 +33,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
see_also:
- sbx policy - Manage sandbox policies
- sbx policy deny network - Deny network access to specified hosts
data/sbx_cli/sbx_policy_deny_network.yaml
+39 -3
View File
@@ -6,16 +6,42 @@ description: |-
RESOURCES takes the same forms as "sbx policy allow network": exact domains,
wildcard subdomains, IP addresses, and CIDR prefixes, with optional port
suffixes. Rules apply to TCP and UDP by default; use --protocol to restrict a
rule to one transport. Deny rules take precedence over allow rules for the
same hostname or CIDR. An allowed hostname isn't checked against CIDR rules
for its resolved IP address.
rule to one transport.
Deny rules take precedence over allow rules for the same hostname or CIDR. A
direct connection to an allowed hostname is also checked against CIDR rules for
its resolved IP address, and a deny on either takes precedence. Connections
through an upstream proxy that resolves the hostname are checked by hostname
only.
The rule applies globally to all sandboxes by default. Use --sandbox to add
the rule to policy "local" scoped to a single sandbox instead.
Without --cloud, a rule is refused, and nothing is added, when the same scope
already holds the opposite decision for the same resource on any of the same
protocols (for HTTP rules, the same methods, path, and query constraints).
Remove the existing rule with "sbx policy rm network --id RULE_ID" first, adding
--sandbox SANDBOX if the rule is sandbox-scoped. Rules in different scopes, such
as a global allow and a sandbox-scoped deny, can coexist, and the deny rule
takes precedence. Rules from your organization's policy never cause this
refusal. With --cloud, the new rule replaces the opposite rule in the same scope
instead.
Use --method to add an HTTP rule. --method accepts comma-separated HTTP
methods or ANY; --path defaults to /**. Repeat --query name=value to require
query parameters.
With --cloud:
Block cloud sandbox network access to the specified hosts.
A matching allow entry in the same scope is replaced by the deny entry.
RESOURCES is a comma-separated list of network patterns, such as api.example.com,
*.example.com, 10.0.0.0/8, or api.example.com:443. HTTP method, path, query, and
transport protocol selectors are not supported.
Rules apply to the account by default. Use --sandbox with a sandbox name or ID
to change one sandbox's policy. Use "sbx --cloud policy ls" to list the rules.
usage: sbx policy deny network [--sandbox SANDBOX] RESOURCES [flags]
options:
- name: help
@@ -48,6 +74,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
# Block access to a host (all sandboxes)
sbx policy deny network ads.example.com
@@ -63,5 +93,11 @@ example: |4-
# Block POST requests to a path
sbx policy deny network api.example.com --method POST --path '/admin/**'
# Block a host in the account policy
sbx --cloud policy deny network ads.example.com
# Block a host for one sandbox
sbx --cloud policy deny network --sandbox my-sandbox ads.example.com
see_also:
- sbx policy deny - Add a deny rule for sandboxes
data/sbx_cli/sbx_policy_init.yaml
+4
View File
@@ -38,6 +38,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
# Initialize with the balanced policy — recommended
sbx policy init balanced
data/sbx_cli/sbx_policy_inspect.yaml
+4
View File
@@ -31,6 +31,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
# Inspect a policy by name
sbx policy inspect "Developer access"
data/sbx_cli/sbx_policy_log.yaml
+4
View File
@@ -33,6 +33,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
# Show all policy logs
sbx policy log
data/sbx_cli/sbx_policy_ls.yaml
+23
View File
@@ -16,6 +16,13 @@ description: |-
Use --include-inactive to show inactive rules for troubleshooting.
Use "sbx policy inspect <policy-or-rule>" for full detail on a selected policy or
rule.
With --cloud:
List the cloud network policy's default mode and allow and deny patterns.
Without SANDBOX, show the account policy. Specify a sandbox name or ID to show
its policy. Cloud rules have no rule IDs; use "sbx --cloud policy rm network"
with --resource to remove a pattern.
usage: sbx policy ls [SANDBOX] [flags]
options:
- name: created-via
@@ -59,6 +66,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
# List all policies
sbx policy ls
@@ -86,5 +97,17 @@ example: |4-
# Include inactive rules hidden by remote governance
sbx policy ls --include-inactive
# Show the account policy
sbx --cloud policy ls
# Show one sandbox's policy
sbx --cloud policy ls my-sandbox
# Output the policy as JSON
sbx --cloud policy ls --format json
# List only network patterns
sbx --cloud policy ls -q
see_also:
- sbx policy - Manage sandbox policies
data/sbx_cli/sbx_policy_refresh.yaml
+4
View File
@@ -27,6 +27,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: ' sbx policy refresh'
see_also:
- sbx policy - Manage sandbox policies
data/sbx_cli/sbx_policy_reset.yaml
+4
View File
@@ -32,6 +32,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
# Reset policies — prompts if sandboxes are running
sbx policy reset
data/sbx_cli/sbx_policy_rm.yaml
+4
View File
@@ -16,6 +16,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
see_also:
- sbx policy - Manage sandbox policies
- sbx policy rm network - Remove a network rule
data/sbx_cli/sbx_policy_rm_network.yaml
+4
View File
@@ -63,6 +63,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
# List rules to find the ID or resource to remove
sbx policy ls --wide
data/sbx_cli/sbx_ports.yaml
+5
View File
@@ -45,6 +45,7 @@ options:
default_value: "false"
usage: Output in JSON format
- name: publish
shorthand: p
default_value: '[]'
usage: |
Publish a port (can be repeated): [[HOST_IP:]HOST_PORT:]SANDBOX_PORT[/PROTOCOL] (local) or SANDBOX_PORT[/tcp] (cloud)
@@ -61,6 +62,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
# List published ports
sbx ports my-sandbox
data/sbx_cli/sbx_prune.yaml
+4
View File
@@ -57,6 +57,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
# Show what would be removed
sbx prune --dry-run
data/sbx_cli/sbx_reset.yaml
+5 -1
View File
@@ -8,7 +8,7 @@ description: |-
- Clear image cache
- Clear all internal registries
- Delete all sandbox state
- Remove all policies
- Remove all local policy rules
- Remove the managed SSH configuration
- Clear the Gordon assistant's sessions and history
- Delete all stored secrets
@@ -46,6 +46,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
sbx reset
data/sbx_cli/sbx_rm.yaml
+4
View File
@@ -48,6 +48,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
sbx rm my-sandbox
data/sbx_cli/sbx_run.yaml
+26 -6
View File
@@ -8,16 +8,18 @@ description: |-
directories, ZIP files, git repositories, or OCI references. Relative local
references must be explicit paths such as ./my-kit or ../my-kit.zip; bare values
retain their agent or sandbox-name meaning. A kit.shortcuts.<agent> setting (sbx
settings set kit.shortcuts.claude sbx/claude:latest) makes that agent name
settings set kit.shortcuts.claude myorg/claude:latest) makes that agent name
resolve to the configured kit reference instead for local sandboxes; cloud
sandboxes ignore it. To re-attach to an existing sandbox
by name, use --name; the agent positional is optional when the named sandbox
already exists and is read from its spec.
Pass agent arguments after the "--" separator. Additional workspaces can be
provided as extra arguments. Append ":ro" to mount them read-only; a read-only
argument may name a single file, which holds that one path out of reach inside a
workspace the sandbox can otherwise write.
provided as extra arguments of the form PATH[:TARGET][:ro]. TARGET is an
absolute path inside the sandbox; omit it to mount PATH at the same path as on
the host. Append ":ro" to mount a workspace read-only; a read-only argument may
name a single file, which holds that one path out of reach inside a workspace
the sandbox can otherwise write.
Omit the path to mount the current directory. Pass a path to mount a different
workspace.
@@ -47,6 +49,10 @@ description: |-
--detach is refused, so scripts pass --detach (e.g.
sbx --cloud run -d claude && sbx --cloud exec ...).
With --cloud, --env and --env-file only apply when creating a sandbox.
Existing sandboxes keep their original environment; drop these flags to
reattach, or pass --new to create a sandbox with the new values.
Sizing comes from --cpus and --memory and must land on a billable shape; without
them a cloud sandbox gets 2 CPUs and 4 GiB. A template named with -t / --template
must already exist in the cloud registry; the CLI does not upload it. See
@@ -109,7 +115,7 @@ options:
- name: memory
shorthand: m
usage: |
Memory limit in binary units (e.g., 512m, 8g). Minimum: 512 MiB. Default: 50% of host memory, clamped to 512 MiB–32 GiB. Maximum: max(75% of host memory, 512 MiB)
Memory limit in binary units (e.g., 512m, 8g). Minimum: 512 MiB. Default: 50% of host memory, clamped to 512 MiB–32 GiB. Maximum: host memory. Warns above 75% of host memory
- name: mount
default_value: '[]'
usage: |
@@ -120,6 +126,9 @@ options:
default_value: "false"
usage: |
Always create a new cloud sandbox instead of prompting to reuse an existing one (cloud only)
- name: no-progress
default_value: "false"
usage: Suppress progress output
- name: on-timeout
usage: |
What happens when --ttl lapses: 'stop' stops the sandbox in place so it can be started again later, 'restart' keeps it running by stopping and immediately starting it, or 'delete' removes it. Omit the flag and the server stops the sandbox when it can be started again later, and deletes it otherwise. With 'restart' a supplied --ttl must be at least 1h (cloud only).
@@ -143,7 +152,7 @@ options:
- name: static-mcp
default_value: '[]'
usage: |
MCP server names that form the sandbox's fixed (static) MCP set. Accepts a comma-separated list (--static-mcp notion,atlassian), repeated flags (--static-mcp notion --static-mcp atlassian), or a mix; all forms accumulate into the same set. The set is chosen once at creation time and cannot be changed when re-attaching to an existing sandbox. Local sandboxes take names registered with 'sbx mcp add'. Cloud sandboxes resolve names on the cloud MCP gateway.
MCP server names that form the sandbox's fixed (static) MCP set. Accepts a comma-separated list (--static-mcp notion,atlassian), repeated flags (--static-mcp notion --static-mcp atlassian), or a mix; all forms accumulate into the same set. Use none for a static set with no servers, local sandboxes only. The set is chosen once at creation time and cannot be changed when re-attaching to an existing sandbox. Local sandboxes take names registered with 'sbx mcp add'. Cloud sandboxes resolve names on the cloud MCP gateway.
- name: template
shorthand: t
usage: |
@@ -157,6 +166,10 @@ options:
experimental: true
usage: |
Attach an existing persistent volume, NAME:MOUNTPATH (cloud only, experimental; repeatable)
- name: workdir
shorthand: w
usage: |
Directory to start the agent session in: absolute, or relative to the sandbox workspace. Applies to this session only, so it works on a re-attach too
inherited_options:
- name: cloud
default_value: "false"
@@ -166,6 +179,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
# Create and run a sandbox with claude in the current directory
sbx run claude
@@ -182,6 +199,9 @@ example: |4-
# Create and run with additional workspaces (read-only)
sbx run claude . /path/to/docs:ro
# Mount an additional workspace at a chosen path inside the sandbox
sbx run claude . /path/to/data:/workspace/data
# Re-attach to an existing sandbox by name (agent read from its spec)
sbx run --name existing-sandbox
data/sbx_cli/sbx_secret.yaml
+4
View File
@@ -29,6 +29,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
see_also:
- sbx - Manage AI coding agent sandboxes.
- sbx secret import - Import secrets detected in host environment variables
data/sbx_cli/sbx_secret_import.yaml
+4
View File
@@ -47,6 +47,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
# Walk every detected env var, prompting before each import
sbx secret import
data/sbx_cli/sbx_secret_ls.yaml
+4
View File
@@ -37,6 +37,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
# List all secrets
sbx secret ls
data/sbx_cli/sbx_secret_rm.yaml
+4
View File
@@ -31,6 +31,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
# Choose an existing secret to remove with the arrow keys
sbx secret rm
data/sbx_cli/sbx_secret_set-custom.yaml
+11 -1
View File
@@ -25,7 +25,7 @@ description: |-
dependencies, or confine their execution. Helpers and any code or configuration
they load must remain outside writable sandbox mounts. Explicit paths into shared
workspaces and broad mounts exposing host configuration or the host temporary
directory remain unsafe, including mounts added later with sbx mount.
directory remain unsafe, including mounts added to a running sandbox later.
With --cloud, --host takes exact DNS names only (no IP addresses or wildcards)
and the proxy sets --header on requests to those hosts instead of substituting
@@ -76,6 +76,9 @@ options:
usage: 'Secret value (less secure: visible in shell history)'
- name: value
usage: 'Secret value (less secure: visible in shell history)'
- name: value-stdin
default_value: "false"
usage: Read the secret value from stdin
inherited_options:
- name: cloud
default_value: "false"
@@ -85,6 +88,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
# Create a global custom secret. A unique placeholder is generated automatically.
# The sandbox env var API_KEY is set to the placeholder value; outbound requests
@@ -102,5 +109,8 @@ example: |4-
# Custom placeholder with {rand} suffix; the CLI prints the generated value.
sbx secret set-custom --host api.example.com --placeholder sk-{rand} --value secret123
# Read the value from stdin to keep it out of shell history and the process list.
printf '%s' "$API_KEY" | sbx secret set-custom --host api.example.com --env API_KEY --value-stdin
see_also:
- sbx secret - Manage stored secrets
data/sbx_cli/sbx_secret_set.yaml
+7 -2
View File
@@ -28,7 +28,7 @@ description: |-
dependencies, or confine their execution. Helpers and any code or configuration
they load must remain outside writable sandbox mounts. Explicit paths into shared
workspaces and broad mounts exposing host configuration or the host temporary
directory remain unsafe, including mounts added later with sbx mount.
directory remain unsafe, including mounts added to a running sandbox later.
### Registry credentials
@@ -55,7 +55,8 @@ options:
- name: force
shorthand: f
default_value: "false"
usage: Overwrite an existing secret when --token is used
usage: |
Overwrite existing API-key, OAuth, or registry credentials without confirmation
- name: help
shorthand: h
default_value: "false"
@@ -102,6 +103,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
# Store a GitHub token globally (available to all sandboxes)
sbx secret set github
data/sbx_cli/sbx_settings.yaml
+4
View File
@@ -24,6 +24,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
see_also:
- sbx - Manage AI coding agent sandboxes.
- sbx settings get - Get the value of a setting
data/sbx_cli/sbx_settings_get.yaml
+4
View File
@@ -25,6 +25,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
# Get a setting value
sbx settings get proxy.daemon
data/sbx_cli/sbx_settings_ls.yaml
+4
View File
@@ -35,6 +35,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
# List settings as a table
sbx settings ls
data/sbx_cli/sbx_settings_set.yaml
+4
View File
@@ -24,6 +24,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
# Route sandbox, daemon, and CLI egress through an upstream proxy
sbx settings set proxy http://proxy.example.com:3128
data/sbx_cli/sbx_settings_unset.yaml
+4
View File
@@ -20,6 +20,10 @@ inherited_options:
shorthand: D
default_value: "false"
usage: Enable debug logging
- name: no-input
default_value: "false"
usage: |
Never prompt; commands that need an answer fail with the command to run instead
example: |4-
# Remove the override for a setting
sbx settings unset proxy.daemon
Loaded 100 of 124 files, more files were not shown because too many files have changed in this diff. Show more