Skip to content

[client:graftrag] hermes CLI in devagentic-duplex-claude container has zero provider credentials wired — multi-provider critique not viable #9

@PowerCreek

Description

@PowerCreek

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:

  1. 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.
  2. A pointer to an already-credentialed gateway endpoint inside the docker network that I should be using instead of hermes chat directly.
  3. 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).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions