Hermes Agent vs NanoClaw

Hermes Agent

Card payments always ask first and are refused in unattended sessions, and the messaging gateway denies every sender until an allowlist is set. Shell commands run on the host by default with a model judging risk, and sending mail through the Google Workspace skill is held back only by an instruction to the model.

NanoClaw

Each session runs in an unprivileged Docker container and API keys stay in a credential gateway on the host, so a manipulated agent cannot read them. Inside the container the agent runs with permission prompts off, network egress is open by default, and it can message any chat it is wired to without approval.

Hermes Agent

1. Set approvals.mode: manual before giving it real accounts. The default smart lets an auxiliary model approve commands
2. Run the gateway with terminal.backend: docker or the project's Docker image when it reads mail, web pages or group chats
3. Set memory.write_approval: true and skills.write_approval: true to review what it saves about the owner
4. Leave approvals.cron_mode and approvals.unattended_mode at deny for scheduled and webhook runs
5. Set TELEGRAM_ALLOWED_USERS or the matching allowlist per channel. Never set GATEWAY_ALLOW_ALL_USERS=true

NanoClaw

1. Install with git clone and bash nanoclaw.sh. There is no registry package, and setup needs Docker, Node 22 or later and a Claude or Codex credential
2. Set NANOCLAW_EGRESS_LOCKDOWN=true before giving an agent credentials or an audience of strangers. The default leaves egress open
3. Put chats with different audiences in separate agent groups. Every session of a group shares one read-write workspace and memory tree
4. Turn on per-request approval for a secret in the gateway when its use should wait for a person. It is off unless configured
5. On OneCLI installs, move the gateway to 1.42.0 by the upgrade guide before updating to 2026.10.0. The updater stops until that is done