Hermes Agent on Omarchy: Arch, Python 3.14, and uv

Where this guide starts

Omarchy is David Heinemeier Hansson's opinionated Arch and Hyprland desktop, installed from its own ISO and encrypted by default. The general shape of the distro — how it installs, what it ships, what its encryption means for a service — is covered in Running OpenClaw on Omarchy and is not repeated here.

What differs for Hermes is that it is a Python application on a rolling-release distro that tracks new Python versions quickly. That drives the install, and only the install — once it is running, Hermes on Arch behaves like Hermes anywhere else.

Arch is past Hermes's Python ceiling

Hermes declares its supported range in pyproject.toml:

requires-python = ">=3.11,<3.14"

Arch's core repository ships Python 3.14 — 3.14.7 at the time of writing. Because Arch rolls, check your own machine rather than trusting a version number in any guide, including this one:

python --version

If that reports 3.14 or newer, the system interpreter is outside the range Hermes supports. uv resolves a project's Python from requires-python, so it will decline to build against that interpreter rather than half-working. The upper bound is deliberate on upstream's part and is intended to move as the ecosystem catches up, so expect this ceiling to change.

The practical consequence is narrow and worth stating plainly: do not install Hermes against Arch's system Python. Not as a style preference — the version is simply out of range.

Use the official installer, because it was written for this

The documented one-liner is the correct path here:

curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

Two things it does specifically matter on Arch:

• It pins the virtualenv to Python 3.11 rather than letting uv pick the newest interpreter it can find, so Arch shipping 3.14 does not decide the outcome.
• It neutralises an inherited UV_PYTHON. uv honours that variable over an existing venv, so a stray UV_PYTHON=3.14 in a shell profile would otherwise point uv at an interpreter outside the supported range instead of the environment it just built. The script's own comments name that exact scenario as what they are guarding against.

In other words, the interpreter hazard on Arch is real but already handled — provided you use the installer. The installation guide covers the general flow.

Where it can still bite you

The protection lives in the install script, not in the laws of physics. If you go around it — hand-rolling a venv, running uv sync yourself, or installing into the system interpreter — then a UV_PYTHON pointing at 3.14 is back in play and nothing is defending you. On Arch that is the most likely reason a manual install fails while the one-liner works for everyone else, so check it first:

echo "$UV_PYTHON"

If you would rather not think about the host interpreter at all — a reasonable position on a rolling release — run the gateway in a container and make the Python question independent of whatever pacman -Syu does next week. The Docker guide covers that.

The installer gives you systemd, so use it

Worth knowing before you reach for a terminal multiplexer: when systemctl is present — and on Omarchy it is — the installer offers to set up a systemd service for the gateway, only falling back to a plain background process where systemd is unavailable.

That matters because the Hermes gateway is built to be supervised. It runs an on-by-default liveness watchdog that hard-exits when its event loop wedges, precisely so something restarts it; the reasoning is in Hermes Agent in tmux. Accept the systemd service and that design works as intended. Decline it and run the gateway in a terminal, and you have opted out of the recovery mechanism for no benefit.

What a service still cannot do

A supervised gateway on your laptop is a real improvement, and it still is not an always-on deployment. Two Omarchy defaults remain in the way, and neither is a flaw:

• Encryption. The disk is encrypted by default, so an unattended reboot stops at a passphrase prompt before any unit starts. systemd cannot restart what has not been unlocked, and rolling updates make reboots routine rather than rare.
• Suspend. A closed laptop is offline regardless of what its service manager intends.

So the honest split is not "supervised versus unsupervised" — the installer already solved that. It is whether the machine is awake and unlocked at the hours you expect the agent to answer.

What to run where

• On Omarchy: development, experimenting with skills and config, interactive hermes chat sessions, and anything operating on files already on that machine.
• Somewhere awake and unlocked: scheduled work, anything other people message, anything that should answer while you sleep or travel — a VPS or managed hosting.

That split keeps your Omarchy install what it is meant to be: a very good desktop, rather than a server pretending to be one.

Hermes Agent on Omarchy FAQ

Related Hermes guides

• Install Hermes Agent
• Hermes Agent in tmux
• Hermes Agent with Docker
• Running OpenClaw on Omarchy