sbx move

Description

Move a sandbox between the local host and Docker's hosted Sandboxes service.

Move captures the sandbox's filesystem as a container image and starts a new sandbox from it on the destination. Running processes and in-memory state do not travel. The destination sandbox gets a new ID; name it with --name.

Neither direction deletes the source. Moving to cloud stops the local sandbox; restart it with 'sbx run --name '. Moving to local asks the cloud source to stop; a refused or unconfirmed stop warns without failing the move, and the stop may still be finishing when the move returns. 'sbx --cloud ls' shows it. A cloud sandbox with no agent is left running. A stopped cloud source keeps its ID and state: 'sbx --cloud run ' resumes it, 'sbx --cloud rm ' deletes it.

A failed or cancelled move restores what it can. It restarts a local source that was running and removes the transfer templates it created. The restart re-runs the entrypoint; processes you started by hand are not revived. If a cleanup step fails, the output names what is left and the command that recovers it.

What does not travel:

• The workspace bind mount and other host mounts. Files moved to local stay inside the sandbox at the image's working directory; copy them out with 'sbx cp'.
• Secrets managed by sbx. The destination picks its own secrets, so you may need to sign in again. Credentials saved in copied files still travel.
• Volumes and environment variables attached to a cloud sandbox, when moving to local. A local sandbox's environment is part of its image and travels to the cloud.
• Network policies. Moving to cloud uses cloud policies; moving to local starts with the host's default policy. Active local L7 (HTTP) rules prompt before a move to cloud; --force skips the prompt but keeps the warning.
• Cloud URLs and host port bindings. Moving to cloud republishes TCP ports under new cloud URLs; a port the cloud refuses is skipped with a warning. Moving to local saves the published TCP ports and binds them on loopback while the sandbox runs. Host ports can change on restart; 'sbx ports SANDBOX' shows them. A cloud port published with an explicit host binding stops a move to local.

Sizing and disk:

• Moving to cloud rounds recorded CPU and memory limits up to a cloud shape. Missing limits use cloud defaults with a warning. Limits above the largest shape stop the move before anything is captured. Moving to local uses local defaults.
• Moving to local stages downloaded layers in the host's temporary directory. Reusing local layers can take up to 32 GiB in addition to the local runtime's image storage. If reuse fails, the layers are downloaded. If staging runs out of space, the move falls back to the export stream.

The cloud sandbox a move creates expires. The default is the server's TTL, typically 1h: stopped in place on expiry when the account and sandbox support it, deleted otherwise. Choose with --ttl and --on-timeout. Extend later with 'sbx --cloud ttl'.

Options

Global options

Examples

# Move a cloud sandbox down to the local host
sbx move sbx_abc123 --to local

# Move a local sandbox up to the cloud
sbx move my-sandbox --to cloud

# Give the destination sandbox a custom name
sbx move sbx_abc123 --to local --name big-refactor