[Setup]: Copilot provider resolves as custom at runtime and sends malformed Authorization header

[Yashwant00CR7]

GitHub Copilot provider appears to route through custom provider path, causing malformed Authorization header

Environment

• Hermes Agent: 0.16.0
• OS: Windows 10
• Provider: copilot
• Model: gpt-5.4-mini

Description

I'm unable to use GitHub Copilot models through Hermes despite having a valid GitHub token and a working Copilot endpoint.

Hermes consistently fails with:

HTTP 400: bad request: Authorization header is badly formatted

The strange part is that the runtime logs report:

Provider: custom
Endpoint: https://api.githubcopilot.com

even though my configuration explicitly specifies:

model:
  default: gpt-5.4-mini
  provider: copilot
  api_mode: chat_completions

(or codex_responses, tested both)

This makes me suspect that Hermes is routing the request through a custom/OpenAI-compatible code path instead of the native Copilot path.

---

Error Output

⚠️ API call failed (attempt 1/3): BadRequestError [HTTP 400]

🔌 Provider: custom
Model: gpt-5.4-mini
🌐 Endpoint: https://api.githubcopilot.com

Error:
HTTP 400: bad request: Authorization header is badly formatted

❌ Non-retryable error (HTTP 400)

---

What I Have Verified

Token is valid

GitHub accepts the token:

$token = "<token>"

curl.exe https://api.github.com/user `
  -H "Authorization: Bearer $token"

Returns my user profile successfully.

---

Hermes sees the Copilot credential

Auth store contains:

"copilot": [
  {
    "label": "COPILOT_GITHUB_TOKEN",
    "auth_type": "api_key",
    "source": "env:COPILOT_GITHUB_TOKEN",
    "base_url": "https://api.githubcopilot.com",
    "last_status": "ok"
  }
]

---

Config is set to Copilot

model:
  default: gpt-5.4-mini
  provider: copilot

---

Runtime contains Copilot-specific code

I found Copilot handling logic in:

hermes_cli/runtime_provider.py
hermes_cli/models.py
hermes_cli/auth.py
agent/auxiliary_client.py
run_agent.py

Example:

def _copilot_runtime_api_mode(model_cfg, api_key):

which suggests native Copilot support exists.

---

Suspicious Observation

Despite the configuration being:

provider: copilot

runtime errors always report:

Provider: custom

This appears inconsistent.

Could there be:

• provider normalization issue
• stale session/provider cache
• alias resolution bug
• fallback into custom provider path
• incorrect header construction for Copilot requests

---

Questions

1. Under what conditions would a configured copilot provider be reported as custom at runtime?

2. Is there a known path where Copilot requests are converted into generic OpenAI-compatible requests?

3. Which code path constructs the Authorization header for Copilot requests?

4. Are there additional caches/session files/provider registries that can override provider: copilot?

---

Additional Information

Search results show many references to Copilot handling:

api.githubcopilot.com

inside:

run_agent.py
agent_init.py
auxiliary_client.py
chat_completion_helpers.py
runtime_provider.py
models.py
auth.py

so the provider is clearly recognized by the codebase.

Any guidance on how to trace why runtime still resolves to custom would be appreciated.

Steps Taken

1. Configured Hermes to use GitHub Copilot:

model:
  default: gpt-5.4-mini
  provider: copilot
  api_mode: chat_completions

Also tested:

api_mode: codex_responses

2. Verified Hermes was reading the expected configuration:

hermes status

Output showed:

Model: {'default': 'gpt-5.4-mini', 'provider': 'copilot'}

3. Verified the Copilot credential was registered:

"copilot": [
  {
    "label": "COPILOT_GITHUB_TOKEN",
    "source": "env:COPILOT_GITHUB_TOKEN",
    "base_url": "https://api.githubcopilot.com",
    "last_status": "ok"
  }
]

4. Initially discovered that PowerShell was reading an old environment variable instead of the token stored in Hermes' .env.

Checked:

