raxit rollback

Every successful raxit apply snapshots the compiled policy — raxit rollback restores one of those snapshots, undoing an edit without hand-reverting the file.

Usage

List the available snapshots:

$ raxit rollback --list
N       TIME                       POLICY_VERSION
1       2026-07-11T22:10:03Z       e1096c1fd92d9c5f
2       2026-07-11T22:28:06Z       49e46c6a8600

Roll back to a specific version:

$ raxit rollback --to 1
rolled back to version 1 (policy hash: e1096c1fd92d9c5f)
restart the daemon to activate the restored policy

With no --to, rollback restores the previous version (the second-from-last snapshot) — useful as a quick undo right after a bad apply:

$ raxit rollback
rolled back to version 1 (policy hash: e1096c1fd92d9c5f)
restart the daemon to activate the restored policy

Flags

• --list — print available snapshots (N, time, policy version) and exit.
• --to <N> — restore snapshot N. Omit to restore the previous version.
• --config <file> — project config file (default .raxit/config.json).
• --versions-dir <dir> — snapshot directory (default .raxit/versions).
• --lock — unlock the config file before restoring and re-lock it after, if it was OS-locked.
• --sign-key <path> — Ed25519 key to sign the rollback's own audit record with (default: the key raxit keys init writes, if present).

Gotchas

• Snapshots are numbered, capped at 10, under .raxit/versions/<N>/ (security.yaml + config.json each) with an index at .raxit/versions/index.json. Once the cap is hit, the oldest snapshot is pruned on the next apply — rollback prints a note when this happens.
• rollback needs at least two snapshots to have a "previous version" to fall back to; with only one, pass --to 1 explicitly or it refuses: raxit rollback: only one version snapshot -- need at least two to roll back.
• rollback restores the file and appends a policy.rollback audit record (permit-effect, recording the from/to policy hash) — but it does not restart or reload a running daemon. Restart raxit serve/raxit dev (or run raxit apply again) to actually activate the restored policy; until then the daemon keeps enforcing whatever it already compiled.
• rollback trusts that a snapshotted security.yaml compiled cleanly the first time — it doesn't re-validate on restore. If the restored policy is actually broken, that surfaces the next time a daemon starts against it (fail-closed, per Fail-closed & degrade-closed), not at rollback time itself.