Three files spelled out the line that marks ~/.local/bin/hermes as Omarchy's:
the installer that writes it, Remove Preinstalls, and the migration. Two of
them were copies, and a change to what ownership means would have left them
matching a line nobody writes any more -- Remove Preinstalls quietly sweeping
nothing, the migration mistaking Omarchy's own wrapper for a stranger's.
omarchy-install-hermes-cli --owns answers it now, and the other two ask. The
installer's own metadata was also a flag behind: --check has been there since
this landed and was never listed.
A test pins the marker to one file, so a second copy fails rather than drifts.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
desktop_hermes_ready decided from a marker file and a text match, while a
hermes the user installed themselves had to answer --version before it counted.
The marker says the app's install once landed, not that it is still there, so a
runtime deleted afterwards left --check reporting success: the default agent
records Hermes, skips the install terminal, and the launch fails.
It now runs the command, on the same 15 second budget the app itself uses. The
path match is a plain string for the same reason it is in the remover -- the
dot in ~/.hermes would otherwise claim a wrapper pointing at ~/xhermes.
foreign_hermes_runs never tested foreignness, only that the command runs, so it
is hermes_runs now and both callers share it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-authored-by: Codex XHigh <noreply@openai.com>
The stub exports UV_PYTHON so mise builds Hermes against 3.13, which Hermes
requires and Arch's Python is past. Exported, it survived the exec into Hermes
itself and reached every command the agent shells out to. Hermes is a coding
agent that runs commands in the user's own repositories, so a `uv venv` or
`uv sync` there resolved 3.13 as well: on a project declaring
requires-python >=3.14, uv warns that the interpreter contradicts it and builds
the venv anyway.
Dropping it at the handover keeps the pin over the install, where it belongs.
mise x resolves the tool it already installed without it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-authored-by: Codex XHigh <noreply@openai.com>
install/user/mise.sh is sourced through run_logged under `bash -eE`, and its
status reaches omarchy-provision-user's `set -euo pipefail`. Every other line
in the file writes a mise stub and cannot fail; omarchy-install-hermes-cli can,
and does whenever hermes-desktop is installed but the app has not been launched
yet -- what a second user on a shared machine meets on their first login.
The rest of provisioning runs after that source: refreshing applications, the
default browser, the mailto handler, the first-install migration markers and
the finalize-user marker. Without the marker the whole step retries and fails
again at every login, and omarchy-provision-first-run calls it with `|| true`,
so nothing surfaces. omarchy-install-ai-hermes and the migration already guard
this call the same way.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Hermes joins Install > AI as a desktop app, sits beside it under Remove > AI,
and becomes a choice in the default-agent list. The CLI installs through
omarchy-install-hermes-cli rather than a bare `mise use`, so its interpreter
is pinned before mise builds it.
Rebased onto quattro. Ori claimed U+E909 in #7709 while this branch was open,
so the Hermes mark moves to U+E90A in the icon font, the menu entries, the
font README, and the charset the menu test pins. The glyph outline itself is
unchanged; it is spliced in beside Ori rather than over it.
Co-Authored-By: witcheer <witcheer.eth@gmail.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SySdB3RtCA8BNv6Am246BP
