msb df reports aggregate storage for the selected local backend. Use msb inspect NAME or msb snap inspect REF for an individual object’s managed files. Cloud accounting and pruning return an explicit unsupported-operation error.
msb df
--verbose adds object paths, allocated-block observations, and reasons entries are retained or could not be measured. Unknown measurements appear as - in tables and null in JSON.
Image references share layers, so image accounting scans the shared cache instead of summing each image’s advertised size. Managed-directory totals include metadata and unindexed files. Indexed external snapshot directories are included; host bind mounts, external linked payloads, unindexed external snapshots, and anonymous Linux RAM are excluded. Concurrent filesystem activity can change measurements while a scan runs.
Logical file lengths and allocated blocks do not measure unique physical storage on filesystems with shared copy-on-write extents. Removing 1 GiB of logical data may free less physical space. There is no combined total when categories may overlap.
msb prune
msb image prune command for image cleanup.
--older-than accepts a nonnegative integer followed by s, m, h, or d. It filters backing modification times, which clones can inherit. Age is only an eligibility filter: ownership locks are checked independently on every removal.
Without
--yes, applying prune requires an interactive terminal and confirmation. Quiet output never bypasses confirmation. Ownership is rechecked after the prompt, so the applied result may differ from the preview.
JSON includes entries, files_removed, logical_bytes_removed, and physical_bytes_reclaimed. The latter remains null: the command does not claim physical storage savings. Entries explain in_use, pending_handoff, too_young, missing_handoff_lock, changed, or error decisions. An error report retains successful removal counts and exits unsuccessfully; a caller can retry later. Dry-run entries use reclaimable and removal counters remain zero.
Automatic branch cleanup
Branch backing is reclaimed best-effort after its last tracked SDK or baseline owner releases it, provided no other pin or handoff remains. Paused sandboxes retain their backing. Runtime process exit and abrupt termination release kernel pins. After a graceful stop, cleanup tries the stopped branch’s exact backing file and then traverses the branch cache in bounded passes without pauses between them; CLI commands wait for that traversal after the graceful-stop result, while SDK callers can continue without waiting. A subsequent branch also triggers a bounded sweep for leftovers, limited to once every 30 seconds within one SDK process. Automatic cleanup targets branch memory. Unused snapshot RAM realizations remain available for warm restores until explicitly pruned. Neither path changes memory bytes, snapshot formats, or checkpoint sparsity.SDK reporting
The Rust SDK uses the same accounting and reclamation implementation as the CLI:Storage::usage_local and Storage::prune_local accept an explicit LocalBackend. Object methods retain the backend captured by their handles. SDK pruning is an explicit operation and has no interactive confirmation; use dry_run to inspect first. Per-object storage measures managed files and describes exclusions. Exact attribution of shared RAM to individual sandboxes is not currently available; aggregate memory accounting reports whether pins or handoffs retain it.
Python, Node, and Go expose the same aggregate reports and ownership checks:
bigint to preserve the complete unsigned 64-bit range; unknown values are null. Python uses integers and None, and Go uses unsigned integers with pointers for nullable measurements. Prune reports retain per-file errors alongside any successful removals, so SDK callers should inspect the report’s entries.