Wiki · Features in depth
Running commands and approvals
How to keep the agent from nagging during ordinary work while it still cannot wipe the server. Including what happens with unattended jobs.
When it asks and when it does not
| Mode | What it does | Who it is for |
|---|---|---|
| smart (default) | An auxiliary model assesses the risk: a clearly safe command is approved for that one case, a genuinely dangerous one is auto-denied and uncertain ones escalate to you | Everyday work — the best compromise |
| manual | Always asks when a dangerous command comes up | When you want to see every risky step |
| off | Disables all checks (the same as --yolo) | Only in an isolated environment where nothing can escape |
When nobody is around to click "approve"
A nightly job or a webhook has nobody to answer the prompt. Those situations therefore have their
own setting: deny (the default) blocks the command and the agent must
find another path; approve approves everything up front.
| Situation | Setting | Default |
|---|---|---|
| Scheduled job (cron) | cron_mode | block |
One-shot command hermes chat -q | single_query_mode | block |
| Webhook, unattended API | unattended_mode | block |
This matters for silent problems: when a nightly job hits a dangerous command and nobody clicks, the job simply does not finish and the refusal stays in the log. If you want such a job, design it to cope with being blocked.
YOLO mode (everything without asking)
| How | Scope |
|---|---|
hermes --yolo or hermes chat --yolo | The whole run |
/yolo in a conversation | From that moment until the session ends |
Never enable it where the agent works on a live site or where your keys and credentials live. In an isolated container or a scratch project it is a sensible choice.
Writing files: no prompt here, it is blocked outright
For file writes there is no "allow" dialog. Hermes checks the path against a list of protected places and refuses the write — with no way to override it from the chat:
| Always protected | Examples |
|---|---|
| Access to the system and the cloud | SSH keys, authorized_keys, AWS and Kubernetes credentials, sudoers |
| Hermes' own secrets | .env, sign-in files, the vault, the browser profile, tool tokens, pairing files |
| Credential files inside a project | .env.local, .env.production, .envrc — the agent must not read them, but it can write them for you |
You can also narrow the write boundary to a single folder — then the agent may not write outside
it (HERMES_WRITE_SAFE_ROOT). The protected places above stay blocked even if they sit
inside that folder.
Where the agent runs, and what that means for checks
| Where the terminal runs | Dangerous command check | What it suits |
|---|---|---|
| On your computer | yes | Development and everyday work |
| On a remote server over SSH | yes | Working on a server |
| In a container (Docker and similar) | skipped — the container is the boundary | Always-on operation once everything is isolated |
| In a cloud sandbox (Modal, Daytona, Vercel) | skipped | Work that should vanish with the machine |
A skipped check is not a bug — it just means isolation, not prompts, is the protection. Check what is mounted into the container (folders, keys, network).
Pitfalls from our systems
| What happened | What to do |
|---|---|
| A nightly job quietly did not finish | It hit a dangerous command with nobody to approve → the default is to block. Design the job to have another path, or grant it permission deliberately |
| The agent claimed it saved a file but did not | The write was blocked (protected path or outside the safe root). Check the write-verification footer, not the summary |
The agent could not read .env | That is correct — credential files are not readable. When a value is needed, supply it as configuration rather than as file contents |
| Someone enabled "allow everything" on a production server | Do not. If you must, only for a limited time and knowing the agent can touch anything |
| An approval expired because we were away | The default wait is 5 minutes. Either come back to decide or pick a mode that does not ask (and own its risk) |
| Moving into a container killed checkpoints too | Inside a container paths belong to the container, so snapshots do not work. In container mode rely on git and backups |
Our tips
| Tip | Why |
|---|---|
Keep smart until you have a reason to change it | It approves most routine work and stops on truly risky things |
| Point the write boundary at your project folder | The agent then cannot write outside it, even by mistake |
| Assume scheduled jobs can be blocked | A job must cope without approval, or it will fail silently |
| Never switch checks off "just to try" on a live system | The risk shows up once and irreversibly |