Checkpoints and /rollback
نقاط الحفظ والتراجع عن التغييرات
What this page is, and what it holds.
This page covers Checkpoints and /rollback. You will use hermes checkpoints prune and hermes checkpoints status here; about 8 minutes to read. Very long sessions lose their own beginning and cost more. Start a new one per task.
Filesystem safety nets for destructive operations using shadow git repos and automatic snapshots
Outcomes taken from this page, not a template.
- Understand what الجلسة is and when you need it.
- Run
hermes checkpoints pruneandhermes checkpoints statusand understand what happens next. - Read the table and take only the row that applies to you.
Exactly as they appear in Hermes.
hermes checkpoints prunehermes checkpoints statushermes checkpoints clear-legacyhermes chathermes checkpoints
Jump to the part you need.
- 01What Triggers a Checkpoint
- 02Quick Reference
- 03How Checkpoints Work
- 04Configuration
- 05Listing Checkpoints
- 06Inspecting the Store from the Shell
- 07Previewing Changes with `/rollback diff`
- 08Restoring with `/rollback`
- 09Single-File Restore
- 10Safety and Performance Guards
- 11Where Checkpoints Live
- 12Best Practices
Nothing summarised away.
The documentation body below is reproduced from the official source so commands and identifiers stay exact. Each section carries a short note describing what it contains.
Hermes Agent can automatically snapshot your project before destructive operations and restore it with a single command. Checkpoints are opt-in as of v2 — most users never use /rollback, and the shadow-store storage is non-trivial over time, so the default is off.
Enable checkpoints per-session with --checkpoints:
hermes chat --checkpointsOr enable globally in ~/.hermes/config.yaml:
checkpoints:
enabled: trueThis safety net is powered by an internal Checkpoint Manager that keeps a single shared shadow git repository under ~/.hermes/checkpoints/store/ — your real project .git is never touched. Every project the agent works in shares the same store, so git's content-addressable object DB deduplicates across projects and across turns.
What Triggers a Checkpoint
Explains the idea itself. Read it slowly; the later sections build on it.
Checkpoints are taken automatically before:
- File tools —
write_fileandpatch - Destructive terminal commands —
rm,rmdir,cp,install,mv,sed -i,truncate,dd,shred, output redirects (>), andgit reset/clean/checkout
The agent creates at most one checkpoint per directory per turn, so long-running sessions don't spam snapshots.
Quick Reference
A lookup table. Do not read it all; find the row that applies to you.
In-session slash commands:
| Command | Description |
|---|---|
/rollback | List all checkpoints with change stats |
/rollback <N> | Restore to checkpoint N, keeping your hand-edits (also undoes last chat turn) |
/rollback <N> --all | Full restore — overwrites your hand-edits too |
/rollback diff <N> | Preview diff between checkpoint N and current state |
/rollback <N> <file> | Restore a single file from checkpoint N |
CLI for inspecting and managing the store outside a session:
| Command | Description |
|---|---|
hermes checkpoints | Show total size, project count, per-project breakdown |
hermes checkpoints status | Same as bare checkpoints |
hermes checkpoints list | Alias for status |
hermes checkpoints prune | Force a sweep: delete orphans/stale, GC, enforce size cap |
hermes checkpoints clear | Nuke the entire checkpoint base (asks first) |
hermes checkpoints clear-legacy | Delete only the legacy-* archives from v1 migration |
How Checkpoints Work
Explains the idea itself. Read it slowly; the later sections build on it.
At a high level:
- Hermes detects when tools are about to modify files in your working tree.
- Once per conversation turn (per directory), it:
- Resolves a reasonable project root for the file.
- Initialises or reuses the single shared shadow store at
~/.hermes/checkpoints/store/. - Stages into a per-project index, builds a tree, and commits to a per-project ref (
refs/hermes/<project-hash>). - These per-project refs form a checkpoint history that you can inspect and restore via
/rollback.
flowchart LR
user["User command\n(hermes, gateway)"]
agent["AIAgent\n(run_agent.py)"]
tools["File & terminal tools"]
cpMgr["CheckpointManager"]
store["Shared shadow store\n~/.hermes/checkpoints/store/"]
user --> agent
agent -->|"tool call"| tools
tools -->|"before mutate\nensure_checkpoint()"| cpMgr
cpMgr -->|"git add/commit-tree/update-ref"| store
cpMgr -->|"OK / skipped"| tools
tools -->|"apply changes"| agentConfiguration
Settings you configure once. Change one at a time so you can see what each does. Commands here: hermes checkpoints prune.
Configure in ~/.hermes/config.yaml:
checkpoints:
enabled: false # master switch (default: false — opt-in)
max_snapshots: 20 # max checkpoints per project (enforced via ref rewrite + gc)
max_total_size_mb: 500 # hard cap on total store size; oldest commits dropped
max_file_size_mb: 10 # skip any single file larger than this
# Auto-maintenance (on by default): sweep ~/.hermes/checkpoints/ at startup
# and delete project entries whose last_touch is older than retention_days.
# Runs at most once per min_interval_hours, tracked via a .last_prune
# marker. This sweep never deletes "orphan" entries (working directory not
# found) — a missing workdir at startup is ambiguous (deleted project vs.
# an unmounted external volume / network share / VPN not yet up), so
# orphan cleanup is only ever done via the explicit
# `hermes checkpoints prune` command below, with a confirmation prompt.
auto_prune: true
retention_days: 7
min_interval_hours: 24To disable everything:
checkpoints:
enabled: false
auto_prune: falseWhen enabled: false, the Checkpoint Manager is a no-op and never attempts git operations. When auto_prune: false, the store grows until you run hermes checkpoints prune manually.
Listing Checkpoints
Explains the idea itself. Read it slowly; the later sections build on it.
From a CLI session:
/rollbackHermes responds with a formatted list showing change statistics:
📸 Checkpoints for /path/to/project:
1. 4270a8c 2026-03-16 04:36 before patch (1 file, +1/-0)
2. eaf4c1f 2026-03-16 04:35 before write_file
3. b3f9d2e 2026-03-16 04:34 before terminal: sed -i s/old/new/ config.py (1 file, +1/-1)
/rollback <N> restore to checkpoint N (keeps your hand-edits)
/rollback <N> --all full restore, overwriting your hand-edits too
/rollback diff <N> preview changes since checkpoint N
/rollback <N> <file> restore a single file from checkpoint NInspecting the Store from the Shell
Commands you type in a terminal. Understand what one does before copying it. Commands here: hermes checkpoints, hermes checkpoints prune.
hermes checkpointsSample output:
Checkpoint base: /home/you/.hermes/checkpoints
Total size: 142.3 MB
store/ 138.1 MB
legacy-* 4.2 MB
Projects: 12
WORKDIR COMMITS LAST TOUCH STATE
/home/you/code/hermes-agent 20 2h ago live
/home/you/code/experiments/rl-runner 8 1d ago live
/home/you/code/old-prototype 3 9d ago orphan
...
Legacy archives (1):
legacy-20260506-050616 4.2 MB
Clear with: hermes checkpoints clear-legacyForce a full sweep (ignores the 24h idempotency marker):
hermes checkpoints prune --retention-days 3 --max-size-mb 200Previewing Changes with `/rollback diff`
Explains the idea itself. Read it slowly; the later sections build on it.
Before committing to a restore, preview what has changed since a checkpoint:
/rollback diff 1This shows a git diff stat summary followed by the actual diff.
Restoring with `/rollback`
Explains the idea itself. Read it slowly; the later sections build on it.
/rollback 1Behind the scenes, Hermes:
- Verifies the target commit exists in the shadow store.
- Takes a pre-rollback snapshot of the current state so you can "undo the undo" later.
- Restores tracked files in your working directory — preserving your hand-edits (see below).
- Undoes the last conversation turn so the agent's context matches the restored filesystem state.
User hand-edits are preserved by default
/rollback <N> restores only the files Hermes itself changed. Every successful
write_file / patch records the file's content hash in an **agent-write
ledger**; at restore time, any file whose current contents no longer match what
Hermes last wrote (you edited it afterwards, or Hermes never touched it) is
skipped instead of overwritten, and listed in the output:
✅ Restored to checkpoint a1b2c3d4: before write_file
↷ Kept your hand-edits: src/config.py, notes.md
Use /rollback <N> --all to restore those too.To force the classic full restore that reverts everything — including your own
edits — add --all:
/rollback 1 --allIf the ledger is empty (a store created before this feature, or Hermes hasn't
written any files in the project yet), /rollback falls back to the full
restore automatically.
Single-File Restore
Explains the idea itself. Read it slowly; the later sections build on it.
Restore just one file from a checkpoint without affecting the rest of the directory:
/rollback 1 src/broken_file.pySafety and Performance Guards
Explains the idea itself. Read it slowly; the later sections build on it.
- Git availability — if
gitis not found onPATH, checkpoints are transparently disabled. - Directory scope — Hermes skips overly broad directories (root
/, home$HOME). - Repository size — directories with more than 50,000 files are skipped.
- Per-file size cap — files larger than
max_file_size_mb(default 10 MB) are excluded from the snapshot. Prevents accidentally swallowing datasets, model weights, or generated media. - Total store size cap — when the store exceeds
max_total_size_mb(default 500 MB), the oldest commit per project is dropped round-robin until under the cap. - Real pruning —
max_snapshotsis enforced by rewriting the per-project ref and runninggit gc --prune=nowafterwards, so loose objects don't accumulate. - No-change snapshots — if there are no changes since the last snapshot, the checkpoint is skipped.
- Non-fatal errors — all errors inside the Checkpoint Manager are logged at debug level; your tools continue to run.
Where Checkpoints Live
Commands you type in a terminal. Understand what one does before copying it. Commands here: hermes checkpoints status, hermes checkpoints clear-legacy.
~/.hermes/checkpoints/
├── store/ # single shared bare git repo
│ ├── HEAD, objects/ # git internals (shared across projects)
│ ├── refs/hermes/<hash> # per-project branch tip
│ ├── indexes/<hash> # per-project git index
│ ├── projects/<hash>.json # workdir + created_at + last_touch
│ └── info/exclude
├── .last_prune # auto-prune idempotency marker
└── legacy-<ts>/ # archived pre-v2 per-project shadow reposEach <hash> is derived from the absolute path of the working directory. You normally never need to touch these manually — use hermes checkpoints status / prune / clear instead.
Migration from v1
Before the v2 rewrite, each working directory got its own complete shadow git repo directly under ~/.hermes/checkpoints/<hash>/. That layout couldn't dedup objects across projects and had a documented no-op pruner — the store would grow without bound.
On first v2 run, any pre-v2 shadow repos are moved into ~/.hermes/checkpoints/legacy-<timestamp>/ so the new single-store layout starts clean. Old /rollback history is still reachable by manually inspecting the legacy archive with git; once you're confident you don't need it, run:
hermes checkpoints clear-legacyto reclaim the space. Legacy archives are also swept by auto_prune after retention_days.
Best Practices
Commands you type in a terminal. Understand what one does before copying it. Commands here: hermes checkpoints status.
- Enable checkpoints only when you need them —
hermes chat --checkpointsor per-profileenabled: true. - Use
/rollback diffbefore restoring — preview what will change to pick the right checkpoint. - Use
/rollbackinstead ofgit resetwhen you want to undo agent-driven changes only. - Check
hermes checkpoints statusoccasionally if you use checkpoints regularly — shows which projects are active and what the store costs you. - Combine with Git worktrees for maximum safety — keep each Hermes session in its own worktree/branch, with checkpoints as an extra layer.
For running multiple agents in parallel on the same repo, see the guide on Git worktrees.
3 questions answered by this page alone.
Every option is a real identifier from the Hermes documentation. The wrong ones are real too, just from other pages.