Skip to main content
Save a prepared sandbox and reuse it as a starting point. Each restore creates a new sandbox and leaves the source unchanged.

Snapshot types

Disk is the default. Full adds memory and execution state; there is no memory-only snapshot.

Disk snapshots

Use disk snapshots for installed dependencies, prepared workspaces, and saved files. Cloud requires a stopped persistent source. See guest flushing for how microsandbox handles pending writes.
1

Prepare

Start a python:3.12 sandbox named baseline using the create guide, then install a dependency:
2

Capture

Save the prepared state as ready:
3

Restore

Restore into worker. Its disk writes are independent of the source.
Local snapshots use group:member selectors, such as baseline:ready. For cloud, pass the snapshot object or reference; it has no client-local path.

Full snapshots

Capture a running workload to resume its processes and memory later. A running source briefly pauses during capture, then resumes; an already-paused source stays paused. On Windows, full snapshots now preserve all tracked hardlink names for bind mounts. Runtimes that support this format can still restore the previous Windows filesystem format. Older runtimes cannot restore snapshots written with the new bind-mount format; use the updated runtime when restoring them. This does not change disk-only snapshot compatibility.
1

Capture

Start with a running or paused sandbox named worker:
2

Restore

Resume in a new sandbox. The image’s startup command does not run again.
  • Compatibility: Use a compatible runtime and guest kernel. CPU and memory settings, including maximums, must match the capture.
  • Connections: Reconnect clients and application connections. Microsandbox does not capture host-side connections or transfers, and does not replay buffered process output.
  • Mounts: Owned volumes are private to each child. Host bindings need explicit authorization; see mount behavior.
If capture saves an artifact but cannot recover the source, inspect the artifact reported in the error before retrying. A packaging failure may leave only a runtime checkpoint.If restore leaves an incomplete child, remove it and restore again; the snapshot remains reusable. Older development full snapshots may need recapture or disk-only restore.

Share memory

Full restores normally copy memory. Enable copy-on-write (CoW) to share unchanged pages between children while keeping writes private:
The first restore prepares a local memory cache; later restores reuse it. No special source setup is needed. CoW requires a full snapshot and cannot be combined with disk-only restore.
The old forked options still enable copy-on-write memory during restore. Use these names in new code:The MCP sandbox_restore tool retains its forked input for the same memory option.

Restore disk only

Boot a fresh VM from a full snapshot’s saved disk without resuming its processes. You can choose different CPU and memory settings.
Snapshots with a tmpfs root cannot be restored disk-only.

Keep the guest clock

By default (sync), the sandbox’s date and time follow the host. The host updates the clock at boot, about once a minute, and when a full snapshot restores or a paused sandbox resumes. With off, the host stops updating the clock after boot. Full restores continue from the snapshot’s saved time. The clock keeps running, making this useful for tests that need a repeatable starting time.
Full snapshots save this setting. Restores inherit it unless you choose sync to use host time or off to continue from the saved time:
  • Scope: off prevents host clock updates. Programs inside the sandbox with permission to set the time can still change it.
  • Drift: With off, the guest clock is not corrected after the host sleeps or its clock changes.
  • Monotonic clock: Continues from the snapshot in both modes.
  • Forks: Forks inherit this setting.
  • Compatibility: Older runtimes reject off. Older SDKs and CLIs reject full snapshots saved with off, including exported archives. Cloud also rejects off.
  • Downgrades: Older SDKs and CLIs require a database downgrade to reopen this installation. Downgrading is blocked while any sandbox’s saved or active settings use off.

Guest flushing

Guest flushing writes pending filesystem changes from memory to disk. It works the same way in the CLI and all SDKs, for snapshots, forking, and pausing. The default auto policy flushes running disk snapshots. Full snapshots and forks keep those changes in memory instead. Choose required if you plan to restore a full snapshot’s disks without its memory:
Flushing does not save data still buffered by your application or commit database transactions. Save or commit that data before capturing the snapshot.
  • Paused sandboxes: Pause with required before taking a disk snapshot. Capture fails if the needed flush was not done before pausing; it never resumes the sandbox to flush.
  • Stopped or crashed sandboxes: auto and skip capture the saved disk state. required fails because no guest is running.
  • Storage: Flushing covers the root and captured block disks, including owned disks. It does not make tmpfs persistent. Host storage synchronization and snapshot durability remain enforced with every policy.
  • Compatibility: Older runtimes may reject the policy; restart the sandbox with an updated runtime. Cloud supports only auto.

Forking

Create a child directly from a running or paused sandbox, without saving a reusable snapshot. Forking preserves disk and execution state. Memory sharing is built in; each child’s writes stay private. To start from a saved snapshot, use restore. The former branch SDK methods remain deprecated aliases for fork.
The source returns to its previous running or paused state. Each child needs a new name and cannot inherit published host ports. Host mounts follow the same binding rules.
Capture once for several children:
Each child gets its own result; a failed child does not remove successful siblings. Validation or capture errors fail the call. Deleting the source or a sibling does not invalidate other children.

Mount behavior

Owned directory snapshots cannot move between Unix and Windows. Owned disks do not have this restriction.

External mounts

Snapshots do not include host-mounted files. Supply their host paths when restoring. Owned volumes restore automatically. Full restore requires every captured external filesystem and additional disk to be available. For either a disk or full snapshot, mount a host directory like this:
Using the same host directory for the source and restored sandbox shares its files.
  • Reuse source bindings: Restore on the same host using the source’s validated mounts. Missing dependencies still cause restore to fail.
  • Select a captured disk: Restore a private copy of a named disk volume. External disk images are not converted to owned volumes.
  • Allow missing resources: Continue without an external filesystem or additional disk. Root and owned storage must still be complete. Access to missing resources fails and may disrupt applications or make filesystems read-only.
