hermes - 💡(How to fix) Fix Codex OAuth refresh token gets consumed by sibling Codex clients (Codex CLI / VS Code extension), permanently invalidating Hermes session until manual re-auth

Summary

When Hermes is configured to use OpenAI Codex via OAuth (openai-codex provider, mode: oauth) AND another Codex client (the codex CLI itself, or the VS Code Codex extension) is also signed into the same OpenAI account on the same machine, refresh-token rotation lets whichever client refreshes first invalidate the OAuth state for everyone else. Hermes's own self-diagnostic captures the failure mode cleanly:

hermes status
…
◆ Auth Providers
  OpenAI Codex  ✗ not logged in (run: hermes model)
    Auth file:  /root/.hermes/auth.json
    Error:      Codex refresh token was already consumed by another client
                (e.g. Codex CLI or VS Code extension). Run `codex` in your
                terminal to generate fresh tokens, then run `hermes auth`
                to re-authenticate.

Once this state is reached, every Hermes turn against gpt-5.5 (or any other Codex model) fails on the WebSocket upgrade with:

provider_transport_failure: Received network error or non-101 status code

…driven by the underlying provider error:

"Your authentication token has been invalidated. Please try signing in again."

Which the agent surfaces to the user as [assistant turn failed before producing content] (recorded in session JSONL with stop=error). On a Telegram-bot deployment this manifests as a series of empty/minimal placeholder replies with no clear cause.

Repro

1. Sign Hermes into OpenAI Codex via OAuth (hermes auth).
2. On the same machine, also sign in via the codex CLI or the VS Code Codex extension.
3. Trigger any of the other clients to perform a refresh (open the IDE, run a codex command, etc.).
4. The next Hermes Codex request fails with auth invalidation.
5. The state cannot be recovered without re-running codex interactively, which then invalidates the other clients in turn — so any user who runs both Hermes and Codex CLI/IDE on one machine ends up in a perpetual ping-pong of broken auth.

What I'd suggest

• Detect mid-session. Hermes already has the diagnostic — hermes status correctly reports the state. But a session that's already been initialized doesn't fire this check on each turn; the failure first manifests as a generic transport error. Detect the invalidated-token state when a Codex turn fails with the auth-invalidation signature and either (a) auto-cascade to the configured fallback provider for that turn, or (b) surface a high-visibility user-facing notice rather than the silent [assistant turn failed before producing content] placeholder.
• Hint at the cause. When Hermes diagnoses this, it's already correct in hermes status. Same diagnostic should be visible in the per-session error envelope so operators can see it without running hermes status separately.
• Long-term root cause. Per-client OAuth tokens (each client gets its own refresh token), or an OS-level shared OAuth broker that doesn't burn sibling clients on refresh, would eliminate the underlying mechanism. This is partly a Codex auth-server design constraint but Hermes can document and harden against it locally.

Environment

• Hermes Agent v0.10.0 (2026.4.16)
• Python 3.11.15
• WSL Ubuntu / Windows 10
• Concurrent Codex clients on the same machine: codex CLI and VS Code Codex extension.

Related

Filed jointly with an issue against openclaw/openclaw covering downstream cascade behavior (an auth-invalidated primary provider in OpenClaw produces an empty placeholder reply instead of cascading to the fallback chain). The OpenClaw issue is independently a bug; this issue is about the upstream OAuth root cause that triggers it.