$env:COPILOT_GITHUB_TOKEN.Length

Corrected the token source and restarted Hermes.

5. Verified the token itself was valid by authenticating directly against GitHub:

$token="<redacted>"

curl.exe https://api.github.com/user `
  -H "Authorization: Bearer $token"

Received a successful response containing my GitHub account information.

6. Verified the endpoint was reachable:

https://api.githubcopilot.com

No connectivity issues were observed.

7. Removed previously configured custom providers from config.yaml to eliminate provider conflicts.

8. Restarted Hermes after every configuration change.

9. Searched configuration for Copilot-related settings:

Select-String `
  -Path C:\Users\yashw\AppData\Local\hermes\config.yaml `
  -Pattern "custom:|githubcopilot|copilot"

Confirmed the active configuration contained:

provider: copilot
base_url: https://api.githubcopilot.com

10. Searched the Hermes source tree for Copilot handling:

Get-ChildItem `
  C:\Users\yashw\AppData\Local\hermes\hermes-agent `
  -Recurse `
  -File |
Select-String "api.githubcopilot.com"

Found references in:

run_agent.py
agent_init.py
auxiliary_client.py
chat_completion_helpers.py
runtime_provider.py
models.py
auth.py

11. Inspected runtime provider logic:

Get-Content `
"C:\Users\yashw\AppData\Local\hermes\hermes-agent\hermes_cli\runtime_provider.py" |
Select-Object -Skip 190 -First 60

Confirmed Copilot-specific code exists, including:

def _copilot_runtime_api_mode(...)

12. Despite all of the above, every request still fails with:

HTTP 400: bad request: Authorization header is badly formatted

and the runtime log reports:

Provider: custom
Endpoint: https://api.githubcopilot.com

which appears inconsistent with the configured provider:

provider: copilot

Installation Method

PowerShell installer (Windows)

Operating System

Windows 11

Python Version

3.11.5

Hermes Version

2.1.0

Debug Report

Debug report uploaded:
  Report       https://paste.rs/QUA0v
  agent.log    https://paste.rs/o9thb
  gateway.log  https://paste.rs/s2ibj

Full Error Output

────────────────────────────────────────
⚠️  API call failed (attempt 1/3): BadRequestError [HTTP 400]
   🔌 Provider: custom  Model: gpt-5.4-mini
   🌐 Endpoint: https://api.githubcopilot.com
   📝 Error: HTTP 400: bad request: Authorization header is badly formatted
   📋 Details: bad request: Authorization header is badly formatted
   ⏱️  Elapsed: 1.67s  Context: 2 msgs, ~9,716 tokens
❌ Non-retryable error (HTTP 400): HTTP 400: bad request: Authorization header is badly formatted
❌ Non-retryable client error (HTTP 400). Aborting.
   🔌 Provider: custom  Model: gpt-5.4-mini
   🌐 Endpoint: https://api.githubcopilot.com
   💡 This type of error won't be fixed by retrying.
 ─  ⚕ Hermes  ──────────────────────────────────────────

What I've Already Tried

-Ran Hermes Update
-Checked all the config files
-No traces of custom provider overriding copilot found

[teknium1]

Thanks for the detailed report. This is now implemented on main; this is an automated hermes-sweeper review.

• 0d93eeff7 (fix(aux): preserve provider identity for resolved endpoints) changed agent/auxiliary_client.py so a recognized provider paired with a resolved base_url keeps its provider identity instead of being flattened to custom.
• Current hermes_cli/runtime_provider.py:1466-1510 returns provider="copilot" for the configured Copilot API-key path, including its resolved endpoint and API mode.
• Current agent/agent_init.py:955-958 applies copilot_default_headers() for githubcopilot.com endpoints.
• Current regression coverage in tests/agent/test_auxiliary_client.py:125-154 verifies the provider-preservation versus custom-endpoint boundary.

The linked PR #45330 targets the same original collapse; the merged implementation is broader because it preserves all catalog-recognized provider identities while retaining the generic custom fallback.