Arch Linux User Repository

This package installs Hermes Agent to /opt/hermes-agent using a uv-based relocatable virtual environment.

All Node.js modules are pre-bundled; lazy installs are disabled in the root-owned/opt directory to avoid permission issues. Instead, lazy installs are directed to $XDG_DATA_HOME/hermes-agent/python (user-writable, e.g., ~/.local/share/hermes-agent/python).

Post-install:

• Add your API keys to ~/.hermes/.env.
• Run hermes doctor to verify your setup.

For the desktop app, see the hermes-agent-desktop package.

@enihcam @y0uCeF The stamp clears "unknown-managed", and removing facts.json silences the warning, but that's not the whole story:

• pm never counts a PATH copy. With lazy installs off and no node in its store, hermes --tui then dies with node: not installed and lazy installs are disabled, also on a fresh account. npx/uvx MCP servers fail the same way.
• The gateway's systemd unit runs the venv python directly, so the launcher's HERMES_DISABLE_LAZY_INSTALLS doesn't apply there. Its first lazy install refills ~/.hermes/tools with python + uv: the warning comes back, and hermes then runs its children and new service units on that bare python without the venv.

Quick relief: export HERMES_NODE=/usr/bin/node in the launcher (the TUI takes it first).

hermes-agent-bin 0.21.7-3 (https://github.com/jabla/hermes-agent-bin/pull/20) covers all of it: a read-only pm store of /usr/bin symlinks under /opt (stamp runtimeDir) plus a 7-line patch. Feel free to reuse system-tools.py and keep-venv-interpreter.patch. I'll take the root causes upstream too.

@y0uCeF Thanks for checking --tui.

0.21.7-2 ships an install-stamp.json so the /opt tree is marked as package-manager owned (external). That should clear the unknown-managed part.

If you still see ffmpeg/node/npm/ripgrep "not installed or outdated", that usually means an old PM facts file from a previous source install. Remove it and try again:

rm -f ~/.hermes/tools/facts.json

The AUR package uses the system packages for those tools and does not keep them in the Hermes PM store.

It seems I was not using tui in my configs. I tested running with --tui and it seems to not find some dependencies, probably related to package manager:

$ hermes --tui
⚠ install out of sync (ffmpeg: not installed or outdated; node: not installed or outdated; npm: not installed or outdated; ripgrep: not installed or outdated) — this unknown-managed install must rebuild the artifact to fix

@enihcam I already started meddling with the new pm and the _find_bundled_tui() on day one. Glad you had that solved. I have not looked into the agent-browser yet. Also appreciate the rsync dependency drop. I tested both upstream hermes-agent with hermes-agent-desktop as well as in TUI and things seem stable so far. Especially, it's not trying to lazy-install anything into /opt.

I agree with the python-hermes-agent dependency, as long as the dependency chain holds.

@y0uCeF Just a note: hermes-agent-desktop now depends on hermes-agent. It uses the system /usr/bin/hermes and no longer installs its own agent tree.

@y0uCeF However, If hermes-agent depends on system Python (3.14), it will be better to depend on python-hermes-agent too, for the Hermes Python package leveraging the system Python libraries.

The whole chain would be hermes-agent-desktop -> hermes-agent -> python-hermes-agent, and their versions have to sync together.

@y0uCeF Done, please review.

Python 3.14 is up in version 0.21.6 today, working on the PKGBUILD to remove python311 dependency.

https://github.com/NousResearch/hermes-agent/commit/7f1ddc70ce89bb30eccc87e60d4d5338d78fefc8 Python 3.14 landed.

@enihcam

I believe hermes agent supports Python versions up to 3.13 even though they pin 3.11. There are attempts to support 3.14, although they may end up limited to Termux deployments. python311 takes a long time and consumes lots of resources to compile. I wish we could use the main python package.