Bug Description

Hermes is unstable with provider: copilot in normal agent/tool flows.

On my machine, the same GitHub/Copilot auth works when calling the Copilot API directly, but Hermes fails with:

• Non-retryable client error: Access to this endpoint is forbidden.
• HTTP 403

This appears to be specific to Hermes agent payloads / routing rather than a basic auth failure.

Environment

• Hermes Agent: v0.9.0 (2026.4.13)
• OpenAI SDK: 2.30.0
• Copilot CLI: 1.0.28
• OS: Linux
• Provider: copilot
• Models tested: gpt-5-mini, gpt-4.1

Initial config during reproduction:

model:
  default: gpt-5-mini
  provider: copilot
  base_url: https://api.githubcopilot.com
  api_mode: chat_completions

During investigation I also tested api_mode: codex_responses; the issue still remained, just with a different failing path.

No proxy / VPN env vars were set during testing.

What I Verified

1. Copilot auth itself works

Using the same gh auth token that Hermes uses, these direct calls succeeded:

• GET https://api.githubcopilot.com/models -> HTTP 200
• POST https://api.githubcopilot.com/chat/completions with a minimal gpt-5-mini payload -> HTTP 200

So this does not look like a generic "Copilot is unavailable" or "token invalid" problem.

2. Hermes fails on real agent payloads

Hermes request dumps showed failures like:

• POST https://api.githubcopilot.com/chat/completions with gpt-5-mini + Hermes tool payload -> HTTP 403
• after switching gpt-5-mini to codex_responses, POST https://api.githubcopilot.com/responses with Hermes payload -> still HTTP 403
• POST https://api.githubcopilot.com/chat/completions with gpt-4.1 + Hermes tool payload -> HTTP 403

Representative Hermes errors:

Non-retryable client error: Access to this endpoint is forbidden.

3. The problem is tool-flow specific, not a total provider outage

With Copilot through Hermes:

• gpt-4.1 simple non-tool prompt (Reply with exactly: ok) -> worked
• gpt-4.1 tool-using prompt -> failed with HTTP 403
• gpt-5-mini tool-using prompt -> failed with HTTP 403

So the bug seems broader than one model: it affects Copilot-backed Hermes agent/tool flows.

Reproduction

Direct API sanity check (works)

Using the same GitHub auth token Hermes resolves from gh auth token:

curl -sS https://api.githubcopilot.com/models \
  -H "Authorization: Bearer <gh auth token>" \
  -H 'Editor-Version: vscode/1.104.1' \
  -H 'User-Agent: HermesAgent/1.0' \
  -H 'Copilot-Integration-Id: vscode-chat' \
  -H 'Openai-Intent: conversation-edits'

and

curl -sS https://api.githubcopilot.com/chat/completions \
  -H "Authorization: Bearer <gh auth token>" \
  -H 'Content-Type: application/json' \
  -H 'Editor-Version: vscode/1.104.1' \
  -H 'User-Agent: HermesAgent/1.0' \
  -H 'Copilot-Integration-Id: vscode-chat' \
  -H 'Openai-Intent: conversation-edits' \
  -H 'x-initiator: user' \
  -d '{"model":"gpt-5-mini","messages":[{"role":"user","content":"Reply with exactly: ok"}],"stream":false}'

returns 200.

Hermes repros (fail)

hermes chat --provider copilot -m gpt-5-mini -Q -q 'List the files in the current working directory. Use tools and answer briefly.'

fails with HTTP 403.

hermes chat --provider copilot -m gpt-4.1 -Q -q 'List the files in the current working directory. Use tools and answer briefly.'

also fails with HTTP 403.

Non-tool control case (works)

hermes chat --provider copilot -m gpt-4.1 -Q -q 'Reply with exactly: ok'

This works.

Additional Investigation / Findings

1. With the original chat_completions routing, Hermes could fail on tool-heavy gpt-5-mini payloads even though minimal direct chat/completions requests succeeded.
2. I then tested forcing gpt-5-mini to codex_responses locally because the agent/tool path looked incompatible with Copilot chat-completions.
3. That changed the failing endpoint from /chat/completions to /responses, but some Hermes first-turn payloads still returned 403.
4. I manually replayed Hermes request bodies outside Hermes:
   • some replayed responses payloads succeeded
   • some replayed responses payloads still returned 403
5. gpt-4.1 also fails in Hermes tool flows, which suggests the bug is not exclusive to GPT-5-mini.
6. The behavior appears payload-shape-sensitive rather than a simple auth rejection.

This makes me suspect one of:

• Hermes is building Copilot agent/tool payloads that Copilot rejects
• Hermes is using the wrong API mode for some Copilot subpaths
• Hermes is sending a payload shape / tool schema combination that Copilot forbids
• there is a first-turn / tool-enabled / reasoning-enabled edge case in Hermes' Copilot integration

Expected Behavior

If Copilot auth is valid and direct API calls work, Hermes should be able to use Copilot models reliably for normal agent/tool turns instead of failing with 403 forbidden.

Actual Behavior

Direct Copilot API checks succeed, but Hermes agent flows with provider: copilot fail with 403 forbidden in tool-using turns (confirmed at least for gpt-5-mini and gpt-4.1).

Related Context

This seems adjacent to existing Copilot/Hermes routing issues like:

• [Bug]: Copilot GPT-5.4 intermittently routes to OpenRouter /chat/completions and fails with unsupported_api_for_model #3388 (Copilot GPT-5.x routing drift)
• fix: exchange GitHub token for Copilot session token before API calls #7730 (Copilot token/session handling)

but this report is specifically about Copilot-backed Hermes agent/tool flows failing with 403 even when direct Copilot API access is confirmed working.