Copilot OAuth client_id prevents copilot_internal token exchange; live model catalog requires workaround

[wyhgoodjob]

Bug

hermes_cli/copilot_auth.py uses an OAuth client_id that cannot access the Copilot API, so any user who logs in via hermes auth add copilot (or the existing device-code flow) ends up with a token that gets HTTP 404 from https://api.github.com/copilot_internal/v2/token, even when their GitHub account has an active Copilot subscription.

Root cause

# hermes_cli/copilot_auth.py
COPILOT_OAUTH_CLIENT_ID = "Ov23li...Qebz"   # GitHub App client id

This is a GitHub App client id (Ov23li... prefix). Tokens minted by it are not authorized for copilot_internal/v2/token, regardless of the user's Copilot plan.

The official VS Code / Copilot CLI / opencode flow uses the legacy OAuth App id:

Iv1.b507a08c87ecfe98

A token from this client_id (with read:user scope) successfully exchanges at copilot_internal/v2/token and lists the full live model catalog (including gpt-5.5, claude-opus-4.5, etc.) — confirmed by manual reproduction.

Reproduction

1. hermes auth add copilot (or call copilot_device_code_login() directly)
2. Authorize as a user with an active Copilot subscription (Individual/Business)
3. Hermes saves token to COPILOT_GITHUB_TOKEN
4. Any code path calling exchange_copilot_token() → HTTP 404 Not Found
5. fetch_github_model_catalog() returns None, so hermes model falls back to the hardcoded curated list — which is missing gpt-5.5 and other newer models.

Symptoms users see

• /model gpt-5.5 not in the list even though it works in VS Code on the same account
• hermes model shows a stale subset of the Copilot catalog
• Token exchange silently fails; users assume their account doesn't have access

Fix

Change COPILOT_OAUTH_CLIENT_ID to Iv1.b507a08c87ecfe98. After this, the live /models catalog populates correctly and dynamic model discovery works as designed.

Side issues spotted while debugging

• hermes auth add copilot --type oauth returns not implemented for auth type oauth yet. — the device-code flow is only reachable via setup wizard / internal call, not via the documented auth add path.
• After copilot_device_code_login() returns a token, hermes_cli/main.py (line ~3528) calls save_env_value("COPILOT_GITHUB_TOKEN", token), but save_env_value is no longer importable from hermes_cli.main (got ImportError on current main branch). Token is fetched but never persisted.

Environment

• Hermes Agent (current main)
• Linux (cachyos), Python 3.11
• Account: GitHub Individual Copilot subscription

[wyhgoodjob]

Update / clarification after further testing:

There are two separate issues here:

1. Selecting GPT-5.5 in Hermes may require provider qualification: . A bare can resolve to the OpenAI Codex provider and fail with "No Codex credentials stored". That routing/UX issue is separate from OAuth.

2. The OAuth/client_id issue described above is still reproducible: a token minted by Hermes' current Copilot device-code flow could not exchange at (404), while a token minted via VS Code Copilot's client_id () on the same GitHub account successfully exchanges and allows to return the live catalog, including .

So the original title/body overstated the user-facing symptom a bit: missing prefix can also explain a failure. The core bug being reported here is specifically the Copilot OAuth token exchange / live catalog discovery failure.

[wyhgoodjob]

Update / clarification after further testing:

There are two separate issues here:

1. Selecting GPT-5.5 in Hermes may require provider qualification: /model copilot/gpt-5.5. A bare /model gpt-5.5 can resolve to the OpenAI Codex provider and fail with "No Codex credentials stored". That routing/UX issue is separate from OAuth.

2. The OAuth/client_id issue described above is still reproducible in my test: a token minted by Hermes' current Copilot device-code flow could not exchange at copilot_internal/v2/token (404), while a token minted via VS Code Copilot's client_id (Iv1.b507a08c87ecfe98) on the same GitHub account successfully exchanges and allows api.githubcopilot.com/models to return the live catalog, including gpt-5.5.

So the original title/body overstated the user-facing symptom a bit: missing the copilot/ provider prefix can also explain a /model gpt-5.5 failure. The core bug being reported here is specifically the Copilot OAuth token exchange / live catalog discovery failure.

[alt-glitch]

Duplicate of #7731 — same root cause (wrong OAuth client_id in copilot_auth.py). Fix PR #15139 is already open with the VS Code client ID switch.

[luyao618]

Submitted PR #16562 to fix this. PTAL 🙏