[Bug]: @ai-sdk/openai headers not forwarded to HTTP requests when using Responses API with APIM #18089

Summary

OpenCode's bundled @ai-sdk/openai implementation fails to forward constructor-level headers to HTTP requests when using the OpenAI Responses API, causing 401 "missing" errors with Azure API Management (APIM) and other services that require custom authentication headers.

Problem Details

Text-level substitution works correctly - environment variables like {env:AZURE_APIM_KEY} are properly resolved in configuration.

However, when using GPT-5+ models (which trigger shouldUseCopilotResponsesApi), the headers from createOpenAI({ headers: {...} }) constructor are not included in the actual HTTP requests to the /responses endpoint.

Evidence

1. Azure APIM reports "missing" (not "invalid") - indicates header never arrives
2. Text substitution confirmed working - {env:AZURE_APIM_KEY} resolves to real key
3. Only affects Responses API - Chat Completions API works fine with same config
4. Model-specific routing - GPT-4 works, GPT-5+ fails (due to API switching)

Root Cause Analysis

OpenCode has two different @ai-sdk/openai implementations:

1. Official @ai-sdk/openai (line 116 in BUNDLED_PROVIDERS) - works correctly
2. Custom GitHub Copilot implementation (line 131) - used for GPT-5+ models via Responses API

The issue is in the custom implementation path:

createOpenAI({ headers }) → 
shouldUseCopilotResponsesApi(modelID) → 
createGitHubCopilotOpenAICompatible() → 
OpenAIResponsesLanguageModel

The headers from the original createOpenAI({ headers }) constructor don't make it through this chain to the final HTTP requests.

Affected Code Locations

• packages/opencode/src/provider/provider.ts:55 - shouldUseCopilotResponsesApi routing logic
• packages/opencode/src/provider/provider.ts:190-199 - GitHub Copilot custom loader
• packages/opencode/src/provider/sdk/copilot/copilot-provider.ts:78-83 - Custom provider creation
• packages/opencode/src/provider/sdk/copilot/responses/openai-responses-language-model.ts:409,782 - Header forwarding logic (correct but receives no headers)

Reproduction

Working Configuration (GPT-4)

{
  "provider": {
    "openai": {
      "options": {
        "apiKey": "{env:OPENAI_API_KEY}",
        "baseURL": "https://my-apim.azure-api.net/openai",
        "headers": {
          "Ocp-Apim-Subscription-Key": "{env:AZURE_APIM_KEY}"
        }
      }
    }
  }
}

Broken Configuration (GPT-5+)

Same config, different model triggers custom Responses API implementation and headers are lost.

Expected Behavior

Headers from createOpenAI({ headers }) constructor should be forwarded to all HTTP requests regardless of whether the model uses Chat Completions API or Responses API.

Actual Behavior

• GPT-4 (Chat API): Headers forwarded ✅
• GPT-5+ (Responses API): Headers missing ❌

Impact

• Azure APIM integration broken for GPT-5+ models
• Enterprise proxies requiring custom auth headers fail
• Inconsistent behavior between model families
• Silent failures - no error indicating headers were dropped

Workaround Approaches Tried

1. Provider-level headers (options.headers) - ❌ Not forwarded
2. Model-level headers (models.{model}.headers) - ❌ Not forwarded
3. Custom User-Agent - ❌ Not forwarded

Related Issues

• Are custom provider headers from config expected to work in v1.2.x? #15306 - Custom provider headers from config not working (similar but broader)
• bug(copilot): gpt-5.x-mini variants incorrectly routed to Responses API #15823 - GPT-5.x-mini routing issues (same routing logic involved)
• fix: provider headers from config not applied to fetch requests #11788 - Previous attempt to fix provider headers (referenced in Are custom provider headers from config expected to work in v1.2.x? #15306)

Environment

• OpenCode version: v1.2.x
• Provider: @ai-sdk/openai
• Models affected: gpt-5, gpt-5.1, gpt-5.2, etc. (any model triggering Responses API)
• Models working: gpt-4, gpt-4-turbo, etc. (Chat Completions API)

Fix Direction

The headers need to be properly passed through the custom provider chain:
createOpenAI options → GitHub Copilot provider → OpenAI Responses model → HTTP requests

Likely requires updating the header passing logic in the custom loader or provider creation chain.