Each example below restores a separate sandbox using one of these options:
Allowing missing resources does not reuse source bindings or accept changed files; see Validate mounts. Warnings remain visible even when progress output is suppressed.Direct forking keeps its existing behavior for unavailable resources. Disk-only restore boots fresh rather than resuming open filesystem handles.

Validate mounts

Full restore and forking validate captured filesystem identities. Strict is the default; relaxed mode accepts supported differences and reports warnings:
Relaxed mode accepts supported changes to supplied filesystem objects. It still checks integrity and requires access to the supplied paths. It does not recreate missing files or allow missing resources.
Full snapshots retain clean cache pages, so reads may return captured bytes before reaching the host. Strict validation checks identity at restore time; it does not lock files against later edits.External files deleted while still open, and special files, can prevent capture. Owned directories support deleted open regular files. Restore warnings identify inaccessible or changed objects; see your SDK reference for details.

Manage snapshots

These operations apply to disk and full snapshots. Cloud supports basic disk snapshot management; groups, archives, verification, and disk maintenance below are local-only.

Restore progress

Track local disk or full restore through image preparation, memory preparation, and activation. Wait for the final result before using the sandbox:
In Go, always receive the result and close its sandbox handle when finished, even if you ignore progress events. Closing a restored handle does not stop the detached sandbox; call Stop or Destroy when needed. Cancel the context to cancel the operation. Some stages have no percentage. Memory preparation has no fixed timeout; activation has a separate timeout. Set an overall deadline or use SDK cancellation when needed.

Manage saved snapshots

List snapshots, inspect one, or remove it:

Snapshot groups

A group keeps related snapshots together. Restore an earlier snapshot and save new changes to explore a different path while keeping the original snapshots. Choose the original group when capturing to keep the new snapshots in that group; otherwise, the group defaults to the restored sandbox’s name. Since v0.7, installed snapshot members are immutable. Creating another snapshot cannot overwrite an existing member. In SDK calls, omit force or set it to false (False in Python): enabling it fails even when the requested name does not exist. Use a unique or generated member name for each capture. To reuse a name, explicitly remove the existing member first; removal still checks for dependent snapshots. See the v0.6 snapshot upgrade example. Locally, group selects its head; group:member selects an exact snapshot:
The first capture sets the head. Later captures or imports advance it only with proven ancestry; older or divergent snapshots leave it unchanged. Select another head before removing the current one if other members remain.
Imports without a group create a new one. Select an imported head explicitly when needed:
Identical members can be reused; conflicting IDs or names fail. Publication never overwrites an existing member. Inspect the group before retrying an interrupted import.

Move snapshots

Archives let you move local disk or full snapshots between machines.

Export and restore

Copy either snapshot type to another machine as a .msb archive. Include the image for offline restore:
On the destination:
The archive keeps its type: disk boots fresh; full resumes execution. Existing .tar and .tar.zst archives also work. Full compatibility and owned-directory platform restrictions still apply.

Import archives

Load a base and dependent archives together; order does not matter:
Dependencies come from the batch or matching members of the named group. Supply an explicit base for other dependencies; unrelated groups are not searched. All members are validated before publication. Divergent tips require choosing a head; forcing an ambiguous head fails.

Export changes

Export only disk layers and full-snapshot RAM objects not supplied by an exact base:
The root and every shared owned disk must match the base’s physical prefix. New owned disks are complete. Owned directory namespaces and full execution maps remain complete; unchanged payloads may come from the base. Import or restore with that base:
Missing dependencies fail before publication or execution. Once loaded or restored, the result owns its files and no longer depends on the base.
The last-layers option exports only the newest root layers, keeping owned disks and required RAM complete. Do not combine it with since-base export, or use either with parent-chain or whole-group export.After compaction, export a new standalone baseline. Independent stopped captures can also get new layer identities despite identical bytes; use a standalone export when the base no longer matches.

Capture to an archive

Capture directly to an archive without installing a snapshot locally. Disk is the default; add the full option for execution state:
Direct capture pins the image but does not bundle its cache. For offline use, create an installed snapshot and export with the image. Restore the archive directly using the same restore APIs.

Compact disks

Merge sealed disk layers in a running or fully stopped local sandbox. This affects disk storage, including disks in full snapshots, not memory. Preview before applying:
The default covers the root and owned data disks, excluding named/external volumes and directories. The layer limit includes the base but never the writable head; it must be at least two. Omit it to merge all sealed layers. Existing snapshots remain valid and retain storage until removed.
Each disk commits separately. If compaction fails, a running VM may stay paused. Restart to recover from disk journals; do not assume rollback or blindly retry.
Use the SDK references for disk selection and result fields. Do not combine compaction with unrelated modifications.

Verify integrity

Disk content hashing is opt-in. Record hashes during capture, then verify when receiving or checking a snapshot:
Without hashes, size and structure checks cannot detect same-length disk corruption. Save and load preserve recorded integrity but do not scan it automatically. Full-snapshot RAM has separate content-addressed checks; fork RAM is not hashed.

Troubleshooting

Reference

See each SDK reference for setup, imports, optional controls, and result fields.
  • SDKs: TypeScript, Rust, Python, and Go.
  • CLI: Run msb snap --help or msb snap restore --help for all options.