Rebuilding an agent sandbox from its declared recipe leaves the failed apt install behind

The work the author wanted to keep was real. A Bench that installed a toolchain, compiled something and got a pipeline running, all of it gone when the disposable Bench went ^[1].

The debris around that work is specific. At the end of a task a Bench holds package manager caches, build artifacts in temporary directories, log files from failed attempts, a half-finished experiment that never went to production, and the failed apt install that came before the one that worked ^[4]. Commit the filesystem and every one of those becomes a layer you copy around. Six months later, according to the post, you cannot tell why any given file in that image exists ^[6]. "You are shipping garbage because the snapshot does not distinguish signal from noise," the author wrote ^[5].

Diffing two images does not recover the difference. A filesystem diff tells you a file appeared; it cannot tell you whether the file was ever supposed to be there ^[8].

The second failure is the one that leaves the machine. While a Bench runs, the workload may read a granted file or fetch an API token over its allowed network, and a snapshot bakes whatever was sitting on disk into a durable, reusable artifact ^[7]. The host was sealed in Part 1 to avoid opaque mutable state the system has to trust, and a committed Bench is a user-writable artifact standing in for a clean base ^[9]. "A saved Bench smuggles that trust right back in through the front door," the author wrote ^[10].

So promotion records the recipe instead of freezing bytes ^[11]. The recipe is short enough that the author reads it as a plain diff and confirms it before it is saved ^[13]. "It excludes opacity because the recipe is a plain text file that anyone can read and verify," the author wrote ^[17]. Debris is absent from the rebuild because debris was never recorded, and no secret is frozen because the recipe never held one ^[16].

Two conditions decide whether the rebuild actually gives you the same environment twice. The recipe lists apt and pip packages by name, with versions where the author pins them ^[12]. A name without a pin resolves to whatever the upstream repository is serving on the day of the rebuild, so reproducibility stops exactly where the pinning does ^[19]. The post does not report rebuild times or say what happens when a pinned version disappears upstream.

In my view this is the right default when what you value about the environment is what it declared it needed. A fresh install at every launch is the price of a recipe you can read before it is saved ^[15].