sbx --cloud run, sbx move, and sbx ttl

The agent in m101-demo is halfway through a long build, your laptop goes into a bag, and the sandbox stops with it. sbx move m101-demo --to cloud captures its filesystem and starts it again on Docker's compute, where a clock ends it and the lid does not. The build process does not move with it, so the agent runs the build again. When you finish this section, you can start a sandbox in the cloud, move one in either direction, and set the clock that ends it.

This edition recorded no cloud run, because a cloud sandbox costs money and that run was not approved. Every fact below comes from the help text and the documentation.

The --cloud flag and what it hides

Cloud sandbox: a sandbox that sbx creates through the Cloud Sandboxes API instead of the local sandboxd, selected with the global --cloud flag.

Sandbox Commands:
  attach      Attach to a cloud sandbox, starting it first if it is stopped
  cp          Copy files or directories between a sandbox and the host
  create      Create a sandbox for an agent
  exec        Execute a command inside a sandbox
  ls          List sandboxes
  move        Move a sandbox between local and cloud
  ports       Manage sandbox port publishing
  rm          Remove one or more sandboxes
  run         Run an agent in a sandbox
  stop        Stop one or more sandboxes without removing them
  ttl         Inspect or extend a cloud sandbox's TTL
…
  volume      Manage persistent volumes (cloud-only)

The cloud tree drops daemon, prune, settings, and skills, and rm --all is refused with --cloud (conflict C47). Sandboxes, templates, secrets, volumes, and network policy live in a separate cloud store.

You need sbx 0.45.1 or later and a pay-as-you-go plan on a Personal or Pro account. The docs page says 0.45.0 and the launch blog says 0.45.1 (conflict C36), and Team and Business accounts are not mentioned (conflict C103). sbx --cloud diagnose checks sign-in, the cloud API, and account access without a local daemon. Docker Offload, a remote daemon for Docker Desktop, is a different product with no sandbox path (conflicts C98 and C99).

Shapes, prices, and quotas

Without --cpus and --memory a cloud sandbox gets 2 CPUs and 4 GiB. The pair must name one of five billable shapes. Prices come from the launch blog of 2026-09-24, and the docs tree prints none (conflict C101).

The blog meters compute per second, and the docs confirm half of that: a stopped sandbox is not billed for compute. The $250 credit in the same blog is promotional. An account starts with 10 concurrent sandboxes, 50 stored sandboxes, 100 volumes, 100 secrets, and 3 images in preparation.

sbx --cloud run and attach

sbx --cloud run claude --name cloud-project creates the sandbox and attaches to its agent, or restarts the named sandbox when it exists. Ctrl-\ detaches, and sbx --cloud attach cloud-project joins the session again. sbx --cloud ports cloud-project --publish 8080 returns a public HTTPS URL, so the service behind it needs its own authentication. Secrets come from sbx --cloud secret set anthropic, and rules from sbx --cloud policy init, which can be run again. HTTP method rules, --protocol, and governance profiles are refused in the cloud.

sbx ttl and --on-timeout

TTL: the time a cloud sandbox lives before its timeout action, one hour by default and at most 24 hours from creation.

sbx --cloud ttl +2h cloud-project extends the expiration under that ceiling and never shortens it. --on-timeout chooses stop, restart, or delete. Omit it, and the server stops a sandbox it can resume and deletes the rest. restart needs a --ttl of at least one hour, and a volume-backed sandbox must use delete. Since v0.47.0 a stopped sandbox reports stopped, and its clock restarts on resume. A volume is a snapshot taken when the sandbox exits, and the last sandbox to exit overwrites it.

sbx move

sbx move m101-demo --to cloud captures the filesystem as a template image, uploads it, and creates a sandbox with a new id, named moved-m101-demo plus a suffix. Kit network rules and the local environment travel inside the image. The host bind mount, the secrets in the store, local policy rules, host port bindings, and running processes stay behind. Credential files written by an interactive sign-in are ordinary files, so they travel unless you delete them first.

HTTP method rules prompt before the move, because the cloud cannot apply them, and --force answers the prompt and keeps the warning. The destination expires after the server's default of one hour unless --ttl and --on-timeout say otherwise. Moving to local can stage up to 32 GiB in the host's temporary directory. The docs also warn that docker exec inside a cloud sandbox can read the VM filesystem instead of the container's (conflict C104). This edition did not confirm it.