There is a saying in the Hermes community: more than half of all users have flipped YOLO at least once. But YOLO is not the whole story — it is just one extreme point on Hermes’s safety spectrum. The people who really get the most out of Hermes switch between seven common modes, instead of defaulting to /yolo whenever things get slow.

Hermes Agent is built on a strong default assumption: if you let it run a command, it should be responsible for the consequences. So before it executes anything that could damage your system, it stops and asks. This is called Dangerous Command Approval, and YOLO is only one way to bypass it.

This post covers the seven safety and autonomy modes in Hermes. After reading, you will be able to tell your agent:

• “Smart mode is enough for normal development.”
• “I run this script often, approve it for the session.”
• “I am doing a bulk refactor, turn on YOLO, but never allow git push --force.”
• “Run this in Docker, so approvals are unnecessary and the host stays safe.”

---

1. Smart Mode: Let the AI Judge Risk (Recommended Default)

approvals:
  mode: smart

smart is the Hermes default. When a command matches a dangerous pattern, Hermes asks an auxiliary LLM to assess the actual risk.

• Obviously safe commands (e.g., python -c "print('hello')") are auto-approved.
• Obviously dangerous commands (e.g., rm -rf /) are auto-denied.
• Uncertain cases are escalated to you.

This cuts down “approval fatigue” dramatically. You do not have to confirm every bash -c, while genuinely destructive actions still get caught.

Best for: Daily development, exploratory tasks, environments where you already trust the agent.

---

2. Manual Mode: Every Dangerous Command Goes Through You

approvals:
  mode: manual

If you prefer not to delegate risk assessment to an auxiliary model, use manual mode. Every command that matches a dangerous pattern pauses and waits for your approval.

In the CLI, the prompt looks like this:

⚠️  DANGEROUS COMMAND: recursive delete
    rm -rf /tmp/old-project

    [o]nce  |  [s]ession  |  [a]lways  |  [d]eny

    Choice [o/s/a/D]:

The four choices:

• once: allow this single execution only.
• session: allow this pattern for the rest of the session.
• always: add the pattern to your permanent allowlist in ~/.hermes/config.yaml.
• deny (default): block the command.

Best for: High-security work, beginners, or when running unfamiliar commands.

---

3. YOLO Mode: Skip All Approval Prompts

YOLO mode bypasses all dangerous-command approvals. You can turn it on in three ways:

# At startup
hermes --yolo
hermes chat --yolo

# During a session
/yolo

# Environment variable
HERMES_YOLO_MODE=1

Once active, Hermes shows a red banner and a status-bar indicator so you do not forget that the safety net is gone.

> /yolo
  ⚡ YOLO mode ON — all commands auto-approved. Use with caution.

YOLO fits scenes where you are confident the commands are safe, such as:

• Repeated automation scripts;
• Work inside containers or throwaway environments;
• Tasks where you are watching closely and can Ctrl+C at any moment.

But remember: YOLO is not 100% unrestricted — the hardline blocklist below still applies.

---

4. Hardline Blocklist: The Floor Even YOLO Cannot Cross

Even with approvals.mode: off or /yolo enabled, Hermes still refuses certain irreversible, catastrophic commands. This is the hardline blocklist.

Examples include:

Command	Why it is blocked
rm -rf /	Wipes the root filesystem
:(){ :|:& };:	Bash fork bomb
mkfs.* against a mounted root device	Formats the live system
dd if=/dev/zero of=/dev/sd*	Zeros a physical disk
Piping untrusted URLs into sh	Remote-code-execution attack surface too large

These patterns live in tools/approval.py::UNRECOVERABLE_BLOCKLIST and cannot be overridden by any flag.

The design philosophy: YOLO means “I trust the AI not to make a mistake,” while the hardline list means “Even if the AI — or the user — goes wrong, the machine cannot be destroyed.”

---

5. Custom Deny Rules: YOLO With Exceptions

If YOLO feels too permissive but manual is too noisy, use approvals.deny to draw your own red lines:

