Confirm Destructive Hermes Slash Commands Before State Loss
Some slash commands change or delete session state immediately. Hermes can place a confirmation step in front of /clear, /new or /reset, /undo, and /exit --delete or /quit --delete so a typo does not become silent data loss.
Understand the choices
The CLI confirmation offers Approve Once, Always Approve, and Cancel. Approve Once authorizes only the current action. Always Approve changes the persistent behavior and should be chosen only when the operator understands the broader effect. Cancel leaves the state unchanged.
For an intentional one-time bypass, the command can include now, --yes, or -y. Treat that as an explicit change-control signal, not a convenience default. Persistent behavior is governed by approvals.destructive_slash_confirm.
Safety checklist
- Save or export important session material before destructive changes.
- Read the full command, including
--delete, before approval. - Prefer Approve Once over a permanent bypass.
- Keep confirmation enabled on shared or production-facing profiles.
- Document unattended workflows that intentionally use
--yes. - Verify the expected session still exists afterward.
Common pitfalls
- Confusing tool approval with state-deletion confirmation. They protect different boundaries.
- Using Always Approve to remove friction. It weakens protection for every later command in that profile.
- Adding
-yto copied examples. Readers may execute a destructive action without seeing the safety prompt. - Assuming undo is harmless. It intentionally removes conversation state.
Verification
In a disposable test session, invoke one protected command without a bypass and confirm the modal appears. Cancel and verify state remains. Then test an approved action only after exporting anything needed. Read back the configuration so the persistent confirmation setting is known rather than assumed.
Official reference: Hermes slash commands.