Checkpoints and rewind

Checkpoints are Axiomate's file snapshot system. Before the AI is about to modify files, Axiomate automatically records a snapshot of the workspace. If you need to roll files back later, use /rewind; if you need to inspect checkpoint storage, use /checkpoints.

The main value is automatic snapshots during multi-turn AI edits. In practice, the AI may read files, edit files, run tests, and continue editing across several turns. Users usually do not have a chance, and it is too frequent to manually commit or stash every intermediate state. Checkpoints automatically record these important file states, so you can return to a point where the AI had partially completed the work instead of choosing only between keeping all changes or discarding everything.

Where checkpoints are stored

Checkpoints are not written to your project git repository. Axiomate stores snapshots in an isolated checkpoint git store, usually at:

~/.axiomate/checkpoints/store

This is a shadow git maintained by Axiomate. Your project's .git, commit history, staging area, stash, and hooks are not modified by the checkpoint system.

If a snapshot is identical to the previous checkpoint, Axiomate does not write a new checkpoint. Only real file differences create new records.

Roll files back with /rewind

When you want to undo file changes made by Axiomate, open:

/rewind

In the File tab, choose the checkpoint you want to restore to. Each row represents a file state you can return to. After you select a row, the confirmation page recalculates the difference between the current disk and the target checkpoint before asking you to confirm.

Important distinction: /rewind is the file restoration entry point. /checkpoints is mainly for inspecting and maintaining the checkpoint store, not for selecting a restore target.

Common /checkpoints commands

Safety snapshots during rewind

When rewind runs, Axiomate first creates a safety snapshot before restoring the target file tree.

If restoration fails midway, the /rewind File tab usually shows a row like ↶ Before rewind. Select it to return to the state before the rewind.

Relationship with project git

The checkpoint system is isolated from project git:

• It does not commit to your project repository.
• It does not modify your staging area.
• It does not run project git hooks.
• It does not replace your own git commits, branches, or stash.

Think of it as Axiomate's local safety net. To formally save work, still use your project's normal git workflow.

Nested git repositories

Axiomate checkpoints treat the current workspace as a filesystem snapshot, so they can cover complex project layouts that contain nested .git boundaries. Common examples include sub-repositories in a monorepo, vendor directories, example projects, or test fixtures.

The behavior is:

• Ordinary files inside nested repositories can be included in checkpoint snapshots.
• The nested repository's own .git metadata is not saved as ordinary project content.
• The child repository's staged, dirty, or untracked state does not directly control the parent workspace checkpoint.
• Rewind focuses on file contents, not on operating the child repository's git history for you.

This gives Axiomate a stronger safety net in real engineering directories: even when a project contains multiple git boundaries, actual file changes can still be archived and restored.

Common notes

• Checkpoints are fail-open: if one snapshot fails, AI tool execution usually continues.
• Rewind is stricter: if there is no safety snapshot or the target checkpoint cannot be verified, Axiomate avoids restoring blindly.
• If the /rewind list looks stale, close and reopen /rewind to refresh it.
• If the checkpoint store is too large, run /checkpoints prune or adjust related settings.