Summary

When Hermes runs the main agent loop with provider: openai-codex, the raw_codex=True path ignores the resolved/runtime Codex base URL and always constructs the OpenAI client with the hardcoded ChatGPT endpoint.

That makes it impossible to run the main Hermes agent through a Codex-compatible proxy/load balancer, even when runtime resolution or env configuration points somewhere else.

Repro

1. Configure Hermes to use openai-codex
2. Set a custom Codex-compatible base URL via runtime resolution, for example through HERMES_CODEX_BASE_URL
3. Verify resolve_codex_runtime_credentials() returns the custom base URL
4. Run a normal agent turn like:

hermes chat -q "say only: ok"

Actual behavior

The main agent path still uses https://chatgpt.com/backend-api/codex instead of the resolved custom base URL.

In our case this meant:

• config/output suggested Hermes was pointed at a custom Codex LB
• but successful main-agent turns still bypassed that LB
• only manual/probe traffic explicitly aimed at the LB showed up there

Expected behavior

If openai-codex runtime credentials resolve to a custom base URL, the main agent loop should use that resolved URL for the raw Codex client too.

Root cause

The main loop requests resolve_provider_client(..., raw_codex=True) here:

• run_agent.py#L762-L817

But the raw_codex=True branch ignores runtime base URL resolution and hardcodes _CODEX_AUX_BASE_URL here:

• agent/auxiliary_client.py#L1128-L1140

Meanwhile the Codex runtime credential resolver already supports a configurable base URL here:

• hermes_cli/auth.py#L1133-L1185

So the information exists, but the raw Codex client path does not use it.

Notes

This seems distinct from:

• #5736 (empty response.output issue)
• #5161 (OPENAI_BASE_URL poisoning auxiliary routing)

This issue is specifically about the main openai-codex execution path bypassing the resolved custom base URL when raw_codex=True.