v0.40.0

Undo what an agent did, and restores that keep your decisions

v0.40.0 makes mistakes easier to take back. An AI agent's changes can be found in the audit log and undone record by record, including deletes. New collections keep record history by default, so there is something to go back to. A backup restore no longer undoes what you decided since the backup: removed users stay removed, work already done isn't run again, and maintenance mode stays on. Several changes are visible after upgrading, so read the upgrade notes first.

Added

• Undo a delete. A record deleted from a collection with history comes back from its history with the same id, values and creation time. Use Undo delete in the record's history, or POST /api/v1/<collection>/<id>/restore. Base collections only; records a cascade deleted with it stay deleted.
• Find an agent's calls in the audit log. MCP calls record the API token they were made with. The audit log filters by token, shows the tool each call ran, and opens the history of the record an entry names, deleted or not. From there one click restores the version before the agent's change.
• Restore an exact version with restore?entry=<history id>. ?at= still works.
• Restores are in the audit log (record.restore), with the version restored.
• Bring back users deleted since the backup, chosen per restore: a toggle on the backups page, or ?bring_back_deleted_users=1. They come back signed out of every session.
• The backups page shows what a restore did after the page reloads: the accounts it kept, the users it left deleted or brought back, and the work it didn't run again.

Changed

• New collections keep record history unless you turn it off (history_enabled: false), through the API, MCP and the admin. Views don't keep history, and existing collections don't change. History stores a copy of the record on every write, so turn it off for collections that change constantly.

Fixed

• A restore no longer brings back access removed since the backup. A user deleted after the backup came back with the restore, and their old sessions worked again until they expired. Such users now stay deleted, along with their provider links and recovery codes, as deleted admins already did.
• A restore no longer runs background work twice. Jobs and webhook deliveries that were waiting when the backup was taken came back and ran again, even if they had run since. Work that ran, or was removed, since the backup is now marked dead, so you can retry it if it should run. Work still waiting keeps its place.
• A restore no longer turns maintenance mode off. You can turn it on, restore, check the result and reopen. The docs now have a checklist for this.

SDKs

No SDK release is needed. JS SDK 0.10.0, and Dart vaultbase 0.6.0 with vaultbase_flutter 0.1.5, work with this release.

See the changelog for the full list.

Upgrade notes

• New collections keep record history by default. To create one without it, pass history_enabled: false. Existing collections don't change.
• A restore leaves users deleted since the backup deleted. To bring them back, use the toggle or ?bring_back_deleted_users=1.
• A restore marks dead the jobs and webhook deliveries that ran since the backup, instead of running them again.
• A restore leaves maintenance mode as it was, instead of taking the backup's setting.
• Restoring a deleted record now brings it back (200) where it used to answer 409.
• MCP audit entries name the collection in their target (collection=posts id=…), and creates name the record they made.
• If you are coming from before v0.39.0, its upgrade notes apply too.

Full Changelog: v0.39.1...v0.40.0