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 asView on GitHub (pinned to c896c09c42)
Solutions
- Re-run the bootstrap installer to recreate the venv and CLI shim (the message's intended repair).
- Verify the path in the message: does <install_root>/venv/.../hermes exist? If not, the venv is gone.
- Make sure HERMES_HOME is the same value the installer used (check ~/.hermes/config.yaml and env).
- 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
- Verify the hermes shim exists under the install root before invoking any update flow.
- Keep HERMES_HOME stable between install and update (same profile, same env).
- Exclude ~/.hermes from disk cleaners and partial backups that drop the venv.
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
- desktop rebuild succeeded but no Hermes.app was found under
- ditto failed while copying updated app into {}
- could not move existing app aside at {} (leaving it in place
- installing updated app at {}: {err}
- write bootstrap marker failed: {err:#}
AI-assisted analysis of NousResearch/hermes-agent@c896c09c42 (2026-08-14).
Data as JSON: /api/errors/63b41de76a6b5acf.
Report an issue: GitHub.