Surfaced while triaging #9 (client:graftrag) — the env-layer workaround there works, but hermes status still gives misleading-looking output in the post-workaround state. Two small gaps:
1. apikey_providers omits Groq and Mistral
hermes_cli/status.py:127 enumerates ~20 known providers but does not include GROQ_API_KEY or MISTRAL_API_KEY — even though both are first-class hermes providers:
hermes_cli/config.py:2325 registers MISTRAL_API_KEY (Voxtral TTS + STT).
hermes_cli/doctor.py:99 calls out GROQ_API_KEY (Whisper STT fallback).
hermes_cli/setup.py has prompts that save MISTRAL_API_KEY.
Repro inside the duplex container after set -a; source ~/.env; set +a:
◆ API Keys
OpenRouter ✗ (not set)
OpenAI ✓ sk-…
Google / Gemini ✓ AIza…
…
Even though both GROQ_API_KEY and MISTRAL_API_KEY are exported, neither shows up — the status display silently drops them, so a user troubleshooting routing has no visual confirmation those keys made it through.
2. No diagnostic when \$HOME/.env exists but ~/.hermes/.env doesn't
env_loader.py:142 only reads ~/.hermes/.env (+ optional project_env). Containerized clients (#8, #9) hit a setup where the orchestrator drops creds at ~/.env (POSIX convention) and hermes status then reports every provider as ✗ not set despite the keys being right there on disk. The user has to know to set -a; source ~/.env; set +a first.
We shouldn't auto-load \$HOME/.env (it's not hermes-namespaced — too easy to clobber unrelated user env). But the status / doctor command can detect the situation and print a one-line hint, e.g.:
◆ Environment
Project: …
Python: 3.11.2
.env file: ✗ not found at /home/duplex/.hermes/.env
(found /home/duplex/.env — run: set -a; source ~/.env; set +a
to load it for this shell, or move it to ~/.hermes/.env)
That alone would have saved the round-trip in #8 and #9.
Scope of fix
- Add
Groq: GROQ_API_KEY and Mistral: MISTRAL_API_KEY rows to apikey_providers in hermes_cli/status.py:127.
- In the same file, when
env_path.exists() is false, also check \$HOME/.env and surface a one-line hint if present.
Both small, surgical changes. I'll send a PR.
Filed by hermes-maintainer (PowerCreek) during triage of #9.
Surfaced while triaging #9 (client:graftrag) — the env-layer workaround there works, but
hermes statusstill gives misleading-looking output in the post-workaround state. Two small gaps:1.
apikey_providersomits Groq and Mistralhermes_cli/status.py:127enumerates ~20 known providers but does not includeGROQ_API_KEYorMISTRAL_API_KEY— even though both are first-class hermes providers:hermes_cli/config.py:2325registersMISTRAL_API_KEY(Voxtral TTS + STT).hermes_cli/doctor.py:99calls outGROQ_API_KEY(Whisper STT fallback).hermes_cli/setup.pyhas prompts that saveMISTRAL_API_KEY.Repro inside the duplex container after
set -a; source ~/.env; set +a:Even though both
GROQ_API_KEYandMISTRAL_API_KEYare exported, neither shows up — the status display silently drops them, so a user troubleshooting routing has no visual confirmation those keys made it through.2. No diagnostic when
\$HOME/.envexists but~/.hermes/.envdoesn'tenv_loader.py:142only reads~/.hermes/.env(+ optional project_env). Containerized clients (#8, #9) hit a setup where the orchestrator drops creds at~/.env(POSIX convention) andhermes statusthen reports every provider as✗ not setdespite the keys being right there on disk. The user has to know toset -a; source ~/.env; set +afirst.We shouldn't auto-load
\$HOME/.env(it's not hermes-namespaced — too easy to clobber unrelated user env). But the status / doctor command can detect the situation and print a one-line hint, e.g.:That alone would have saved the round-trip in #8 and #9.
Scope of fix
Groq: GROQ_API_KEYandMistral: MISTRAL_API_KEYrows toapikey_providersinhermes_cli/status.py:127.env_path.exists()is false, also check\$HOME/.envand surface a one-line hint if present.Both small, surgical changes. I'll send a PR.
Filed by hermes-maintainer (PowerCreek) during triage of #9.