Customize the sandbox image
sbxm add creates a Dockerfile in the project’s host-side directory. Edit that file to add tools or system dependencies.
Rebuild
Section titled “Rebuild”sbxm rebuild <project-id>Rebuild applies the Dockerfile by recreating the sandbox, whether or not the file changed. The old writable layer is lost. It also rebuilds the repository setup and managed worktrees.
Before rebuilding
Section titled “Before rebuilding”The normal rebuild protects work by checking for:
- dirty files
- unpublished commits
- an in-progress Git operation
- repository-level refs such as local branches, tags, notes, stash entries, extra remotes, and reflog-only commits
- unmanaged worktrees
- a Dockerfile or artifact that belongs to another project
Commit and push what you want to keep, remove what you do not need, and
inspect unmanaged worktrees yourself. Commits on branches, tags, or worktree
HEADs that you do not want to push yet can be saved into the host repository
instead: when they are the only thing stopping the rebuild, an interactive
rebuild offers to save them and continue. Stash
and notes commits are not saved this way. A clean worktree does not prove that the
repository has no Layer A blocker. sbxm does not delete unrelated work to make
a rebuild fit.
Add worktrees without rebuilding
Section titled “Add worktrees without rebuilding”If only the number of managed worktrees changes, use:
sbxm apply <project-id> --worktrees 4Use managed worktrees for the count and attached/detached behavior.