Unable to get Basic authorization headers working for OpenAI

[treydock]

Describe the bug

💡 Before filing, please check common issues:
https://block.github.io/goose/docs/troubleshooting

📦 To help us debug faster, attach your diagnostics zip if possible.
👉 How to capture it: https://block.github.io/goose/docs/troubleshooting/diagnostics-and-reporting/

A clear and concise description of what the bug is.

---

To Reproduce
Steps to reproduce the behavior:

API calls work with curl:

$ curl -H "Authorization: Basic OMIT" https://LOCAL_DOMAIN/v1/models
{"object":"list","data":[{"id":"qwen3-coder:30b","object":"model","created":1772129681,"owned_by":"library"},{"id":"qwen2.5-coder:7b","object":"model","created":1771525563,"owned_by":"library"},{"id":"codellama:7b","object":"model","created":1771523458,"owned_by":"library"}]}

Attempt same with goose and get 401:

export OPENAI_CUSTOM_HEADERS="authorization=Basic OMIT"
$ grep OPENAI ~/.config/goose/config.yaml
OPENAI_HOST: https://LOCAL_DOMAIN
OPENAI_BASE_PATH: v1/chat/completions
OPENAI_TIMEOUT: '600'

$ GOOSE_DISABLE_KEYRING=1 goose run --provider openai --model qwen3-coder:30b -t "testing"

    __( O)>  ● new session · openai qwen3-coder:30b
   \____)    20260303_18 · /Users/tdockendorf/git/osc-helm-charts
     L L     goose is ready
Ran into this error: Authentication error: Authentication failed. Status: 401 Unauthorized. Response: .

Please retry if you think this is a transient or recoverable error.

I have tried several permutations of OPENAI_CUSTOM_HEADERS with quotes around the value, etc and nothing seems to work.

---

Expected behavior

I would expect that the OpenAI custom headers could support basic auth.

---

Screenshots
If applicable, add screenshots to help explain your problem.

---

Please provide the following information

• OS & Arch: OS X 14.8.3
• Interface: CLI
• Version: 1.26.1
• Extensions enabled: Just the defaults, this is a fresh install
• Provider & Model: OpenAI with local Ollama using basic Auth. Model is qwen3-coder:30b

---

Additional context

I get the same 401 when I go through goose configure. I've been trying to debug with goose run as that seems faster than going through all the configure prompts.

[treydock]

I tried installing Ollama via Open WebUI and using Bearer tokens, same issue. Attempts look like this in secrets.yaml:

OPENAI_CUSTOM_HEADERS: "Authorization=Bearer OMIT"

I tried wrapping the part after = with single quotes, still get 401s.

I see the API calls making it to Open WebUI but failing:

2026-03-03 15:36:54.630 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - OMIT:0 - "POST /api/v1/chat/completions HTTP/1.1" 401

I saw similar logs when using Basic auth via NGINX Ingress for Ollama. The Bearer token works with curl:

$ curl -H "Authorization: Bearer OMIT" https://LOCAL_DOMAIN/api/v1/models
<JSON output>

[fresh3nough]

fully resolvable via config (no code change needed) --> Manually edit ~/.config/goose/custom_providers/ JSON or use goose configure and set headers: {"Authorization": "Basic OMIT"}. This bypasses forced Bearer auth.

[treydock]

I've decided to focus on using Bearer tokens as that's more like our production deployment rather than Basic auth. I got things working with OpenAI provider and using Open WebUI:

$ grep OPENAI ~/.config/goose/config.yaml
OPENAI_HOST: https://LOCAL_DOMAIN/api/
OPENAI_BASE_PATH: v1/chat/completions
OPENAI_TIMEOUT: '600'
$ grep OPENAI ~/.config/goose/secrets.yaml
OPENAI_API_KEY: OMIT

I am seeing some 400 error log entries on Open WebUI that I'm not sure what those are about.

2026-03-04 14:23:11.995 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 131.187.45.7:0 - "POST /api/v1/chat/completions HTTP/1.1" 400
2026-03-04 14:23:13.042 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 131.187.45.7:0 - "POST /api/v1/chat/completions HTTP/1.1" 200

I'll start a session and see no errors except for some 400s in the Open WebUI logs.

I do see these errors in goose logs:

