If hermes setup created a user service for the gateway, enable and
start it as the hermes user. Linger is pre-enabled so the service
survives without an interactive session.
- Add /usr/bin/hermes-setup that runs hermes setup as root, allowing
optional components (TTS engines, browsers, etc.) to be installed,
then restores ownership and permissions on /home/hermes
- Update login hint to reference hermes-setup
- Update completion message to guide users to hermes-setup and note
that the gateway service should be installed as a user service
- Update JSON note to reflect new setup flow
hermes-agent v2026.5.7 (PR #21193, merged 2026-05-07) flipped
HERMES_REDACT_SECRETS and DEFAULT_CONFIG security.redact_secrets to
true by default. The explicit HERMES_REDACT_SECRETS=true in .env and
the config.yaml creation block added in commit 1420682e are now
redundant — Hermes writes the same values itself on a fresh install.
Verified on CT 900 (v2026.5.7): _REDACT_ENABLED=True with no env
override; Hermes self-writes redact_secrets: true to config.yaml.
Ref: NousResearch/hermes-agent#17691
Adds third-party script warning with user confirmation before running
the upstream installer (install) and updater (update), matching the
kasm/pihole pattern. Removes redundant binary existence check per
reviewer feedback. Adds corresponding JSON warning note.
Trims the verbose 12-line CT footer to the standard pattern plus
essential first-run setup steps. API server, API key, and dashboard
SSH tunnel details are now displayed on every SSH login via
/etc/profile.d/hermes-hint.sh instead.
Addresses PR feedback from CrazyWolf13.
The previous approach used a /usr/bin/hermes shim to proxy commands from root
to the hermes user, and a hand-crafted system-level systemd unit for the
gateway. This worked for the default profile but broke down for named profiles:
- hermes profile create <name> generates an alias script in
~/.local/bin/<name> that calls hermes with -p <name>. These aliases live
in the hermes user's PATH, not root's, so root could not invoke them.
- Maintaining parity would require per-profile shims, a watcher daemon to
create/remove them, and system-unit mirrors for each profile gateway — all
of which would need to stay in sync with hermes internals across updates.
New approach — work with hermes, not around it:
- loginctl enable-linger hermes: ensures the hermes user's systemd session
starts at boot and persists without login. All user-unit gateways (default
and per-profile) now survive reboots automatically.
- Gateway service management delegated entirely to hermes: 'hermes gateway
install' / 'hermes setup' create and enable the user unit natively.
The install script no longer pre-installs the gateway; hermes prompts the
user to do so at the end of 'hermes setup'.
- hermes-dashboard.service remains a system unit (no native install command
exists for it). Its After= no longer references hermes-gateway.service
since there is no system-unit gateway to depend on.
- /usr/bin/hermes shim removed. Root is guided to 'su - hermes' via a two-
line /etc/profile.d/hermes-hint.sh message on login, with a one-liner to
make the switch automatic. Once logged in as hermes, all hermes commands,
profile aliases, and gateway management work natively.
- update_script simplified: only hermes-dashboard (our unit) is stopped and
restarted. hermes update --yes handles gateway service lifecycle itself.
