Summary
On native Windows, a fresh install fails with No inference provider configured even when %LOCALAPPDATA%\hermes\.env contains a valid ANTHROPIC_API_KEY (or any provider key). The .env file is never loaded because the installed hermes entrypoint resolves the Hermes home to the POSIX default ~/.hermes instead of the Windows-native %LOCALAPPDATA%\hermes.
Root cause
The console-script entrypoint is hermes_cli.main:main. At import time hermes_cli/main.py loads the dotenv:
# hermes_cli/main.py:519
load_hermes_dotenv(project_env=PROJECT_ROOT / ".env")
hermes_home is not passed. In env_loader.load_hermes_dotenv:
home_path = Path(hermes_home or os.getenv("HERMES_HOME", Path.home() / ".hermes"))
With hermes_home=None and HERMES_HOME unset (the default), home_path becomes Path.home() / ".hermes" = C:\Users\<user>\.hermes — which does not exist on Windows. The real home (per hermes_constants.get_hermes_home() / _get_platform_default_hermes_home()) is %LOCALAPPDATA%\hermes. So the user's .env is silently skipped.
hermes config show masks the bug: it displays the correct path via get_env_path() (which uses get_hermes_home()), so the "Secrets" line reads %LOCALAPPDATA%\hermes\.env, but the actual dotenv load used the wrong directory. Result: every key shows (not set).
Notably main.py already imports the correct helper two lines above but doesn't use it:
# main.py:516
from hermes_cli.config import get_hermes_home
And the other entrypoint gets it right — cli.py:182:
load_hermes_dotenv(hermes_home=_hermes_home, project_env=_project_env)
Reproduce
- Native Windows (no WSL),
HERMES_HOME unset.
- Install, then write a key to
%LOCALAPPDATA%\hermes\.env:
ANTHROPIC_API_KEY=sk-ant-...
hermes config show → Anthropic (not set); hermes → No inference provider configured (error text even points at ~/.hermes/.env).
Workaround: set HERMES_HOME=%LOCALAPPDATA%\hermes as a user env var — but that shouldn't be required, since get_hermes_home() already knows the correct default.
Fix
Pass the resolved home, matching cli.py:
load_hermes_dotenv(hermes_home=get_hermes_home(), project_env=PROJECT_ROOT / ".env")
PR attached.
Environment: Windows 11, Hermes 0.18.0, local editable (uv pip install -e .), Python 3.13.
Summary
On native Windows, a fresh install fails with
No inference provider configuredeven when%LOCALAPPDATA%\hermes\.envcontains a validANTHROPIC_API_KEY(or any provider key). The.envfile is never loaded because the installedhermesentrypoint resolves the Hermes home to the POSIX default~/.hermesinstead of the Windows-native%LOCALAPPDATA%\hermes.Root cause
The console-script entrypoint is
hermes_cli.main:main. At import timehermes_cli/main.pyloads the dotenv:hermes_homeis not passed. Inenv_loader.load_hermes_dotenv:With
hermes_home=NoneandHERMES_HOMEunset (the default),home_pathbecomesPath.home() / ".hermes"=C:\Users\<user>\.hermes— which does not exist on Windows. The real home (perhermes_constants.get_hermes_home()/_get_platform_default_hermes_home()) is%LOCALAPPDATA%\hermes. So the user's.envis silently skipped.hermes config showmasks the bug: it displays the correct path viaget_env_path()(which usesget_hermes_home()), so the "Secrets" line reads%LOCALAPPDATA%\hermes\.env, but the actual dotenv load used the wrong directory. Result: every key shows(not set).Notably
main.pyalready imports the correct helper two lines above but doesn't use it:And the other entrypoint gets it right —
cli.py:182:Reproduce
HERMES_HOMEunset.%LOCALAPPDATA%\hermes\.env:ANTHROPIC_API_KEY=sk-ant-...hermes config show→ Anthropic (not set);hermes→ No inference provider configured (error text even points at~/.hermes/.env).Workaround: set
HERMES_HOME=%LOCALAPPDATA%\hermesas a user env var — but that shouldn't be required, sinceget_hermes_home()already knows the correct default.Fix
Pass the resolved home, matching
cli.py:PR attached.
Environment: Windows 11, Hermes 0.18.0, local editable (
uv pip install -e .), Python 3.13.