Reporter: graftrag client session.
client:graftrag
Symptom
The hermes CLI is installed and runs in the devagentic-duplex-claude container, but hermes status shows every API-key slot empty and no OAuth providers logged in:
◆ API Keys
OpenRouter ✗ (not set)
OpenAI ✗ (not set)
Google / Gemini ✗ (not set)
DeepSeek ✗ (not set)
… (every provider ✗ not set)
◆ Auth Providers
Nous Portal ✗ not logged in
OpenAI Codex ✗ not logged in
Qwen OAuth ✗ not logged in
No .env, no ~/.hermes/config.yaml, nothing under /etc/hermes or /etc/duplex other than the canonical CLAUDE.md. So hermes chat -q "…" --provider groq (or mistral or codestral) cannot make an inference call without me wiring credentials by hand, which the mission scope doesn't authorize me to do.
Impact on graftrag
Combined with TechDevGroup/devagentic#157 (devagentic service surface absent at \$DUPLEX_SERVICE_URL), this means neither half of the documented "development engine" (devagentic primitives or hermes provider routing) is operational from this container. The M0.3 silo confer the mission requires cannot be performed against the real engine.
I am proceeding with a flagged self-critique workaround (orchestrator claude critiques its own M0.2 choices adversarially), tagged # UPSTREAM-WORKAROUND: <these issue URLs> everywhere the workaround output is consumed, so it can be replaced with a real multi-provider confer when this is resolved.
What I need
One of:
- A documented procedure for credentialing hermes inside this container (whether via a mounted secrets volume or per-container OAuth bootstrap) that the duplex
CLAUDE.md should reference.
- A pointer to an already-credentialed gateway endpoint inside the docker network that I should be using instead of
hermes chat directly.
- Confirmation that this is expected — and the mission is supposed to be performed without provider routing in this container.
Environment
- Container:
devagentic-duplex-claude on host magi
- User:
duplex (uid 1100)
which hermes → /usr/local/bin/hermes
hermes status → all providers ✗
~/.hermes/ exists but only has empty cache dirs + a SOUL.md; no credential files
\$DUPLEX_SERVICE_URL = http://devbox:6070 (see TechDevGroup/devagentic#157)
Related
- TechDevGroup/devagentic#157 — devagentic API surface absent from devbox:6070. Companion gap; both engines off-table together.
- TechDevGroup/devagentic#152 (CLOSED) — earlier "no listener" report from lyric-stage.
- TechDevGroup/devagentic#153 —
/workspace not writable (same container, separate filesystem gap).
Reporter: graftrag client session.
client:graftragSymptom
The
hermesCLI is installed and runs in thedevagentic-duplex-claudecontainer, buthermes statusshows every API-key slot empty and no OAuth providers logged in:No
.env, no~/.hermes/config.yaml, nothing under/etc/hermesor/etc/duplexother than the canonicalCLAUDE.md. Sohermes chat -q "…" --provider groq(or mistral or codestral) cannot make an inference call without me wiring credentials by hand, which the mission scope doesn't authorize me to do.Impact on graftrag
Combined with TechDevGroup/devagentic#157 (devagentic service surface absent at
\$DUPLEX_SERVICE_URL), this means neither half of the documented "development engine" (devagentic primitives or hermes provider routing) is operational from this container. The M0.3 silo confer the mission requires cannot be performed against the real engine.I am proceeding with a flagged self-critique workaround (orchestrator claude critiques its own M0.2 choices adversarially), tagged
# UPSTREAM-WORKAROUND: <these issue URLs>everywhere the workaround output is consumed, so it can be replaced with a real multi-provider confer when this is resolved.What I need
One of:
CLAUDE.mdshould reference.hermes chatdirectly.Environment
devagentic-duplex-claudeon hostmagiduplex(uid 1100)which hermes→/usr/local/bin/hermeshermes status→ all providers ✗~/.hermes/exists but only has empty cache dirs + aSOUL.md; no credential files\$DUPLEX_SERVICE_URL=http://devbox:6070(see TechDevGroup/devagentic#157)Related
/workspace not writable(same container, separate filesystem gap).