You’re about to add a cleanup command to a script the agent will run unattended, and there’s one question you can’t answer by looking at the code: will Hermes let this through? Guessing means either a mid-run approval prompt nobody is there to answer, or a command that quietly ran when you expected it to be blocked. v0.21.0 ships the obvious tool for this: hermes approvals test dry-runs any command against the real approval guards — the hardline blocklist, your approvals.deny rules, dangerous-pattern detection, the allowlist, even the yolo/off bypass — and prints the verdict without executing anything, prompting anyone, or persisting anything.

The verdict in three exit codes

hermes approvals test -- rm -rf /tmp/x

The -- matters: it stops flag parsing so the command’s own flags (like -rf) aren’t eaten by hermes approvals itself. The output tells you the verdict, which rule matched, and the normalized command trace — the same normalization the real gate applies. Scripts get the answer as an exit code:

• 0 — allow
• 2 — ask-approval (would prompt)
• 3 — deny (hardline blocklist or your own deny rule)

So you can wire it into a pre-flight check: a deploy script that refuses to continue if a step would be blocked, a cron job that fails loudly before running a command the gate would stop anyway, or an audit pass that greps your scripts for anything that would prompt in an unattended context.

What it actually evaluates

The dry run runs the same decision chain as a real command, including:

• the hardline blocklist (unconditionally denied commands),
• your approvals.deny fnmatch globs (see our smart approvals setup guide for the schema),
• dangerous-pattern detection (recursive deletes, sudo, disk writes, credential edits, …),
• the command allowlist (commands you’ve already blessed),
• and the yolo/off bypass if you run with those modes (yolo modes explained).

Two flags fine-tune the check: --env-type tells it which terminal backend to evaluate against (default local; isolated container backends like docker skip the guards, so a command that’s fine in a container may prompt locally — worth knowing before you write the script), and --json gives machine-readable output.

The bonus command: hermes approvals suggest

hermes approvals test answers “what would happen?”; its sibling hermes approvals suggest answers “what should I allow?” It mines your past approval decisions from the session database, ranks the recurring patterns, and proposes command_allowlist entries — nothing is written unless you apply them:

hermes approvals suggest                  # review the numbered proposals
hermes approvals suggest --apply 1,3,7    # merge the chosen ones into config.yaml

Options: --days (how far back to scan, default 90), --min-count (minimum approvals for a pattern, default 2), --limit, --db (alternate session database), --json. Destructive classes (recursive delete, sudo, disk writes, credential edits, …) are never proposed — the tool won’t suggest allowing what it exists to gate. This pairs neatly with unattended approvals for cron contexts.

When you’ll reach for this

Three moments stand out. Before writing automation: check each risky step once, and either bless it deliberately or handle the prompt path. Auditing: hermes approvals test -- <cmd> on a suspicious command tells you exactly which rule catches it — no trial runs. Learning the system: the normalized trace shows you how Hermes actually sees your command, which is the fastest way to understand why a shell one-liner you thought was innocent trips the gate. v0.21.0 also hardened the whole approval surface (Windows destructive commands now trip it, protected instruction files always require approval) — the release notes cover the full picture at /releases/v0-21-0/.