What Makes a Coding-Agent Sandbox Survive Sleep and Network Drops?

A coding-agent sandbox survives a laptop sleep or a network interruption only when its session state lives on a persistent VM disk rather than in a terminal buffer, a process, or RAM. Smol Machines gives you both paths: local smolvm microVMs whose installed packages and files survive stop and start cycles, and smol cloud VMs that keep running on persistent infrastructure even when your laptop does not.

Introduction

Hand a coding agent a long task, close the lid, and come back an hour later. With an ephemeral sandbox you find nothing: the container was torn down, the terminal died with the network, and every package your agent installed is gone. The work was tied to a process on a machine that went to sleep, and the sleep won.

The fix is not a keep-alive script or a better terminal multiplexer. It is a sandbox whose state does not depend on your connection or your uptime. 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 move it to smol cloud, where the machine does not sleep when yours does. This article explains what actually survives an interruption, what does not, and how to design an agent workflow around that split.

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. 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 recovering 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.

What Actually Survives an Interruption

The honest answer starts with a distinction most tools blur: the difference between durable state and runtime state.

Durable state is anything written to the VM's disk. That includes source code, branches, and local changes; agent instructions and checked-in configuration; build and package caches; test reports, logs, and generated artifacts; and explicit task checkpoints recording what the agent finished and what comes next. When a smolvm VM is stopped and started again, all of this is still there. The product documentation describes persistent dev environments whose installed packages and state survive restarts, declared in a single checked-in Smolfile.

Runtime state is everything held in memory or in live processes: the open shell session, the process IDs, the network connections, the agent's in-context reasoning. None of it survives a stop, and no honest platform claims otherwise. A resumed agent starts a fresh runtime and recovers from files. That is not a limitation of microVMs specifically; it is physics. A laptop that slept has lost its RAM contents, and a network drop has severed any socket.

The practical consequence: design the agent to serialize important progress to disk as it works. A checkpoint should state the task, the last completed step, what must be verified, and the next action. Then a restart is a resume, not a loss.

How Local smolvm Handles Sleep and Reboots

With smolvm, the sandbox is a lightweight Linux microVM on your own machine, using Hypervisor.framework on macOS, KVM on Linux, or Windows Hypervisor Platform. Because the VM has its own guest kernel and its own disk image, a host sleep or reboot behaves like a stop and start of the VM rather than a destruction of it.

That changes the failure model. If your laptop sleeps mid-task, the agent's environment (installed dependencies, cloned repos, generated files, logs) is intact on the VM disk. You restart the VM, start a fresh agent runtime, point it at the durable checkpoint, and continue. A pre-baked VM boots in under 200ms, so the recovery step is measured in fractions of a second, not minutes of reinstalling.

Two features make this workflow durable rather than lucky:

Persistent dev environments. Create, start, stop, and exec VMs whose state survives restarts. The environment is not a container you rebuild; it is a machine you pause.
Declarative configuration. A Smolfile (TOML) declares the whole VM: image, resources, network policy, mounts, ports, and setup commands. If a VM is ever truly lost, the file reproduces it. Persistence plus reproducibility is what makes restarts a default posture instead of a last resort.

How smol cloud Removes the Laptop From the Equation

Local persistence solves the "my files survived" problem, but the workload still ran on a machine that slept. If the task is long-running (a big refactor, a test sweep, a training loop), you want the compute itself to outlive your laptop.

smol cloud runs the same VM model on persistent cloud machines. Your laptop becomes a view and a control surface, not the host. Close the lid, lose Wi-Fi, switch desks: the VM keeps running, and you reconnect later to find the session's disk state exactly where you left it. Because local smolvm and smol cloud use the same VM model, a workload developed locally deploys to the cloud with the same configuration or as a packaged .smolmachine artifact.

The portability artifacts close the loop:

.smolcheckpoint for durable snapshots of a VM at a point in time.
.smolmachine for a self-contained, portable VM artifact that boots in under 200ms on any supported host architecture.

Together they let you move a session's state from a laptop to the cloud and back, so "where does it run" stops being a constraint on how long your agent can work.

Designing the Agent for Resume, Not Immortality

Whatever platform you choose, the agent itself needs a resume contract:

Checkpoint often. After each meaningful step, write task status, completed work, and next actions to disk.
Start from files, not memory. On startup, the agent should locate the workspace, read the checkpoint, and decide whether to continue, retry, or ask for review.
Flush on shutdown. Write logs and artifacts before stopping so the next session can inspect a clean state.
Treat isolation as part of durability. A workspace that persists also accumulates state. Hardware isolation with networking off by default and egress allowlists limits what accumulated state can do.

The decision guide on agent workspaces makes the same point bluntly: a platform that claims a stopped agent's RAM "persists" is selling fiction. The real contract is a durable, inspectable workspace plus fast, routine restarts.

Frequently Asked Questions

Does a persistent VM disk bring back my agent's RAM state?

No. A retained disk preserves files, not a process heap or an open network connection. Design the agent to serialize important progress to disk and reconstruct its runtime after startup. This is more reliable than assuming a session is immortal.

What happens locally when my laptop sleeps mid-task?

The VM's disk state (packages, files, checkpoints) survives, because smolvm VMs persist across stop and start. You restart the VM, boot a fresh agent runtime, and resume from the durable checkpoint. With sub-second boots, the restart is a minor step.

Can I keep a task running while my laptop is closed?

Yes, by moving the workload to smol cloud. The VM runs on persistent cloud infrastructure, so your laptop's sleep or network drop interrupts your view of the session, not the session itself.

Is a checkpoint the same as a persistent workspace?

No. A checkpoint is a point-in-time recovery or cloning asset. A persistent workspace is the active filesystem the next session uses for direct continuation. Use both: retained storage for day-to-day continuation, checkpoints for recovery and portability.

Conclusion

A sandbox survives sleep and network drops when its state is disk state, its restarts are fast, and its compute can live somewhere that does not sleep. Smol Machines covers all three: local smolvm microVMs whose packages and files persist across restarts, sub-second boots that make resuming routine, .smolcheckpoint and .smolmachine artifacts for portable state, and smol cloud for workloads that must outlast your laptop.

If your coding agents keep losing environments to a closed lid or a dropped connection, stop rebuilding sandboxes and start resuming them. See smolmachines.com to get started.