The snapshot that arrived thirty-nine times

Claude Code had finished. The stack compiled, the tests passed, and the Work Room showed Completed. Then the parent agent asked to list the new project so it could verify the result. The browser should have shown one small approval card. Instead, the input disappeared and five minutes passed in silence.

The durable session told a different story from the screen. It contained the model's verification call, its action summary, and the pending approval. The agent was waiting honestly; the browser simply had not reached the question. That distinction sent us away from provider permissions and toward the queue between a committed tool transaction and its client.

Long-running coding tools publish activity while they work, but keep their canonical state private until the transaction commits. Every activity entry had also captured a complete session snapshot. When Claude returned, thirty-nine trace entries committed in order—and each brought another, mostly superseded, snapshot with it. In this run the newest snapshot was about 475 KB. The tiny approval was standing behind roughly 17.7 MiB of old versions of the same conversation.

The fix follows the meaning of an atomic commit. Every trace entry still survives in order, because each describes something that happened. Session snapshots are different: before the transaction becomes visible, a newer one fully replaces the older one. The transaction now retains only the latest snapshot and publishes it after its traces.

The lesson is not merely to send fewer bytes. Event history and state snapshots have different identities. History accumulates; snapshots supersede. Treating both as append-only can make a truthful approval look like a broken client—and the longer and more useful the Work Room conversation becomes, the worse that mistake gets.