Stacked follow-up on the v2.0.0 rewrite. The merged v2.0.0 template
had three latent issues that only surfaced during local E2E testing:
1) sudo → gosu (python:3.11-slim ships neither; only gosu was in
the Dockerfile). start.sh was calling sudo which would have
broken every container boot.
2) PATH pointed at /home/agent/.hermes/bin which doesn't exist —
install.sh symlinks ~/.local/bin/hermes. Installer is also
interactive by default; needs --skip-setup to run in docker build.
3) start.sh wrote ~/.hermes/cli-config.yaml but hermes-agent reads
~/.hermes/config.yaml. cli-config.yaml.example is just a starter
file — install.sh copies it to config.yaml on first boot. Without
our overwrite the template inherited the example default
(anthropic/claude-opus-4.6 + provider: auto) instead of the
workspace's chosen model. We now rewrite config.yaml every boot
from HERMES_DEFAULT_MODEL + HERMES_INFERENCE_PROVIDER env.
Also:
- Added xz-utils + build-essential to the image (hermes installer
extracts a Node 22 .tar.xz and some Python deps in .[all] build
from source).
- Forward every provider key hermes-agent knows about, not just
the 6 from v2.0.0. All ~22 providers documented in the official
website/docs/integrations/providers.md are now wired:
HERMES_API_KEY, NOUS_API_KEY, OPENROUTER_API_KEY, OPENAI_API_KEY,
ANTHROPIC_API_KEY, GEMINI_API_KEY, GOOGLE_API_KEY, DEEPSEEK_API_KEY,
GLM_API_KEY, KIMI_API_KEY, KIMI_CN_API_KEY, MINIMAX_API_KEY,
MINIMAX_CN_API_KEY, DASHSCOPE_API_KEY, XIAOMI_API_KEY,
ARCEEAI_API_KEY, NVIDIA_API_KEY, OLLAMA_API_KEY, HF_TOKEN,
AI_GATEWAY_API_KEY, KILOCODE_API_KEY, OPENCODE_ZEN_API_KEY,
OPENCODE_GO_API_KEY, COPILOT_GITHUB_TOKEN, GH_TOKEN
- config.yaml models[] list expanded to 30+ entries covering every
provider family (Hermes 3/4, Anthropic direct, OpenAI via
OpenRouter, Gemini direct, DeepSeek, GLM, Kimi, MiniMax global+CN,
Qwen/DashScope, Xiaomi MiMo, Arcee Trinity, NVIDIA NIM, Ollama
Cloud, Hugging Face catch-all, Vercel AI Gateway, OpenCode Zen+Go,
Kilo Code, OpenRouter catch-all, custom/local).
- top-level required_env: [] — hermes supports too many providers
for a single hardcoded requirement; per-model required_env in
the canvas Config tab drives the real UX. hermes-agent itself
errors loud at request time if zero providers are configured.
- HERMES_CUSTOM_BASE_URL / HERMES_CUSTOM_API_KEY env support in
start.sh — lets operators point hermes at OpenAI direct, LM Studio,
LiteLLM, any OpenAI-compat endpoint without exec-ing into the
container.
- HERMES_INFERENCE_PROVIDER env — forces a specific provider,
overriding hermes' auto-detection (which routes OPENAI_API_KEY
to openai-codex OAuth path → 401 Missing Authentication header).
- docs/CONFIGURATION.md rewritten with the full provider matrix,
OAuth flow, forcing a provider, auxiliary model, persistence
layout, and the common routing gotchas surfaced during testing.
- docs/ARCHITECTURE.md adds "Provider routing (how keys become
inference)" section.
Proved end-to-end on local Docker:
[start.sh] hermes gateway ready on :8642 (pid 22)
Uvicorn running on http://0.0.0.0:8000
→ A2A message/send "Respond with HERMES BRIDGE WORKING END TO END"
← HERMES BRIDGE WORKING END TO END — (via OpenAI Responses API)
→ "Run uname -a && whoami && pwd using your terminal tool"
← Linux 094f72... aarch64 GNU/Linux / agent / /home/agent
(real tool call — not chat response)
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
7e7871875c