Rewind
Undo every write since a point in time, for a branch, a table or one row, and undo a migration.
Mantis records every write to every branch. A rewind uses that record to put things back the way they were at a time you name: rows inserted since then are removed, deleted rows are restored and changed rows get their old values back.
Preview first
npx shipmantis rewind --to 30mRewinding the branch to 2026-10-15T09:00:00.000Z undoes 42 changes:
todos 3 removed, 12 restored, 27 reverted
Nothing was changed. Run again with --apply to rewind.Without --apply nothing changes. Read the preview, then run the same command with --apply.
| Flag | What it does |
|---|---|
--to | A time with an offset, like 2026-10-14T09:30:00Z, or 30m, 2h, 1d ago. |
--table <name> | Rewind only this table. |
--table <name> --id <uuid> | Rewind only this row. |
--branch <name> | Rewind another branch. Default: MANTIS_BRANCH, else main. |
--apply | Rewind after the preview. |
Your agent does the same with the preview_rewind and rewind tools.
Rewinding main
A rewind of main from the CLI or the agent is held for a person's approval, and the command
exits with code 2. When it is approved it rewinds to the time that was asked for, so writes made
while it waited are undone too. The dashboard shows the preview again before you approve.
A held rewind goes stale, and can't be approved, if the history it needs has aged out or the schema has changed since. A rewind started from the dashboard applies at once, since a person started it.
How far back
| Plan | History kept |
|---|---|
| Free | 7 days |
| Pro | 30 days |
A rewind can't reach past a schema change either: undo the migration first, or rewind to a time after it.
Undo a migration
npx shipmantis undoundo reverses the latest migration on the branch. A table or column it dropped comes back with
its data, for as long as the plan keeps history. Run it again to undo the one before. An undo is
never undone itself; to go forward again, push the schema.
On main, an undo that can lose data, such as dropping a table the migration created, is held for
approval like a push.
Held changes
Every held change has a status. Your agent reads it with the check_change tool.
| Status | Means |
|---|---|
pending | Waiting for a person in the dashboard. |
approved | Approved and applied. |
rejected | Turned down; nothing was changed. |
stale | Can no longer apply as asked, because the schema or the history moved on. Make the change again. |