Validation of Dangerous Commands

6.3. Validation of Dangerous Commands — The Blocking Layer Before a Command Runs

Three approval modes

hermes config set approvals.mode manual   # Default: always ask before dangerous commands
hermes config set approvals.mode smart    # Recommended: a secondary LLM assesses risk, auto-approves low-risk commands
hermes config set approvals.mode off      # Fully off (equivalent to --yolo)

Hermes maintains a curated set of regex patterns for high-risk commands — recursive deletes, DROP TABLE, fork bombs, piping curl into bash, killing the gateway process — any pattern match requires user approval before the command runs.

YOLO mode — use it consciously

hermes --yolo          # enable at session start
/yolo                  # toggle mid-session

YOLO disables all dangerous-command safety checks for that session — two visual warning banners (a red line at session start, a warning fragment on the status bar) are always displayed when it is on, so no one forgets they are in this mode.

Input is normalized before matching

Before scanning patterns, Hermes normalizes the input — stripping ANSI escape codes, null bytes, normalizing Unicode to NFKC — to close the most obvious obfuscation paths (though in essence it is still pattern matching, not absolute semantic analysis).

Notes

• smart is a good balance for daily use: it auto-approves low-risk operations and stops to ask on high-risk ones — do not turn approvals off “for speed”, because the denylist exists precisely because users keep finding new ways to accidentally wipe their home directory.
• For slash commands that destroy session state (/clear, /new, /reset, /undo), the CLI also asks for its own confirmation before executing — a protection layer separate from shell command approval.
• Pattern-based detection can inherently be bypassed (obfuscation, splitting across multiple commands, writing to a file and then sourcing it) — treat this as the first defensive layer, not the last.