fix(auth): align Codex OAuth persistence paths - #37517
Merged
Merged
Conversation
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.
Ensure desktop and CLI Codex OAuth logins both write the canonical provider state so fresh installs resolve a usable runtime provider.
Contributor
🔎 Lint report:
|
| Rule | Count |
|---|---|
invalid-argument-type |
1 |
First entries
hermes_cli/auth_commands.py:317: [invalid-argument-type] invalid-argument-type: Argument to function `_save_codex_tokens` is incorrect: Expected `str`, found `Any | None`
✅ Fixed issues: none
Unchanged: 5014 pre-existing issues carried over.
Diagnostics are surfaced as warnings — this check never fails the build.
alt-glitch
added
type/bug
AhmetArif0
added a commit
to AhmetArif0/hermes-agent
that referenced
this pull request
Jun 2, 2026
…provider hermes auth add xai-oauth called pool.add_entry() directly, writing only the credential-pool entry (source "manual:xai_pkce") without touching providers["xai-oauth"] or setting active_provider in auth.json. _model_section_has_credentials() checks get_active_provider() first; with active_provider unset and no api_key_env_vars configured for oauth_external providers, the setup wizard reported "No inference provider configured" even after a successful OAuth login. Use _save_xai_oauth_tokens() — the canonical path already called from the hermes model xAI login flow — which writes providers["xai-oauth"]["tokens"] (setting active_provider) and lets _seed_from_singletons seed the pool with a "loopback_pkce" entry on the next load_pool() call. Mirrors the fix applied to openai-codex in NousResearch#37517.
AhmetArif0
added a commit
to AhmetArif0/hermes-agent
that referenced
this pull request
Jun 2, 2026
hermes auth add google-gemini-cli called pool.add_entry() but never wrote to providers["google-gemini-cli"] or set active_provider in auth.json. _model_section_has_credentials() checks get_active_provider() first; with active_provider unset and no api_key_env_vars configured for oauth_external providers, the setup wizard reported "No inference provider configured" even after a successful OAuth login. Add _mark_google_gemini_cli_active() in auth.py: writes a minimal provider state entry (email for display only) and calls _save_provider_state() to set active_provider. The function deliberately does not copy access_token or refresh_token — those are managed by agent.google_oauth in the Google credential file and must not be duplicated in auth.json where they would become stale. pool.add_entry() is retained so "hermes auth list" continues to show the entry. Runtime credential resolution continues to use agent.google_oauth directly. Mirrors the fix applied to openai-codex (NousResearch#37517) and xai-oauth (NousResearch#37576).
AhmetArif0
added a commit
to AhmetArif0/hermes-agent
that referenced
this pull request
Jun 2, 2026
hermes auth add qwen-oauth called pool.add_entry() but never wrote to providers["qwen-oauth"] or set active_provider in auth.json. _model_section_has_credentials() checks get_active_provider() first; with active_provider unset and no api_key_env_vars configured for oauth_external providers, the setup wizard reported "No inference provider configured" even after a successful Qwen CLI OAuth login. Add _mark_qwen_oauth_active() in auth.py: writes a minimal provider state entry (base_url for display only) and calls _save_provider_state() to set active_provider. The function deliberately does not copy the api_key — that lives in the Qwen CLI credential file managed by _save_qwen_cli_tokens / resolve_qwen_runtime_credentials and must not be duplicated in auth.json where it would become stale. pool.add_entry() is retained so "hermes auth list" continues to show the entry. Runtime credential resolution continues to use resolve_qwen_runtime_credentials. Mirrors the fix applied to openai-codex (NousResearch#37517) and xai-oauth (NousResearch#37576).
This was referenced Jun 4, 2026
teknium1
pushed a commit
that referenced
this pull request
Jun 4, 2026
hermes auth add google-gemini-cli called pool.add_entry() but never wrote to providers["google-gemini-cli"] or set active_provider in auth.json. _model_section_has_credentials() checks get_active_provider() first; with active_provider unset and no api_key_env_vars configured for oauth_external providers, the setup wizard reported "No inference provider configured" even after a successful OAuth login. Add _mark_google_gemini_cli_active() in auth.py: writes a minimal provider state entry (email for display only) and calls _save_provider_state() to set active_provider. The function deliberately does not copy access_token or refresh_token — those are managed by agent.google_oauth in the Google credential file and must not be duplicated in auth.json where they would become stale. pool.add_entry() is retained so "hermes auth list" continues to show the entry. Runtime credential resolution continues to use agent.google_oauth directly. Mirrors the fix applied to openai-codex (#37517) and xai-oauth (#37576).
teknium1
pushed a commit
that referenced
this pull request
Jun 4, 2026
hermes auth add qwen-oauth called pool.add_entry() but never wrote to providers["qwen-oauth"] or set active_provider in auth.json. _model_section_has_credentials() checks get_active_provider() first; with active_provider unset and no api_key_env_vars configured for oauth_external providers, the setup wizard reported "No inference provider configured" even after a successful Qwen CLI OAuth login. Add _mark_qwen_oauth_active() in auth.py: writes a minimal provider state entry (base_url for display only) and calls _save_provider_state() to set active_provider. The function deliberately does not copy the api_key — that lives in the Qwen CLI credential file managed by _save_qwen_cli_tokens / resolve_qwen_runtime_credentials and must not be duplicated in auth.json where it would become stale. pool.add_entry() is retained so "hermes auth list" continues to show the entry. Runtime credential resolution continues to use resolve_qwen_runtime_credentials. Mirrors the fix applied to openai-codex (#37517) and xai-oauth (#37576).
teknium1
pushed a commit
that referenced
this pull request
Jun 4, 2026
…provider hermes auth add xai-oauth called pool.add_entry() directly, writing only the credential-pool entry (source "manual:xai_pkce") without touching providers["xai-oauth"] or setting active_provider in auth.json. _model_section_has_credentials() checks get_active_provider() first; with active_provider unset and no api_key_env_vars configured for oauth_external providers, the setup wizard reported "No inference provider configured" even after a successful OAuth login. Use _save_xai_oauth_tokens() — the canonical path already called from the hermes model xAI login flow — which writes providers["xai-oauth"]["tokens"] (setting active_provider) and lets _seed_from_singletons seed the pool with a "loopback_pkce" entry on the next load_pool() call. Mirrors the fix applied to openai-codex in #37517.
teknium1
pushed a commit
that referenced
this pull request
Jun 4, 2026
hermes auth add qwen-oauth called pool.add_entry() but never wrote to providers["qwen-oauth"] or set active_provider in auth.json. _model_section_has_credentials() checks get_active_provider() first; with active_provider unset and no api_key_env_vars configured for oauth_external providers, the setup wizard reported "No inference provider configured" even after a successful Qwen CLI OAuth login. Add _mark_qwen_oauth_active() in auth.py: writes a minimal provider state entry (base_url for display only) and calls _save_provider_state() to set active_provider. The function deliberately does not copy the api_key — that lives in the Qwen CLI credential file managed by _save_qwen_cli_tokens / resolve_qwen_runtime_credentials and must not be duplicated in auth.json where it would become stale. pool.add_entry() is retained so "hermes auth list" continues to show the entry. Runtime credential resolution continues to use resolve_qwen_runtime_credentials. Mirrors the fix applied to openai-codex (#37517) and xai-oauth (#37576).
waym0reom3ga
pushed a commit
to waym0reom3ga/autolycus-agent
that referenced
this pull request
Jun 4, 2026
hermes auth add google-gemini-cli called pool.add_entry() but never wrote to providers["google-gemini-cli"] or set active_provider in auth.json. _model_section_has_credentials() checks get_active_provider() first; with active_provider unset and no api_key_env_vars configured for oauth_external providers, the setup wizard reported "No inference provider configured" even after a successful OAuth login. Add _mark_google_gemini_cli_active() in auth.py: writes a minimal provider state entry (email for display only) and calls _save_provider_state() to set active_provider. The function deliberately does not copy access_token or refresh_token — those are managed by agent.google_oauth in the Google credential file and must not be duplicated in auth.json where they would become stale. pool.add_entry() is retained so "hermes auth list" continues to show the entry. Runtime credential resolution continues to use agent.google_oauth directly. Mirrors the fix applied to openai-codex (NousResearch#37517) and xai-oauth (NousResearch#37576).
waym0reom3ga
pushed a commit
to waym0reom3ga/autolycus-agent
that referenced
this pull request
Jun 4, 2026
…provider hermes auth add xai-oauth called pool.add_entry() directly, writing only the credential-pool entry (source "manual:xai_pkce") without touching providers["xai-oauth"] or setting active_provider in auth.json. _model_section_has_credentials() checks get_active_provider() first; with active_provider unset and no api_key_env_vars configured for oauth_external providers, the setup wizard reported "No inference provider configured" even after a successful OAuth login. Use _save_xai_oauth_tokens() — the canonical path already called from the hermes model xAI login flow — which writes providers["xai-oauth"]["tokens"] (setting active_provider) and lets _seed_from_singletons seed the pool with a "loopback_pkce" entry on the next load_pool() call. Mirrors the fix applied to openai-codex in NousResearch#37517.
waym0reom3ga
pushed a commit
to waym0reom3ga/autolycus-agent
that referenced
this pull request
Jun 4, 2026
hermes auth add qwen-oauth called pool.add_entry() but never wrote to providers["qwen-oauth"] or set active_provider in auth.json. _model_section_has_credentials() checks get_active_provider() first; with active_provider unset and no api_key_env_vars configured for oauth_external providers, the setup wizard reported "No inference provider configured" even after a successful Qwen CLI OAuth login. Add _mark_qwen_oauth_active() in auth.py: writes a minimal provider state entry (base_url for display only) and calls _save_provider_state() to set active_provider. The function deliberately does not copy the api_key — that lives in the Qwen CLI credential file managed by _save_qwen_cli_tokens / resolve_qwen_runtime_credentials and must not be duplicated in auth.json where it would become stale. pool.add_entry() is retained so "hermes auth list" continues to show the entry. Runtime credential resolution continues to use resolve_qwen_runtime_credentials. Mirrors the fix applied to openai-codex (NousResearch#37517) and xai-oauth (NousResearch#37576).
kossteg
pushed a commit
to kossteg/hermes-agent
that referenced
this pull request
Jun 16, 2026
hermes auth add qwen-oauth called pool.add_entry() but never wrote to providers["qwen-oauth"] or set active_provider in auth.json. _model_section_has_credentials() checks get_active_provider() first; with active_provider unset and no api_key_env_vars configured for oauth_external providers, the setup wizard reported "No inference provider configured" even after a successful Qwen CLI OAuth login. Add _mark_qwen_oauth_active() in auth.py: writes a minimal provider state entry (base_url for display only) and calls _save_provider_state() to set active_provider. The function deliberately does not copy the api_key — that lives in the Qwen CLI credential file managed by _save_qwen_cli_tokens / resolve_qwen_runtime_credentials and must not be duplicated in auth.json where it would become stale. pool.add_entry() is retained so "hermes auth list" continues to show the entry. Runtime credential resolution continues to use resolve_qwen_runtime_credentials. Mirrors the fix applied to openai-codex (NousResearch#37517) and xai-oauth (NousResearch#37576).
T02200059
pushed a commit
to T02200059/hermes-agent
that referenced
this pull request
Jun 18, 2026
* fix(desktop): codex OAuth onboarding now resolves on fresh install 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. * fix(auth): align Codex OAuth persistence paths Ensure desktop and CLI Codex OAuth logins both write the canonical provider state so fresh installs resolve a usable runtime provider. --------- Co-authored-by: teknium1 <127238744+teknium1@users.noreply.github.com>
T02200059
pushed a commit
to T02200059/hermes-agent
that referenced
this pull request
Jun 18, 2026
hermes auth add google-gemini-cli called pool.add_entry() but never wrote to providers["google-gemini-cli"] or set active_provider in auth.json. _model_section_has_credentials() checks get_active_provider() first; with active_provider unset and no api_key_env_vars configured for oauth_external providers, the setup wizard reported "No inference provider configured" even after a successful OAuth login. Add _mark_google_gemini_cli_active() in auth.py: writes a minimal provider state entry (email for display only) and calls _save_provider_state() to set active_provider. The function deliberately does not copy access_token or refresh_token — those are managed by agent.google_oauth in the Google credential file and must not be duplicated in auth.json where they would become stale. pool.add_entry() is retained so "hermes auth list" continues to show the entry. Runtime credential resolution continues to use agent.google_oauth directly. Mirrors the fix applied to openai-codex (NousResearch#37517) and xai-oauth (NousResearch#37576).
T02200059
pushed a commit
to T02200059/hermes-agent
that referenced
this pull request
Jun 18, 2026
…provider hermes auth add xai-oauth called pool.add_entry() directly, writing only the credential-pool entry (source "manual:xai_pkce") without touching providers["xai-oauth"] or setting active_provider in auth.json. _model_section_has_credentials() checks get_active_provider() first; with active_provider unset and no api_key_env_vars configured for oauth_external providers, the setup wizard reported "No inference provider configured" even after a successful OAuth login. Use _save_xai_oauth_tokens() — the canonical path already called from the hermes model xAI login flow — which writes providers["xai-oauth"]["tokens"] (setting active_provider) and lets _seed_from_singletons seed the pool with a "loopback_pkce" entry on the next load_pool() call. Mirrors the fix applied to openai-codex in NousResearch#37517.
T02200059
pushed a commit
to T02200059/hermes-agent
that referenced
this pull request
Jun 18, 2026
hermes auth add qwen-oauth called pool.add_entry() but never wrote to providers["qwen-oauth"] or set active_provider in auth.json. _model_section_has_credentials() checks get_active_provider() first; with active_provider unset and no api_key_env_vars configured for oauth_external providers, the setup wizard reported "No inference provider configured" even after a successful Qwen CLI OAuth login. Add _mark_qwen_oauth_active() in auth.py: writes a minimal provider state entry (base_url for display only) and calls _save_provider_state() to set active_provider. The function deliberately does not copy the api_key — that lives in the Qwen CLI credential file managed by _save_qwen_cli_tokens / resolve_qwen_runtime_credentials and must not be duplicated in auth.json where it would become stale. pool.add_entry() is retained so "hermes auth list" continues to show the entry. Runtime credential resolution continues to use resolve_qwen_runtime_credentials. Mirrors the fix applied to openai-codex (NousResearch#37517) and xai-oauth (NousResearch#37576).
xyshanren
pushed a commit
to xyshanren/hermes-agent-cn
that referenced
this pull request
Jun 25, 2026
hermes auth add qwen-oauth called pool.add_entry() but never wrote to providers["qwen-oauth"] or set active_provider in auth.json. _model_section_has_credentials() checks get_active_provider() first; with active_provider unset and no api_key_env_vars configured for oauth_external providers, the setup wizard reported "No inference provider configured" even after a successful Qwen CLI OAuth login. Add _mark_qwen_oauth_active() in auth.py: writes a minimal provider state entry (base_url for display only) and calls _save_provider_state() to set active_provider. The function deliberately does not copy the api_key — that lives in the Qwen CLI credential file managed by _save_qwen_cli_tokens / resolve_qwen_runtime_credentials and must not be duplicated in auth.json where it would become stale. pool.add_entry() is retained so "hermes auth list" continues to show the entry. Runtime credential resolution continues to use resolve_qwen_runtime_credentials. Mirrors the fix applied to openai-codex (NousResearch#37517) and xai-oauth (NousResearch#37576).
xyshanren
pushed a commit
to xyshanren/hermes-agent-cn
that referenced
this pull request
Jun 25, 2026
…provider hermes auth add xai-oauth called pool.add_entry() directly, writing only the credential-pool entry (source "manual:xai_pkce") without touching providers["xai-oauth"] or setting active_provider in auth.json. _model_section_has_credentials() checks get_active_provider() first; with active_provider unset and no api_key_env_vars configured for oauth_external providers, the setup wizard reported "No inference provider configured" even after a successful OAuth login. Use _save_xai_oauth_tokens() — the canonical path already called from the hermes model xAI login flow — which writes providers["xai-oauth"]["tokens"] (setting active_provider) and lets _seed_from_singletons seed the pool with a "loopback_pkce" entry on the next load_pool() call. Mirrors the fix applied to openai-codex in NousResearch#37517.
xyshanren
pushed a commit
to xyshanren/hermes-agent-cn
that referenced
this pull request
Jun 25, 2026
hermes auth add google-gemini-cli called pool.add_entry() but never wrote to providers["google-gemini-cli"] or set active_provider in auth.json. _model_section_has_credentials() checks get_active_provider() first; with active_provider unset and no api_key_env_vars configured for oauth_external providers, the setup wizard reported "No inference provider configured" even after a successful OAuth login. Add _mark_google_gemini_cli_active() in auth.py: writes a minimal provider state entry (email for display only) and calls _save_provider_state() to set active_provider. The function deliberately does not copy access_token or refresh_token — those are managed by agent.google_oauth in the Google credential file and must not be duplicated in auth.json where they would become stale. pool.add_entry() is retained so "hermes auth list" continues to show the entry. Runtime credential resolution continues to use agent.google_oauth directly. Mirrors the fix applied to openai-codex (NousResearch#37517) and xai-oauth (NousResearch#37576).
waefrebeorn
pushed a commit
to waefrebeorn/slermes
that referenced
this pull request
Jul 2, 2026
* fix(desktop): codex OAuth onboarding now resolves on fresh install 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. * fix(auth): align Codex OAuth persistence paths Ensure desktop and CLI Codex OAuth logins both write the canonical provider state so fresh installs resolve a usable runtime provider. --------- Co-authored-by: teknium1 <127238744+teknium1@users.noreply.github.com>
waefrebeorn
pushed a commit
to waefrebeorn/slermes
that referenced
this pull request
Jul 2, 2026
hermes auth add google-gemini-cli called pool.add_entry() but never wrote to providers["google-gemini-cli"] or set active_provider in auth.json. _model_section_has_credentials() checks get_active_provider() first; with active_provider unset and no api_key_env_vars configured for oauth_external providers, the setup wizard reported "No inference provider configured" even after a successful OAuth login. Add _mark_google_gemini_cli_active() in auth.py: writes a minimal provider state entry (email for display only) and calls _save_provider_state() to set active_provider. The function deliberately does not copy access_token or refresh_token — those are managed by agent.google_oauth in the Google credential file and must not be duplicated in auth.json where they would become stale. pool.add_entry() is retained so "hermes auth list" continues to show the entry. Runtime credential resolution continues to use agent.google_oauth directly. Mirrors the fix applied to openai-codex (NousResearch#37517) and xai-oauth (NousResearch#37576).
waefrebeorn
pushed a commit
to waefrebeorn/slermes
that referenced
this pull request
Jul 2, 2026
…provider hermes auth add xai-oauth called pool.add_entry() directly, writing only the credential-pool entry (source "manual:xai_pkce") without touching providers["xai-oauth"] or setting active_provider in auth.json. _model_section_has_credentials() checks get_active_provider() first; with active_provider unset and no api_key_env_vars configured for oauth_external providers, the setup wizard reported "No inference provider configured" even after a successful OAuth login. Use _save_xai_oauth_tokens() — the canonical path already called from the hermes model xAI login flow — which writes providers["xai-oauth"]["tokens"] (setting active_provider) and lets _seed_from_singletons seed the pool with a "loopback_pkce" entry on the next load_pool() call. Mirrors the fix applied to openai-codex in NousResearch#37517.
waefrebeorn
pushed a commit
to waefrebeorn/slermes
that referenced
this pull request
Jul 2, 2026
hermes auth add qwen-oauth called pool.add_entry() but never wrote to providers["qwen-oauth"] or set active_provider in auth.json. _model_section_has_credentials() checks get_active_provider() first; with active_provider unset and no api_key_env_vars configured for oauth_external providers, the setup wizard reported "No inference provider configured" even after a successful Qwen CLI OAuth login. Add _mark_qwen_oauth_active() in auth.py: writes a minimal provider state entry (base_url for display only) and calls _save_provider_state() to set active_provider. The function deliberately does not copy the api_key — that lives in the Qwen CLI credential file managed by _save_qwen_cli_tokens / resolve_qwen_runtime_credentials and must not be duplicated in auth.json where it would become stale. pool.add_entry() is retained so "hermes auth list" continues to show the entry. Runtime credential resolution continues to use resolve_qwen_runtime_credentials. Mirrors the fix applied to openai-codex (NousResearch#37517) and xai-oauth (NousResearch#37576).
santhreal
pushed a commit
to santhreal/hermes-agent
that referenced
this pull request
Jul 13, 2026
* fix(desktop): codex OAuth onboarding now resolves on fresh install 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. * fix(auth): align Codex OAuth persistence paths Ensure desktop and CLI Codex OAuth logins both write the canonical provider state so fresh installs resolve a usable runtime provider. --------- Co-authored-by: teknium1 <127238744+teknium1@users.noreply.github.com>
santhreal
pushed a commit
to santhreal/hermes-agent
that referenced
this pull request
Jul 13, 2026
hermes auth add google-gemini-cli called pool.add_entry() but never wrote to providers["google-gemini-cli"] or set active_provider in auth.json. _model_section_has_credentials() checks get_active_provider() first; with active_provider unset and no api_key_env_vars configured for oauth_external providers, the setup wizard reported "No inference provider configured" even after a successful OAuth login. Add _mark_google_gemini_cli_active() in auth.py: writes a minimal provider state entry (email for display only) and calls _save_provider_state() to set active_provider. The function deliberately does not copy access_token or refresh_token — those are managed by agent.google_oauth in the Google credential file and must not be duplicated in auth.json where they would become stale. pool.add_entry() is retained so "hermes auth list" continues to show the entry. Runtime credential resolution continues to use agent.google_oauth directly. Mirrors the fix applied to openai-codex (NousResearch#37517) and xai-oauth (NousResearch#37576).
santhreal
pushed a commit
to santhreal/hermes-agent
that referenced
this pull request
Jul 13, 2026
…provider hermes auth add xai-oauth called pool.add_entry() directly, writing only the credential-pool entry (source "manual:xai_pkce") without touching providers["xai-oauth"] or setting active_provider in auth.json. _model_section_has_credentials() checks get_active_provider() first; with active_provider unset and no api_key_env_vars configured for oauth_external providers, the setup wizard reported "No inference provider configured" even after a successful OAuth login. Use _save_xai_oauth_tokens() — the canonical path already called from the hermes model xAI login flow — which writes providers["xai-oauth"]["tokens"] (setting active_provider) and lets _seed_from_singletons seed the pool with a "loopback_pkce" entry on the next load_pool() call. Mirrors the fix applied to openai-codex in NousResearch#37517.
santhreal
pushed a commit
to santhreal/hermes-agent
that referenced
this pull request
Jul 13, 2026
hermes auth add qwen-oauth called pool.add_entry() but never wrote to providers["qwen-oauth"] or set active_provider in auth.json. _model_section_has_credentials() checks get_active_provider() first; with active_provider unset and no api_key_env_vars configured for oauth_external providers, the setup wizard reported "No inference provider configured" even after a successful Qwen CLI OAuth login. Add _mark_qwen_oauth_active() in auth.py: writes a minimal provider state entry (base_url for display only) and calls _save_provider_state() to set active_provider. The function deliberately does not copy the api_key — that lives in the Qwen CLI credential file managed by _save_qwen_cli_tokens / resolve_qwen_runtime_credentials and must not be duplicated in auth.json where it would become stale. pool.add_entry() is retained so "hermes auth list" continues to show the entry. Runtime credential resolution continues to use resolve_qwen_runtime_credentials. Mirrors the fix applied to openai-codex (NousResearch#37517) and xai-oauth (NousResearch#37576).
donbowman
pushed a commit
to donbowman/hermes-agent
that referenced
this pull request
Jul 13, 2026
* fix(desktop): codex OAuth onboarding now resolves on fresh install 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. * fix(auth): align Codex OAuth persistence paths Ensure desktop and CLI Codex OAuth logins both write the canonical provider state so fresh installs resolve a usable runtime provider. --------- Co-authored-by: teknium1 <127238744+teknium1@users.noreply.github.com>
donbowman
pushed a commit
to donbowman/hermes-agent
that referenced
this pull request
Jul 13, 2026
hermes auth add google-gemini-cli called pool.add_entry() but never wrote to providers["google-gemini-cli"] or set active_provider in auth.json. _model_section_has_credentials() checks get_active_provider() first; with active_provider unset and no api_key_env_vars configured for oauth_external providers, the setup wizard reported "No inference provider configured" even after a successful OAuth login. Add _mark_google_gemini_cli_active() in auth.py: writes a minimal provider state entry (email for display only) and calls _save_provider_state() to set active_provider. The function deliberately does not copy access_token or refresh_token — those are managed by agent.google_oauth in the Google credential file and must not be duplicated in auth.json where they would become stale. pool.add_entry() is retained so "hermes auth list" continues to show the entry. Runtime credential resolution continues to use agent.google_oauth directly. Mirrors the fix applied to openai-codex (NousResearch#37517) and xai-oauth (NousResearch#37576).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Supersedes #37506.
Closes #37506.
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 onlycredential_pool.openai-codex. It never setactive_provider. On a fresh install (no~/.hermes, no env keys), onboarding immediately runssetup.runtime_check->resolve_runtime_provider("auto"), which detects OAuth providers throughactive_provider, so it fell through and raised"No inference provider configured". Meanwhilesetup.statuscould see configured credentials, producing the disagreement banner: "Connected, but Hermes still cannot resolve a usable provider."Changes
hermes_cli/web_server.py_codex_full_login_worker: persists via canonical_save_codex_tokens()instead of a bare pool write.hermes_cli/auth_commands.pyhermes auth add openai-codex: now uses the same canonical Codex token store, so CLI and desktop both writeproviders.openai-codex, setactive_provider, and seed the canonical pool entry.agent/credential_pool.py: preserves a user-supplied Codex label when seeding the canonicaldevice_codeentry from singleton auth state.resolve_runtime_provider()on a freshHERMES_HOME, plus the CLI auth-add persistence contract.Validation
Fresh empty
HERMES_HOME, all provider env vars unset:active_providerafter Codex OAuthNoneopenai-codexsetup.runtime_checkopenai-codexhermes auth add openai-codexTest plan
scripts/run_tests.sh tests/hermes_cli/test_auth_commands.py tests/hermes_cli/test_auth_codex_provider.py tests/hermes_cli/test_web_oauth_dispatch.py tests/hermes_cli/test_runtime_provider_resolution.py tests/test_tui_gateway_server.pyInfographic