Checkpoints: undo anything
Every agent turn is saved automatically as a checkpoint. You can roll your preview back to an earlier point, or fork the whole app to experiment safely, and you'll know exactly what each one does and doesn't restore.
How automatic checkpoints work
Emergent saves a checkpoint every time the agent finishes a turn. Think of these as save points - if a change breaks something, you can return to the last point where everything worked.
Rolling back erases the chat messages and code changes made after the point you choose (there's an option to erase messages only). There is no roll-forward: once you roll back and continue, the erased work is gone. When in doubt, fork first (below), the fork keeps a full copy while you experiment.
Going back to an earlier version
If the agent breaks something - maybe it removed a button, deleted files you need, or misunderstood an instruction - roll back to a point when everything worked.
Rollback lives on the chat timeline: each message has a Rollback button. Scroll to the last message where the app was in a good state.
You can erase messages and code (the full revert) or messages only.
Click Rollback. Your preview is restored to that point. Rollback affects preview only, your live app keeps running its last published version until you Re-publish. Your app's web address and database records are unchanged.
Experimenting without risk: forking
Sometimes you don't want to undo - you want to try something big without touching your working app. That's what forking is for.
Forking creates a complete, independent copy of your app. The original keeps running; the copy (the "fork") becomes a separate job where you can experiment freely.
Click the + button in the chat input bar, then click Fork this chat.
The Configure New Chat dialog opens: your chat history is condensed into an editable summary the fork starts from (review it, add anything important), and you can pick the model for the new chat.
The fork appears as its own job. Chat, build, and publish in the fork without affecting the original. If the experiment works, keep the fork. If it fails, just delete it and go back to the original.
Thinking of asking the agent to "refactor the entire backend"? Fork first. If things go sideways, you haven't lost anything, the fork is a full copy of your code and data.
What gets copied when you fork
- All your code and files at the moment of the fork
- Database contents (code and data are cloned from the volume at the fork point)
- Chat history up to the fork point is summarized (editable) in the new job, it is not carried verbatim, so early details may need re-stating
- Build settings and environment variables
Rollback vs. fork: when to use each
| You want to... | Use |
|---|---|
| Undo a recent bad change | Rollback |
| Try a big experiment without touching the working app | Fork |
| Build a variant for a different customer or use case | Fork |
| Escape an agent that's stuck repeating itself | Fork (fresh conversation from the current code state, see When something breaks) |
| Recover from multiple mistakes over time | Rollback to a known-good state, then fork if you want to explore a different direction in parallel |
Rollback is "undo back to a point" (and it erases what came after). Forking is "duplicate and diverge" (nothing is erased).
If something looks wrong after rolling back
Rollback restores your preview code to the selected point in the chat timeline. Re-publish to update the live app. If the old code expects the database to look different than it does now, you might see errors until you manually clean up or adjust the data.
✅ All source code files ✅ Dependencies and packages ✅ Environment variables ✅ Build configuration ✅ Database structure (table structures, indexes)
❌ Database data (your actual records stay as-is) ❌ External connection keys stored outside the platform ❌ Custom domain DNS records
Always test your app after a rollback to make sure critical features still work.
Go deeper: Forking
