Skip to main content
The session returned by create_sandbox_session runs commands, saves checkpoints, and switches between branches. Use the connection from Your first sandbox.

Run commands and save a checkpoint

These two commands share one VM. snapshot() is a lightweight operation that saves their files and stops the running VM. The next command starts from the saved image. You can snapshot as often as needed, including after every command. If the filesystem has not changed, a snapshot can return the same image_uuid. This is normal: a new checkpoint does not require a new image UUID.
The program prints the saved image UUID. Files survive a snapshot; processes and memory do not. Normal context exit saves pending work. An exception aborts unsaved work; completed snapshots remain available. The default policy also saves after 10 idle seconds. Each snapshot is one checkpoint, even when it contains several commands.

Save after every command

Pass session_type=ContreeSession or ContreeAsyncSession to save each command automatically. Each command runs in a separate VM, which stops when it finishes. The next command starts from the saved image. No explicit snapshot() is needed.
Set disposable=True on a command to leave the session image unchanged. The default commit policy saves completed operations even when the command exits with a nonzero code. Failed or cancelled operations do not advance history. Use the default LazySession when commands need the same running processes. It keeps the VM until a snapshot. Choose snapshot frequency to match the required checkpoints and process lifetime. An unchanged filesystem can produce the same image UUID in either mode.

Start a new session from a snapshot

Each session builds an independent chain of saved images. Only the Store records the links between history nodes and the positions of branches. An image_uuid identifies saved files; it does not carry SDK session history. You can start any number of new sessions from any history node’s image_uuid, or from any other image UUID you can access. Each session has its own history. Changes in one session do not change the source image or other sessions.
Reuse image_uuid in further create_sandbox_session(image=image_uuid) calls to start more independent sessions. The source session can already be closed. The new sessions do not inherit its history, branch names, or Store metadata. If you share a Store, omit session_id to generate a new ID, or supply an unused ID. An existing ID resumes that session instead; see Save and resume a session.

Continue with a task

History uses an in-memory Store by default. To resume later, supply a SQLite Store and a stable session_id. Filesystem images remain on the ConTree server.