IntelliJ: duplicate authorization header sent for OpenAI models, causing authentication failure

[tim-sh]

Before submitting your bug report

• I've tried using the "Ask AI" feature on the Continue docs site to see if the docs have an answer
• I believe this is a bug. I'll try to join the Continue Discord for questions
• I'm not able to find an open issue that reports the same bug
• I've seen the troubleshooting guide on the Continue Docs

Relevant environment info

- OS: Linux
- Continue version: 1.0.30
- IDE version: IntelliJ IDEA Community 2025.1
- Model: o4-mini (self-hosted)
- config:
models:
  - name: my o4-mini
    provider: openai
    model: o4-mini
    apiBase: https://acme.com/some/path
    requestOptions:
      headers:
        Authorization: Bearer eyYo…
        my-hdr: bar

Description

When trying to use a self-hosted openai model, the server error response indicates that Continue doesn't send the Authorization header as it should.
This does not happen with a self-hosted gemini model, where our server expects the same token and successfully receives it (indicated by absence of error).

Investigating with a proxy, I see this duplication in the raw headers: ['authorization', 'Bearer', 'authorization', 'Bearer [myToken]']. Now the first value, 'Bearer' (token missing), seems to win – at least that's what Node.js' http module makes it into.

Though I can't see the headers received by our server when disabling the proxy, the finding suggests that Continue sends a duplicate Authorization header in my case.

The token has this structure, I would say:
[a-zA-Z0-9]{250}\.[a-zA-Z0-9]{6590}\.[a-zA-Z0-9_-]{342}

[atineoSE]

I can see the same on VS Code with continue version 1.0.21. My openAI compatible server fails authorization because the empty header takes precedence.

[tingwai]

Hi, thank you for the detailed ticket! Taking an initial look at this it seems to be a bug, I'm not very familiar with this portion of the code but I'll create a ticket and surface it to the team!

[visadb]

I'm also having this problem. My case involves using vLLM with basic auth but the problem is essentially the same: no apiKey configured but the provider sends an empty Authorization: Bearer header that interferes with my custom Authorization: Basic <mycredentials> header. I posted a fix proposal as PR #7803