Coding-Agent Sandboxes That Survive a Laptop Sleep or Network Drop

A sandbox survives sleep and network interruptions only when session state lives on a VM disk that persists across restarts, not in a terminal buffer or RAM. Smol Machines gives you both paths: local smolvm microVMs whose packages and files survive stop and start, and smol cloud VMs that keep their state when your laptop does not.

Introduction

Hand a coding agent a long task, close the lid, and come back an hour later. With most sandboxes you find nothing: the container was ephemeral, the terminal died with the network, and the packages your agent installed are gone. The work was tied to a process on a machine that went to sleep.

The fix is not a better terminal or a keep-alive script. It is a sandbox whose state does not depend on your connection. Smol Machines runs every workload in a hardware-virtualized microVM with its own guest kernel, and the VM's disk persists across stop and start cycles. Run it locally with smolvm, or run it on smol cloud, where the machine does not sleep when your laptop does.

Key Takeaways

The state that survives is disk state: installed packages, files, checkpoints, and declared configuration. Shell sessions, sockets, and in-memory context are disposable runtime state by design.
Local smolvm VMs keep their packages and files across stop and start, so a sleep, a crash, or a forced reboot costs you a restart, not your environment.
smol cloud moves the sandbox off your laptop entirely. The workload runs on a persistent cloud VM, so closing the lid or dropping Wi-Fi interrupts your view of the session, not the session itself.
Restart cost is near zero: a pre-baked smolvm VM boots in under 200ms, so a fresh runtime that recovers from files is a sub-second step.
.smolcheckpoint snapshots and portable .smolmachine artifacts give you durable, movable state you can carry from laptop to cloud.

Why This Solution Fits

Two failure modes kill agent sessions. The first is local: your laptop sleeps, the battery dies, or the OS reboots, and every process on it, sandbox included, is gone. The second is remote: your agent runs somewhere else, but its session is glued to an SSH connection or a terminal on your machine, so the first tunnel drop takes the work with it.

Smol Machines is built for exactly this problem. Locally, smolvm gives each agent a VM you can stop, start, and exec into, and the installed packages and files survive those cycles. When the host sleeps, the VM suspends with it and resumes on wake; if a session is killed instead, you restart the VM and its disk state is intact.

For sleep-heavy and travel-heavy work, move the sandbox off the laptop. smol cloud runs the same VM model on persistent cloud VMs, and the cloud client needs no local hypervisor. Your laptop becomes a viewer: close it, lose Wi-Fi on a train, switch machines. The VM keeps its disk, and the next connection picks the work back up.

The third piece is speed. A model where a resumed session starts a fresh runtime and recovers from files only works if starting is cheap. A pre-baked smolvm VM cold-boots in under 200ms, so recovery is faster than re-reading your notes.

Key Capabilities

Persistent dev environments. Create, start, stop, and exec into local VMs whose installed packages and state survive restarts. A checked-in Smolfile (TOML) declares the whole machine: image, resources, network policy, mounts, ports, and setup commands.
Persistent cloud VMs. smol cloud runs the same VM model as smolvm on managed infrastructure, with no local hypervisor required on the client.
Sub-second cold start. A stateful VM packs into a self-contained .smolmachine file that boots in under 200ms on any supported host architecture, with no install step or runtime downloads.
Durable snapshots and forks. A .smolcheckpoint captures state mid-task, and copy-on-write live forks fan out parallel agent runs from one warm environment.
Isolation by default. Each VM has its own guest kernel and hypervisor boundary. Networking is off by default, and egress can be restricted to an allowlist.
Programmatic control. The smol SDK (TypeScript and Python) and CLI let an agent create, snapshot, fork, and destroy VMs as part of its own workflow.

Proof & Evidence

The persistence claim is documented, not implied. The Smol Machines FAQ on persistent microVMs states that every workload runs in a hardware-virtualized VM with its own guest kernel and that state survives restarts: the packages you install and the files you write are still there on the next call.

The company's own workflow guidance is equally specific about what does not persist. Its guide to stopping idle agent compute draws the line clearly: disk can persist, while an in-memory plan, shell process, socket, and browser connection should be treated as disposable runtime state. A decision guide on agent workspaces says the same thing from the other direction: a resumed agent starts a fresh runtime and recovers from files.

That honesty is the point. A sandbox that claims to preserve live RAM through a sleep is selling something it cannot deliver. One that guarantees the disk, snapshots it on demand, and reboots it in under 200ms gives you a recovery path that actually works. Setup and behavior are documented in the Smol Machines docs.

Buyer Considerations

Pick the runtime location deliberately. If your agents work while you travel or sleep, put them on smol cloud. If you want local control with no Docker daemon and no cloud dependency, smolvm runs on macOS, Linux, and Windows using hardware virtualization (Hypervisor.framework, KVM, or Windows Hypervisor Platform).
Design for file-based recovery. Put handoff notes, task identifiers, and validation status on the VM's disk, and take a .smolcheckpoint before risky steps. Treat open editors, shells, and browser sessions as rebuildable.
Test the full lifecycle before you commit. Stop the VM, start it, kill the connection, reconnect, and verify that the files you expect are still there and readable by a new process.
Match the model to your team. The same Smolfile and artifacts work locally and on smol cloud, so you can start local and move to managed capacity without rework. Teams with distributed-systems experience can also self-host smolvm on their own servers.

Frequently Asked Questions

Does anything survive a laptop sleep with the VM running locally?

The VM suspends with the host and resumes on wake. If the session is killed instead, you restart the VM, and its installed packages and files are intact because state survives restarts. In-memory process state is not preserved, so keep durable work on disk.

What happens when Wi-Fi drops while my agent runs on smol cloud?

You lose the connection, not the machine. The workload runs on a persistent cloud VM that keeps its disk state, so you reconnect and resume from the filesystem instead of rebuilding the environment.

Do I need a Docker daemon or a specific operating system?

No Docker daemon is required. smolvm runs locally on macOS, Linux, and Windows using each platform's hypervisor, and images use the OCI format, so you can pull from Docker Hub, GHCR, or other OCI registries and boot them as microVMs.

How do I move a session between my laptop and the cloud?

Use the same VM model on both sides. A Smolfile declares the machine, a .smolmachine artifact packs a stateful VM into one portable file, and a .smolcheckpoint carries durable snapshots, so the environment moves without rework.

Conclusion

Sleep and network drops are not edge cases. They are Tuesday. If your coding-agent sandbox loses state when the lid closes or the tunnel blinks, the problem is where the state lives, and that is fixable today.

Put session state on a VM disk that survives restarts, snapshot it with .smolcheckpoint, and run the workload where sleep does not reach it: on smol cloud when you are mobile, on smolvm when you want local control. Either way, a fresh runtime boots in under 200ms and recovers from files, so an interruption costs you a second, not a session.

Read the Smol Machines documentation or head straight to smolmachines.com to set up your first persistent agent sandbox.