$ cat ~/.local/state/goose/logs/cli/2026-03-04/20260304_092732.log | grep 400
{"timestamp":"2026-03-04T14:27:34.668300Z","level":"WARN","fields":{"message":"Provider request failed with status: 400 Bad Request. Payload: Some(Object {\"detail\": String(\"Model not found\")}). Returning error: RequestFailed(\"Bad request (400): {\\\"detail\\\":\\\"Model not found\\\"}\")"},"target":"goose::providers::openai_compatible"}
{"timestamp":"2026-03-04T14:27:34.668381Z","level":"WARN","fields":{"message":"Request failed, retrying (1/3): RequestFailed(\"Bad request (400): {\\\"detail\\\":\\\"Model not found\\\"}\")"},"target":"goose::providers::retry"}
{"timestamp":"2026-03-04T14:27:35.741226Z","level":"WARN","fields":{"message":"Provider request failed with status: 400 Bad Request. Payload: Some(Object {\"detail\": String(\"Model not found\")}). Returning error: RequestFailed(\"Bad request (400): {\\\"detail\\\":\\\"Model not found\\\"}\")"},"target":"goose::providers::openai_compatible"}
{"timestamp":"2026-03-04T14:27:35.741314Z","level":"WARN","fields":{"message":"Request failed, retrying (2/3): RequestFailed(\"Bad request (400): {\\\"detail\\\":\\\"Model not found\\\"}\")"},"target":"goose::providers::retry"}
{"timestamp":"2026-03-04T14:27:37.442504Z","level":"WARN","fields":{"message":"Provider request failed with status: 400 Bad Request. Payload: Some(Object {\"detail\": String(\"Model not found\")}). Returning error: RequestFailed(\"Bad request (400): {\\\"detail\\\":\\\"Model not found\\\"}\")"},"target":"goose::providers::openai_compatible"}
{"timestamp":"2026-03-04T14:27:37.442716Z","level":"WARN","fields":{"message":"Request failed, retrying (3/3): RequestFailed(\"Bad request (400): {\\\"detail\\\":\\\"Model not found\\\"}\")"},"target":"goose::providers::retry"}

I'm not sure why this would be as when I ran goose configure it detected the available models and I chose qwen3-coder:30b which is working. Is Goose trying to check for OpenAI models that don't exist on my deployment?

[fresh3nough]

Bug 1: Custom headers silently dropped when OPENAI_API_KEY is unset

The root cause is in openai.rs:79-86. get_secrets("OPENAI_API_KEY", &["OPENAI_CUSTOM_HEADERS"]) uses OPENAI_API_KEY as the primary key. In config/base.rs:754-776, if the primary key isn't found, the entire call fails and unwrap_or_default() returns an empty map — discarding OPENAI_CUSTOM_HEADERS entirely, even when it's set via env var.

Additionally, get_secrets uses the primary key's source (env vs keyring) to decide where to look for all secrets. If OPENAI_API_KEY isn't in env, it switches to keyring-only mode and ignores OPENAI_CUSTOM_HEADERS from the environment.

Fix options:

A) Change from_env to fetch custom headers independently — Call get_secret("OPENAI_CUSTOM_HEADERS") separately (with env fallback) instead of bundling it with the API key. Simplest, lowest risk.

B) Fix get_secrets to not fail when primary is missing — Make the primary key optional in the HashMap (use if let Ok(v) like the secondary keys). Broader fix but changes a shared API.

Bug 2: Auth header override

Even when custom headers are successfully loaded, if OPENAI_API_KEY is also set, the Authorization header from custom headers gets overwritten. In api_client.rs:412-426, send_request applies AuthMethod::BearerToken after custom headers, so Authorization: Bearer always wins over Authorization: Basic .

Fix options:

C) Skip default auth when custom Authorization header exists — In from_env, if custom headers contain an authorization key, set AuthMethod::NoAuth regardless of whether an API key exists.

D) Reverse the apply order — Apply auth headers before per-request/custom headers in send_request so custom headers take precedence. Riskier since it affects all providers.

Bug 3: "Model not found" 400 errors (secondary issue)

In openai.rs:72, from_env always sets:
crates/goose/src/providers/openai.rs (72-72)
This hardcodes gpt-4o-mini as the fast model for all OpenAI provider instances, including custom hosts. When complete_fast runs, it tries gpt-4o-mini first → 400 "Model not found" on Ollama/Open WebUI → retries 3 times → falls back to the actual model. This explains the alternating 400/200 pattern.

Fix options:

E) Don't set a default fast model when using a custom host — If OPENAI_HOST is not api.openai.com, skip the with_fast() call.

F) Set fast model to the user's model on custom hosts — Same as E but explicitly uses the user's model as both primary and fast.

any guidance on preferences here would be helpful, basically just pick one option for each bug

@treydock

[fresh3nough]

The minimal, safe fix combines A + C + E: fetch custom headers independently, respect custom Authorization headers over default auth, and skip the hardcoded fast model for non-OpenAI hosts.

[DOsinga]

thanks @fresh3nough for looking into this. I think the basic use case you suggested is right, you should use a custom provider for this, not trying to change the behavior of the basic openai provider. supporting custom headers independently of the API key does seem like a good fix though, yeah. fast model should just be part of the custom providers.

[DOsinga]

closing this since the highlevel issue is fixed by custom providers.