approvals:
  mode: off           # effectively YOLO
  deny:
    - "git push --force*"
    - "*curl*|*sh*"
    - "dd if=* of=/dev/*"

Rules are case-insensitive fnmatch globs, matched against the full normalized command text. Even under YOLO, a matching command is hard-blocked.

This is perfect for “I trust most operations, but a few actions are never allowed” scenarios, such as:

• Let the agent edit code and run tests freely, but forbid git push --force;
• Let it fetch dependencies, but block curl ... | sh;
• Let it operate Docker, but never write directly to block devices.

---

6. Write Approval Mode: Gate Memory and Skill Writes

Beyond terminal commands, Hermes writes things on its own: it saves important facts to memory and learned workflows as skills. If you worry about it “learning the wrong things,” turn on write approval.

memory:
  write_approval: true

skills:
  write_approval: true

When enabled, every memory or skill write is staged under ~/.hermes/pending/ until you review and approve it:

# Review pending skill writes
/skills pending
/skills diff <id>
/skills approve <id>
/skills reject <id>

# Same for memory
/memory pending
/memory approve <id>
/memory reject <id>

Best for:

• Preventing the agent from auto-remembering sensitive or incorrect facts;
• Team-shared Hermes instances where learned skills need human review;
• Debugging the learning loop before allowing it to persist anything.

---

7. Container Isolation Mode: Replace Approvals with Boundaries

The last mode is not about how to approve, but about making approvals unnecessary. Hermes supports multiple terminal backends:

Backend	Isolation	Dangerous-command check
local	None — runs on the host	✅ Yes
ssh	Remote machine	✅ Yes
docker	Container	❌ Skipped (container is the boundary)
singularity	Container	❌ Skipped
modal	Cloud sandbox	❌ Skipped
daytona	Cloud sandbox	❌ Skipped

When running on Docker, Modal, or Daytona, dangerous-command checks are skipped because even if the container is destroyed, the host stays untouched. Production Hermes gateways are usually configured this way.

Docker containers also run with a hardened set of security flags by default:

_BASE_SECURITY_ARGS = [
    "--cap-drop", "ALL",
    "--security-opt", "no-new-privileges",
    "--pids-limit", "256",
    "--tmpfs", "/tmp:rw,nosuid,size=512m",
]

Best for: Production deployments, CI/CD, multi-tenant environments, and any sandbox where destruction is acceptable.

---

Pick the Right Mode: A Quick Reference

Mode	Command approval	Write approval	When to use it
smart	AI pre-review + human review for edge cases	Optional	Default for daily development
manual	All dangerous commands require human approval	Optional	High-risk tasks or beginners
YOLO	All dangerous commands bypassed	Optional	Temporary automation, trusted scripts
hardline	Catastrophic commands permanently blocked	Not applicable	Always-on safety floor
deny rules	Custom blocking patterns	Not applicable	YOLO with exceptions
write approval	Optional	Required for memory/skill writes	Prevent the agent from learning bad things
container isolation	Checks skipped	Bounded by container	Production or sandbox use

---

Practical Recommendations

1. Stick with the default: smart mode handles most daily work without constant interruptions.
2. Use session approval for batches: Safer than YOLO, but avoids per-command prompts.
3. Pair YOLO with deny rules: If you do go full YOLO, keep at least a few custom red lines.
4. Run production in Docker: Isolation is more reliable than approvals and removes approval fatigue entirely.
5. Audit your allowlist: command_allowlist grows over time. Clean it periodically with hermes config edit.
6. Enable write approval for shared Hermes: Especially important when running a long-lived gateway in a team.

---

Conclusion

Hermes’s approval system is not there to slow you down. It is there to let you balance confident delegation with timely braking. YOLO is fun, but it is only one of seven modes. The real power users know when to stay in smart, when to switch to manual, when to turn YOLO back off, and when to let Docker do the safety work for them.

Next time you reach for /yolo, ask yourself: Do I really need to bypass every approval, or would session approval plus a single deny rule be enough?