Skip to content

fix(desktop): codex OAuth onboarding resolves on fresh install#37506

Closed
teknium1 wants to merge 1 commit into
mainfrom
hermes/hermes-d1511484
Closed

fix(desktop): codex OAuth onboarding resolves on fresh install#37506
teknium1 wants to merge 1 commit into
mainfrom
hermes/hermes-d1511484

Conversation

@teknium1

@teknium1 teknium1 commented Jun 2, 2026

Copy link
Copy Markdown
Contributor

Summary

Picking OpenAI Codex (ChatGPT) in the desktop app's first-run provider setup now resolves to a working provider instead of erroring out.

Root cause: the desktop codex device-code worker persisted tokens with a hand-rolled pool.add_entry(), writing only credential_pool.openai-codex. It never set active_provider. On a fresh install (no ~/.hermes, no env keys) the onboarding flow immediately runs setup.runtime_checkresolve_runtime_provider("auto"), which detects OAuth providers only via active_provider — so it fell through and raised "No inference provider configured". Meanwhile setup.status (which sniffs the pool) reported configured, producing the disagreement banner: "Connected, but Hermes still cannot resolve a usable provider."

Changes

  • hermes_cli/web_server.py _codex_full_login_worker: persist via the canonical _save_codex_tokens() instead of a bare pool write. It writes the providers.openai-codex singleton (which sets active_provider) and syncs the pool — matching the CLI hermes auth add openai-codex path and the Nous (persist_nous_credentials) / MiniMax (_minimax_save_auth_state) dashboard workers, which were already correct.

Validation

E2E on a fresh empty HERMES_HOME with all provider env vars unset:

Before After
active_provider after codex OAuth None openai-codex
setup.runtime_check raises "No inference provider configured" OK → openai-codex
Onboarding banner "cannot resolve a usable provider" proceeds to chat

Infographic

nous-system7

The desktop codex device-code worker persisted tokens with a hand-rolled
pool.add_entry(), writing only credential_pool.openai-codex. It never set
active_provider, so on a fresh install the onboarding setup.runtime_check
resolved provider "auto", couldn't detect the Codex OAuth session, and raised
"No inference provider configured" — while setup.status (which sniffs the pool)
reported configured. The disagreement surfaced as the onboarding banner
"Connected, but Hermes still cannot resolve a usable provider."

Use the canonical _save_codex_tokens() instead, matching the CLI's
`hermes auth add openai-codex` path and the Nous/MiniMax dashboard workers.
It writes the providers.openai-codex singleton (setting active_provider) and
syncs the pool.
@github-actions

github-actions Bot commented Jun 2, 2026

Copy link
Copy Markdown
Contributor

🔎 Lint report: hermes/hermes-d1511484 vs origin/main

ruff

Total: 0 on HEAD, 0 on base (➖ 0)

🆕 New issues: none

✅ Fixed issues: none

Unchanged: 0 pre-existing issues carried over.

ty (type checker)

Total: 9678 on HEAD, 9678 on base (➖ 0)

🆕 New issues: none

✅ Fixed issues: none

Unchanged: 5014 pre-existing issues carried over.

Diagnostics are surfaced as warnings — this check never fails the build.

@alt-glitch alt-glitch added type/bug Something isn't working comp/cli CLI entry point, hermes_cli/, setup wizard provider/openai OpenAI / Codex Responses API P2 Medium — degraded but workaround exists labels Jun 2, 2026
@austinpickett austinpickett requested a review from Copilot June 2, 2026 17:01

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Fixes the desktop app’s first-run OpenAI Codex (ChatGPT) OAuth onboarding so that a successful device-code login results in a resolvable runtime provider on fresh installs (by persisting via the canonical auth-store helper that sets active_provider).

Changes:

  • Replace the hand-rolled credential_pool.openai-codex write in the Codex device-code worker with hermes_cli.auth._save_codex_tokens(...).
  • Ensure the Codex login path sets the providers.openai-codex singleton (and thus active_provider) to align dashboard onboarding with the CLI flow.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread hermes_cli/web_server.py
Comment on lines +3720 to +3731
# Persist via the canonical Codex token store. _save_codex_tokens writes
# the providers.openai-codex singleton (which sets active_provider via
# _save_provider_state) AND syncs the credential pool. The previous
# hand-rolled pool.add_entry() only seeded credential_pool.openai-codex,
# leaving active_provider=None — so on a fresh install the immediately-
# following setup.runtime_check resolved provider "auto", couldn't detect
# the Codex OAuth session, and raised "No inference provider configured"
# while setup.status (which sniffs the pool) reported configured. That
# divergence produced the desktop onboarding "Connected, but Hermes still
# cannot resolve a usable provider" error. This mirrors the CLI's
# `hermes auth add openai-codex` path and the Nous/MiniMax dashboard
# workers, which all use their canonical save helpers.
Comment thread hermes_cli/web_server.py
Comment on lines +3732 to +3736
from hermes_cli.auth import _save_codex_tokens
_save_codex_tokens({
"access_token": access_token,
"refresh_token": refresh_token,
})
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

comp/cli CLI entry point, hermes_cli/, setup wizard P2 Medium — degraded but workaround exists provider/openai OpenAI / Codex Responses API type/bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants