Version history and restoring
Every file the builder touches is recorded before and after. Any run can be rolled back — and the rollback is itself a run you can roll back.
Bookbag records every file change the builder makes. Not a diff — the whole file, as it was before and as it is after. That record is what makes undo possible.
Open it from the project-name dropdown in the top bar: Version history.
What a version is
One entry in the panel is one build run, and inside it, one row per file that run changed. Each row stores:
- the path,
- whether the file was created, changed or deleted,
- its entire contents before the change (empty, if the file did not exist),
- its entire contents after (empty, if it was deleted).
Whole contents rather than diffs is a deliberate choice. Generated app files are small, and a whole-file snapshot restores correctly without a patch algorithm that could fail halfway.
What the panel shows
The title is Version history, and under it: "Every change the builder made, newest first. Restore rolls the project back to how it was before that step."
Each entry shows:
- The prompt that started the run, in bold. A run with no prompt shows
Run #<id>. - How long ago it happened.
- A green
· currentmarker on the newest entry. - File badges in monospace, each the path plus a label: added, changed or removed. Only the first eight are shown; the rest collapse into a
+N morebadge. - A Restore button.
If the builder has never changed a file, the panel reads: "No file changes recorded yet. Ask for a change and it shows up here."
What Restore actually does
This is the part worth reading carefully, because it is not what "restore" usually means in other tools.
Restore means roll the whole project back to how it was before that run. It is not "restore this one file" and it is not "restore this one version".
Concretely: every file change from that run and every run after it is undone. For each file, the earliest recorded "before" state wins — so a file changed in four consecutive runs goes back to what it was before the first of them.
The confirmation dialog says this plainly:
Restore to before this change? Every file change from this point forward is undone (N files in this step). The restore is recorded, so you can undo it too.
The restore is itself a version
When the restore finishes, Bookbag writes a new entry into the history:
- A new run appears, with the prompt
Restore to before run #<id>and statusdone. - One version row per restored file, so the restore's own "before" and "after" are recorded.
- A system message in the chat reading "Restored N files to their state before run #
<id>."
Which means an unwanted restore is undoable in exactly the same way: restore to before the restore.
No model is called and no credits are spent. A restore is a file operation, not a build.
What restore cannot undo
Only what the builder wrote through its file tools — write_file, edit_file and delete_file — is recorded.
Two things are therefore not covered:
- Anything a shell command did. If the builder ran
npm install some-package, the change topackage.jsonandpackage-lock.jsonhas no version row and will not be rolled back. The same goes for any file a command created or removed. - Publishing. Publishing temporarily rewrites
next.config.mjsand puts it back afterwards, outside the version system.
In practice this means a restore reliably returns your app code to a previous state, and may leave an extra dependency installed. That is harmless.
When restore is refused
| Message | Meaning |
|---|---|
| A build is running — wait for it to finish first. | You cannot restore under a live run. Wait for it, or stop it. |
| Nothing to restore from that point. | No file changes were recorded at or after that run. |
| A valid runId is required. | An internal error; reload the page. |
| You can view this project but not change it. | You are a viewer. Viewers can read version history but not restore from it. |
On success you get a toast reading Restored N files, the panel reloads, and the preview and Code tab refresh.
How long history is kept
Forever, until the project is deleted. There is no cap on the number of versions, no age limit and no pruning job. Deleting a project removes its history along with everything else.