Skip to main content
smolvm sandbox prune sweeps the SmolVM data directory for per-sandbox disks and runtime logs whose sandbox row is gone, and deletes them so the space comes back. A per-sandbox disk normally lives under disks/ in the SmolVM data directory and is reached through its row in the sandbox inventory. If a crash, a lost inventory, or a partial cleanup drops the row while the file survives, nothing else can find that disk by name. Over time these files accumulate. Run smolvm sandbox prune to find and delete them.
This is different from smolvm prune (an alias of smolvm image prune), which reclaims cached SmolVM images from older releases. sandbox prune acts on runtime state left behind by individual sandboxes, not image caches.

​
Synopsis

​
Options

​
flag
List the leftover disks and logs that would be deleted, and how much space would be freed, without deleting anything.
​
flag
Skip the interactive confirmation prompt. Required when running non-interactively or with --json.
​
flag
Also delete disks kept with retain_disk_on_delete=True. By default those are protected and reported under a separate “Kept” panel.
​
flag
Print a JSON envelope instead of formatted text. Combine with --force to run unattended.

​
What gets pruned

For every VM ID that no longer has a row in the inventory, sandbox prune considers:
  • The per-sandbox disk under disks/ (.qcow2 or .ext4) and its sidecar files.
  • The <vm_id>.log runtime log in the data directory.
It skips:
  • Disks flagged as saved by a marker file (see Retained disks) unless you pass --include-saved.
  • Disks referenced by a running process, since SDK-driven sandboxes keep their inventory in memory rather than on disk.

​
Examples

​
Preview what would be deleted

Always safe to run first:
Example output:

​
Delete the leftovers

You will be asked to confirm before anything is deleted. Pass --force to skip the prompt.

​
Use in automation

The JSON envelope lists the files removed, the files kept because they were marked as saved, and the total bytes freed.

​
Also delete saved disks

Disks kept with retain_disk_on_delete=True survive sandbox prune by design. If you actually want them gone:

​
Retained disks

When you set retain_disk_on_delete=True on a sandbox, SmolVM keeps its disk after the sandbox is deleted so a later sandbox with the same ID can pick it back up. To tell a deliberately kept disk apart from a leaked one, SmolVM writes a marker file (<disk>.retained) next to the disk when the sandbox is deleted. sandbox prune reads that marker and leaves marked disks alone.
Disks retained on releases before this behavior existed carry no marker, so sandbox prune treats them as leftovers. Before you run sandbox prune for the first time after upgrading, run it with --dry-run and check the list, or pass no flags at all and inspect the confirmation prompt. If you need to preserve pre-upgrade retained disks that you plan to re-attach, keep them out of the sweep by not running sandbox prune, or delete them explicitly with --include-saved once you’ve confirmed the list.

​
Exit codes

Last modified on August 21, 2026