Hermes openai-codex fails on same machine/network where official Codex CLI still works

Summary

On the same macOS machine and same network:

• official codex CLI is logged in with ChatGPT and can still complete core model responses
• Hermes Agent configured with openai-codex repeatedly fails in gateway/chat usage with:
  • APIConnectionError
  • APITimeoutError
  • final user-visible message: API failed after 3 retries — Connection error.

This suggests Hermes' openai-codex compatibility path is not equivalent to the official Codex CLI transport on this environment, even though both target ChatGPT/Codex-backed auth.

Environment

• OS: macOS 15.6 (arm64)
• Hermes: main branch around tag v2026.4.16
• Hermes provider: openai-codex
• Hermes base URL: https://chatgpt.com/backend-api/codex
• Official Codex CLI: codex-cli 0.120.0

What happens in Hermes

Hermes gateway/chat receives the inbound message, but model calls fail repeatedly.

Observed Hermes logs:

API call failed (attempt 1/3): APIConnectionError
Provider: openai-codex  Model: gpt-5.4
Endpoint: https://chatgpt.com/backend-api/codex
Error: Connection error.

API call failed (attempt 1/3): APITimeoutError
Provider: openai-codex  Model: gpt-5.4
Endpoint: https://chatgpt.com/backend-api/codex
Error: Request timed out.

Max retries (3) exhausted — trying fallback...
API failed after 3 retries — Connection error.

hermes status shows:

• OpenAI Codex auth: logged in
• Gateway service: running

So this does not appear to be a basic login/config/service-startup failure.

Direct endpoint behavior from shell

A simple curl to the Codex backend shows Cloudflare mitigation on this machine/network:

HTTP/2 403
cf-mitigated: challenge

This is consistent with Hermes source comments in agent/auxiliary_client.py noting that chatgpt.com/backend-api/codex is behind Cloudflare and may reject requests with 403 / cf-mitigated: challenge.

What happens in official Codex CLI on the same machine/network

Official Codex CLI is logged in successfully:

$ codex login status
Logged in using ChatGPT

Official Codex CLI local logs show successful core response flow on this same machine:

• codex_api::endpoint::responses_websocket
• codex_api::sse::responses
• response.created
• response.in_progress
• response.completed

So the official CLI is still able to complete at least the main response path here.

Important nuance

Official Codex CLI is not completely free of 403s on this machine. Its logs also show 403s for some auxiliary endpoints, e.g.:

• https://chatgpt.com/backend-api/plugins/featured
• analytics/events-related calls
• discoverable tool/apps list calls

However, despite those 403s, the official CLI can still complete core model responses.

Hermes, by contrast, fails on the main Codex request path with timeouts / connection errors.

Why this looks like a Hermes compatibility gap

From source inspection:

• Hermes openai-codex uses https://chatgpt.com/backend-api/codex
• Hermes sets _codex_cloudflare_headers(...) to mimic approved originators
• Hermes appears to use an OpenAI-compatible client + custom wrapping (codex_responses mode)
• Official Codex CLI appears to use a more native transport path involving websocket/SSE response handling

So on this environment, Hermes may be close to the official client but not close enough to pass whatever backend expectations/mitigations affect the main response path.

Expected behavior

If official Codex CLI can successfully complete core responses on the same machine/network with the same login family, Hermes openai-codex should ideally also be able to complete core responses, or at least degrade in a way that matches the official transport path more closely.

Actual behavior

Hermes repeatedly times out / connection-fails on the main Codex path and becomes unusable in gateway/chat flows.

Repro outline

1. Log in to official Codex CLI with ChatGPT
2. Confirm codex login status succeeds
3. Confirm official Codex CLI can still complete at least one normal prompt on the same machine/network
4. Configure Hermes to use openai-codex
5. Send a message through Hermes gateway or Hermes chat
6. Observe repeated APIConnectionError / APITimeoutError against https://chatgpt.com/backend-api/codex

Questions

1. Is Hermes' openai-codex path known to differ materially from the official Codex CLI transport in ways that could explain this?
2. Is there a known issue where official Codex CLI still works but Hermes openai-codex fails on the same machine/network?
3. Should Hermes be reusing a more native Codex transport path for the primary response flow instead of an OpenAI-compatible compatibility layer?
4. Are there additional headers / handshake / websocket behaviors the official client uses that Hermes does not yet mirror?

Relevant local observations

• Hermes source explicitly comments that Cloudflare can reject Codex backend calls
• Official Codex CLI shows successful responses_websocket / sse activity locally
• Hermes fails on the primary model request path, not just plugin/analytics side endpoints

If useful, I can provide

• sanitized Hermes logs
• sanitized codex local log excerpts
• exact Hermes config fields for provider/model/api_mode