Blocking of Irreversible Commands

6.6. Blocking of Irreversible Commands — The Line That Cannot Be Crossed

Hardline blocklist — the lowest layer, no override flag

This is the final defensive layer, standing below even --yolo: a set of catastrophic commands — wiping the entire filesystem, fork bombs, writing directly to block devices — are refused unconditionally by Hermes, regardless of --yolo, approvals.mode: off, or any other approval configuration. There is no override flag for this layer.

rm -rf / and its obvious variants (including --no-preserve-root /)
Fork bomb: :(){ :|:& };:
Direct writes to block devices (raw disk writes)

The blocklist trips before the regular command-approval layer (6.3) ever sees the command — if the blocklist is hit, the tool call immediately returns an explanatory error to the agent, and nothing is executed.

Why it is designed with “no override flag”

This is a deliberate difference from regular approval modes: approval modes can be turned off (YOLO), but the hardline blocklist is a hard boundary — if a legitimate workflow truly needs to run one of these commands (for example, you are operating a wipe-and-reinstall pipeline), the solution is to run it outside the agent, not to find a way to switch it back on through Hermes.

A point to note: the blocklist is deliberately narrow

Worth stating plainly here: the blocklist only blocks the most obvious catastrophes (fork bombs, rm -rf /) — it cannot catch deliberate credential theft, sophisticated staged exfiltration, or lateral-movement commands that look like normal development work. This is why the layers 6.1–6.5 need to stand together, and you cannot rely on this blocklist alone.

Notes

• Do not mistake “having a hardline blocklist” for “being absolutely safe” — this is the last safety net for obvious catastrophes, not a solution for the whole risk surface (especially for sensitive tasks such as crypto wallet operations or financial transactions — where Hermes currently has no dedicated limiting mechanism).
• For slash commands that destroy session state (/clear, /reset, /quit --delete), the CLI has its own confirmation prompt — this is a different mechanism, not part of the hardline blocklist, and can be turned off via configuration if desired.
• If you ever hit the blocklist stopping an operation you believe is legitimate, do not try to “bypass” it — that is a signal to pull that operation out of the agent loop and run it manually yourself.