The failure of a coding agent mid-task has long been treated as a reason to start over. When an agent exhausts its budget, encounters an unhandled error, or hits a dead end, the common response is to reset the environment and begin from the initial state. This retry-from-scratch pattern discards every machine state change accumulated during the previous run—temporary database entries, started services, modified configuration files, and any other runtime context. The result is not just wasted compute; it is a fundamental inefficiency in how agents recover from failure.
This paper investigates whether intermediate environment states carry meaningful progress that can be recovered and built upon. The authors argue that if a snapshot of the full development environment—files, processes, data, and state—is preserved, then restoring and branching from that snapshot could outperform repeated restarts. The core claim is that the value of a snapshot lies less in the code diff and more in the surrounding runtime state that a diff alone cannot capture.
To test this, the authors implement a Go-Explore-style search over full Daytona snapshots. Go-Explore is a framework known for its ability to systematically explore and return to promising states in stochastic environments. Applied to coding agent workflows, the approach systematically archives snapshots at regular intervals and later samples from them when the agent fails, effectively creating a structured search over past progress.
The experimental results show that higher and more efficient solve rates depend mainly on progress that sits outside the repository. Databases, external services, and other runtime state constitute the bulk of the preserved value. When an agent fails after having, for example, initialized a PostgreSQL database, seeded it with test data, and started a local development server, restarting from scratch means re-establishing all of that from memory or configuration. The snapshot approach avoids that rework.
An important secondary finding concerns the scope of the coding task. Full-snapshot search proves most effective when long-horizon coding work spans multiple services whose state cannot be reconstructed from a single diff. If an agent’s progress involves coordinating changes across a frontend, a backend API, a message queue, and a caching layer, the cumulative state becomes too complex to reconstruct via textual diffs alone. In such cases, preserving the entire sandbox snapshot—including process IDs, network ports, and in-memory data—offers a decisive advantage.
The authors acknowledge limitations. The approach requires storage and management of snapshots, which scales with the size of the development environment. Not every coding task benefits equally; short, self-contained edits inside a single repository may see little improvement. The greatest gains appear in scenarios where the agent’s value accumulates in external state rather than in the source code itself.
For working developers, the takeaway is that snapshot-based recovery is not a universal replacement for restarting, but a targeted improvement for certain classes of problems. When an agent’s workflow involves databases, services, or other runtime infrastructure, preserving full sandbox state between attempts can dramatically reduce the time to solution. The paper suggests that future coding agent frameworks should consider checkpointing not just source files, but the entire execution environment.