The type, the fixture, and the render stop agreeing

It is when the data shape (the TypeScript type, the seed fixture, the localStorage key, the JSON your handlers read or write) moves faster than the code consuming it, so old data, old renders, and new code stop agreeing. In practice it shows up as 'why is this row blank,' 'why does Add throw,' or 'why does refresh wipe it.' The cause is almost always a turn that updated the shape in one file but missed a consumer that still expects the prior shape.

It treats every iteration turn as a single atomic git commit. commitTurn at src/core/e2b.ts:1759 runs 'git add -A && git commit -q -m ...&& git rev-parse HEAD' inside the VM. The 'git add -A' stages every modified, added, or deleted file at once. So a turn that changes Todo in src/types.ts also captures the fixture rewrite, the consumer fix, the new component, and the deletion of the dead one as a single SHA. There is no half of a turn. Either the whole shape change lands or none of it does.

It does not prevent the forgetting. It bounds the cost of recovery. If turn 3 missed AddTodo, you can ask 'undo'. undoTurn at src/core/e2b.ts:1855 walks the historyStack back one step and runs 'git checkout <previous-sha> -- .' (revertToSha at line 1815). The whole tree restores: the type, the fixtures, the consumer, the renamed file, and the new component all snap back to a coherent shape. Without this, undo has to be 'please write back the version you wrote two prompts ago,' and the model gets it close but not exact, which is itself a source of drift.

Source files survive, every byte of them, because git is restoring the working tree. What does not survive: localStorage written by the running app between commits, in-memory React state, external side effects like rows written to Neon or contacts added to a Resend audience. If the agent provisioned a database during turn 3 and undo brings the schema migration back, the rows you wrote in between are still there with the new shape. The honest framing is: undo restores the code, not the world the code touched.

Each project's Chromium runs with a persistent profile at /root/.chromium-profile/ inside the VM (vm-claude-md.ts:276), and localStorage persists within the session. That is what makes the drift painful in turn 4 of the example above: the old-shape records are still there after the type changed. The clean recovery is to reload after an undo, which means most state in localStorage is treated as soft. If you ask for hard durability, the agent provisions Neon and the data stops being your problem and starts being your schema-migration problem.

Most builders that 'have git' commit at session checkpoints, not at every turn. The difference matters. Per-turn means undo is one click; per-session means undo is a reset. The historyStack and activeIndex on the session document (src/core/e2b.ts:99-102) also let you fork: undo three turns, prompt a different direction, and the original branch is still in the SHA list. We use the fork-on-undo pattern when a turn introduced a shape we are not sure about and want to compare two versions.

Those are out of git's reach by design. The provision_database, provision_audience, and related actions are documented in vm-claude-md.ts and write to real third-party services. A schema migration the agent runs against Neon during turn 3 will not undo when you undo turn 3 in-app; the row is in Neon. The agent's CLAUDE.md tells it to mirror schema changes back into the Drizzle migration files in src/db/, so at least the source-of-truth schema is on the same SHA timeline as the rest of your code, but the live database is not. Treat external state as a separate timeline and write idempotent migrations.

Three options. First, name it in the next prompt: 'after this change every consumer of Todo must read the new shape, audit src/components and fix.' The agent re-reads files and patches consumers. Second, undo and try a smaller turn: 'add only the order field, do not rename text.' Third, fork: undo two steps, prompt a different shape entirely, and compare. The historyStack keeps the abandoned branch around. The path you should not take is the long, restating prompt that asks the model to recreate the old version from memory.

The history endpoint exists at src/app/api/chat/history. It reads session.historyStack from Firestore and returns the ordered SHAs with their commit messages. The chat UI shows it as a per-turn timeline you can revert, undo, and redo against. activeIndex tells you which SHA is currently checked out, which matters after a chain of undos and redos because the live working tree may not be the latest SHA in the stack.

Yes, but indirectly. The orphan-component bug is a subset of drift: a new file lands but is not imported anywhere, so it has no consumers. 'git add -A' captures the orphan in the SHA, which means undo reliably removes it instead of leaving a dead file behind. The agent's CLAUDE.md (built into the E2B template) instructs it to import every new component into src/App.tsx and verify the DOM rendered via Playwright after a UI change. The mitigation is a habit, the recovery is the SHA.