Issue Station
Sign In
Tools hereToolbox

hermes - 💡(How to fix) Fix Copilot `/model` picker should fall back to OAuth access_token from auth.json [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
NousResearch/hermes-agent#16708•Fetched 2026-04-28 06:51:23
View on GitHub
Comments
0
Participants
1
Timeline
4
Reactions
0
Author
akamel001akamel001
Participants
akamel001akamel001
Timeline (top)
labeled ×4

The /model picker for the copilot provider only shows a small hardcoded fallback list when the live model fetch fails. The fetch fails silently for users whose only Copilot credential is an OAuth access_token in auth.json (i.e. the device-code flow that hermes auth add copilot itself produces), because _resolve_copilot_catalog_api_key() only consults the COPILOT_GITHUB_TOKEN / GH_TOKEN / GITHUB_TOKEN environment variables.

Net effect: the picker hides current Copilot models (e.g. claude-opus-4.7, claude-sonnet-4.6, gpt-5.5, grok-code-fast-1) from users who authenticated through Hermes's own supported flow. Users either don't know those models exist, or have to type the model id directly via /model <id>.

Root Cause

hermes_cli/models.py::_resolve_copilot_catalog_api_key() (around line 1942) calls resolve_api_key_provider_credentials("copilot"), which only inspects the env vars listed in COPILOT_ENV_VARS. It never falls back to the OAuth access_token that auth.json already holds — the same token the rest of Hermes uses to talk to Copilot.

The Codex catalog resolver (same file, around line 1791) already has the right pattern: env-var first, then resolve_codex_runtime_credentials() which reads auth.json.

Fix Action

Fix / Workaround

About 5 lines, no new dependencies, behavior is strictly additive (env still wins). I'd rather just file the report than maintain a PR — happy to expand on the patch sketch if useful.

Workaround for other users hitting this

RAW_BUFFERClick to expand / collapse

Summary

The /model picker for the copilot provider only shows a small hardcoded fallback list when the live model fetch fails. The fetch fails silently for users whose only Copilot credential is an OAuth access_token in auth.json (i.e. the device-code flow that hermes auth add copilot itself produces), because _resolve_copilot_catalog_api_key() only consults the COPILOT_GITHUB_TOKEN / GH_TOKEN / GITHUB_TOKEN environment variables.

Net effect: the picker hides current Copilot models (e.g. claude-opus-4.7, claude-sonnet-4.6, gpt-5.5, grok-code-fast-1) from users who authenticated through Hermes's own supported flow. Users either don't know those models exist, or have to type the model id directly via /model <id>.

Reproduce

  1. Fresh Hermes install, no gh CLI configured, no COPILOT_GITHUB_TOKEN set.
  2. hermes auth add copilot → device-code flow → auth.json ends up with credential_pool.copilot[0].access_token (OAuth gho_…).
  3. Run Hermes, type /model and choose copilot.
  4. The picker shows only the hardcoded fallback list from hermes_cli/models.py (around lines 157–172), missing all current models.
  5. /model claude-opus-4.7 works fine — the model is available, the picker just doesn't list it.

Root cause

hermes_cli/models.py::_resolve_copilot_catalog_api_key() (around line 1942) calls resolve_api_key_provider_credentials("copilot"), which only inspects the env vars listed in COPILOT_ENV_VARS. It never falls back to the OAuth access_token that auth.json already holds — the same token the rest of Hermes uses to talk to Copilot.

The Codex catalog resolver (same file, around line 1791) already has the right pattern: env-var first, then resolve_codex_runtime_credentials() which reads auth.json.

Proposed fix

Mirror the Codex pattern in _resolve_copilot_catalog_api_key():

  1. Env-var lookup (current behavior).
  2. On miss, load auth.json via the existing load_auth_data() helper, walk credential_pool.copilot[], and return the first entry's access_token.

About 5 lines, no new dependencies, behavior is strictly additive (env still wins). I'd rather just file the report than maintain a PR — happy to expand on the patch sketch if useful.

Workaround for other users hitting this

Type the model id directly: /model claude-opus-4.7, /model gpt-5.5, etc.

Environment

  • Hermes Agent (current main)
  • Provider: copilot, auth via hermes auth add copilot device-code flow
  • Linux (Ubuntu)

extent analysis

TL;DR

The issue can be fixed by modifying the _resolve_copilot_catalog_api_key() function to fall back to the OAuth access_token in auth.json when environment variables are not set.

Guidance

  • The root cause is that the _resolve_copilot_catalog_api_key() function only checks environment variables and does not fall back to the OAuth access_token in auth.json.
  • To verify the issue, run Hermes with the copilot provider and check if the model picker shows only the hardcoded fallback list.
  • To mitigate the issue, users can type the model id directly using the /model <id> command.
  • The proposed fix involves modifying the _resolve_copilot_catalog_api_key() function to load auth.json and return the first access_token entry in credential_pool.copilot[] when environment variables are not set.

Example

def _resolve_copilot_catalog_api_key():
    # Current behavior: env-var lookup
    api_key = resolve_api_key_provider_credentials("copilot")
    if api_key:
        return api_key
    
    # Proposed fix: fall back to auth.json
    auth_data = load_auth_data()
    for credential in auth_data.credential_pool.copilot:
        if credential.access_token:
            return credential.access_token
    return None

Notes

The proposed fix assumes that the load_auth_data() function is already implemented and returns the authentication data from auth.json. The fix also assumes that the credential_pool.copilot list contains at least one entry with an access_token.

Recommendation

Apply the proposed fix to the _resolve_copilot_catalog_api_key() function to allow the model picker to show current Copilot models for users who authenticated through the device-code flow.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#pipeline error#runtime error#dependency conflict#environment variable

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

hermes - 💡(How to fix) Fix Copilot `/model` picker should fall back to OAuth access_token from auth.json [1 participants]