NousResearch/hermes-agent · error · anyhow::Error

Could not find the hermes CLI under {}. Is Hermes installed?

Error message

Could not find the hermes CLI under {}. Is Hermes installed? Re-run the installer to repair the install.

What it means

Raised at the start of the update flow: the hermes CLI shim (venv hermes entry) was not found under the computed install root. The entire update — `hermes update` and the desktop rebuild — is driven through that CLI, so its absence means the install is broken or HERMES_HOME points somewhere else; the remedy is to re-run the installer to repair.

Source

Thrown at apps/bootstrap-installer/src-tauri/src/update.rs:320

        target_app_from_args(std::env::args().skip(1))
    } else {
        None
    };

    let hermes = resolve_hermes(&install_root).ok_or_else(|| {
        let msg = format!(
            "Could not find the hermes CLI under {}. Is Hermes installed? \
             Re-run the installer to repair the install.",
            install_root.display()
        );
        emit(
            &app,
            BootstrapEvent::Failed {
                stage: None,
                error: msg.clone(),
            },
        );
        anyhow!(msg)
    })?;

    // Synthetic manifest so the existing progress UI renders our stages.
    emit(
        &app,
        BootstrapEvent::Manifest {
            stages: update_stages(target_app.is_some()),
            protocol_version: None,
        },
    );

    // ---- stage 1: wait for the old desktop to die ------------------------
    // The desktop exec'd us then called app.exit(), but process teardown is
    // async on Windows. If it still holds the venv shim, `hermes update`
    // aborts with exit 2. If it still holds the packaged app.asar,
    // install.ps1's repair/re-clone path cannot move/remove the install tree.
    // Give both handles a bounded window to clear. Surfaced as its own stage
    // (rather than a silent pre-step) so a slow close / force-kill reads as

View on GitHub (pinned to c896c09c42)

Solutions

  1. Re-run the bootstrap installer to recreate the venv and CLI shim (the message's intended repair).
  2. Verify the path in the message: does <install_root>/venv/.../hermes exist? If not, the venv is gone.
  3. Make sure HERMES_HOME is the same value the installer used (check ~/.hermes/config.yaml and env).
  4. If the venv exists but at a different location, fix the profile/HERMES_HOME mapping rather than reinstalling.
Defensive patterns

Strategy: validation

Validate before calling

use std::path::{Path, PathBuf};

fn venv_hermes(install_root: &Path) -> PathBuf {
    if cfg!(target_os = "windows") {
        install_root.join("venv").join("Scripts").join("hermes.exe")
    } else {
        install_root.join("venv").join("bin").join("hermes")
    }
}

fn install_repairable(install_root: &Path) -> bool {
    let shim = venv_hermes(install_root);
    shim.is_file() && shim.metadata().map(|m| m.is_file()).unwrap_or(false)
}

if !install_repairable(&install_root) {
    eprintln!("hermes CLI missing under {} — re-run the installer to repair.", install_root.display());
}

Prevention

When it happens

Trigger: HERMES_HOME env changed between install and update so the updater looks in an empty directory; the venv was deleted (partial uninstall, disk cleanup tool); the install never completed (no bootstrap marker/venv); a moved/cloned repo where the install root was never populated.

Common situations: User moved ~/.hermes or ran a cleaner app that wiped it; switching profiles so HERMES_HOME points at a fresh dir; a first-run update triggered before bootstrap ever finished; restoring from backup without the venv (venvs are not relocatable).

Related errors


AI-assisted analysis of NousResearch/hermes-agent@c896c09c42 (2026-08-14). Data as JSON: /api/errors/63b41de76a6b5acf. Report an issue: GitHub.