CLI masks structured OpenAI-compatible 403 error message as authentication failure #5436

Description

When a custom OpenAI-compatible provider returns HTTP 403 with a structured error body, GitHub Copilot CLI reports a generic authentication/provider failure instead of displaying the response's error.message and error.code.This is misleading for valid 403 responses that are not authentication failures, such as policy or quota decisions. VS Code's Copilot client renders the same response clearly.

Environment- GitHub Copilot CLI: 1.0.104- OS: Windows- Provider compatibility: OpenAI-compatible HTTP endpoint

Minimal synthetic response

HTTP/1.1 403 ForbiddenContent-Type: application/jsonx-ms-error-code: GroupMonthlyTokenQuota
ExceededRetry-After: 86400
{  
"error": {  
"code": "GroupMonthlyTokenQuotaExceeded",  
"type": "insufficient_quota",  
"message": "The monthly token allowance for this group has been exceeded for the current calendar month."  
}}

Actual behavior

Copilot CLI displays a generic provider authentication/API-key failure, such as:

textAuthentication failed with provider ... Check your COPILOT_PROVIDER_API_KEY, ...

It does not surface the structured error.message or error.code from the 403 response.

Suggested handling

Distinguish policy/quota 403 responses from authentication 403 responses by inspecting the structured error.code and error.type, and render the server-provided message. The Retry-After and standard error-code headers can remain available as supplemental context.

Affected version

1.0.104

Steps to reproduce the behavior

1. Configure Copilot CLI to use an OpenAI-compatible provider endpoint.
2. Make the endpoint return the response above from a model request.
3. Observe the Copilot CLI message.

Expected behavior

For a structured OpenAI-compatible 403 response, Copilot CLI should prefer the server-provided error.message and display the error.code, unless the error code/type actually indicates an authentication failure.
Actual authentication errors such as invalid_api_key should retain the existing authentication guidance.

Additional context

The HTTP status remains intentionally 403; treating this as 429 would be incorrect and could trigger retry loops. A user-agent-specific server workaround would be brittle, so this appears to require client-side presentation logic.