Codex Desktop mixes local custom provider base_url with remote auth.json API key

[Void0312Aurora]

What version of the Codex App are you using (From “About Codex” dialog)?

Codex Desktop/26.506.21252 Dev

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Codex Desktop appears to combine the local custom provider base_url with an API key from a remote environment's auth.json.

This does not look like a server-side issue. The local custom provider expects one API key, but Codex Desktop sends a different key that belongs to the remote active Codex environment.

Local Windows Codex config:

• custom provider A
• wire_api = "responses"
• requires_openai_auth = true
• base_url = "https://local-custom-provider.example/v1"
• local auth key fingerprint: local-key...abcd

Remote Codex environment:

• custom provider B
• base_url = "https://remote-custom-provider.example/v1"
• remote auth key fingerprint: remote-key...wxyz

POST /v1/responses
Originator: Codex Desktop
User-Agent: Codex Desktop/0.129.0-alpha.15 (Windows 10.0.26200; x86_64)
Host: local-custom-provider.example
Authorization: Bearer remote-key...wxyz
Status: 401
{"error":"Invalid API key"}

The request URL/host is the local custom provider, but the Authorization header uses the remote active key.

What steps can reproduce the bug?

### Steps to reproduce

1. Configure Codex Desktop on the local machine with a custom Responses API provider:

```toml
model_provider = "custom"

[model_providers.custom]
name = "custom"
wire_api = "responses"
requires_openai_auth = true
base_url = "https://local-custom-provider.example/v1"

2. Configure the local machine's Codex auth file with API key A:

{
  "OPENAI_API_KEY": "local-key...abcd"
}

3. Use Codex Desktop with a remote workspace / remote environment that has its own Codex auth file configured with API key B:

{
  "OPENAI_API_KEY": "remote-key...wxyz"
}

4. Ensure API key A is valid for local-custom-provider.example, and API key B is valid for a different provider or environment.

5. From Codex Desktop, start a session that targets the local custom provider while connected to the remote workspace / environment.

6. Send any request that uses the Responses API, for example a normal chat turn.

7. Inspect the local custom provider's request logs.

8. Observe that the request is sent to the local custom provider URL, but the Authorization header contains API key B from the remote environment instead of API key A from the local machine.

### What is the expected behavior?

The Authorization header should come from the same configuration scope as the selected base_url.

If Codex Desktop is sending requests to the local custom provider configured in the local Windows ~/.codex/config.toml, it should use the local Windows ~/.codex/auth.json key.

It should not use the remote environment's active OPENAI_API_KEY when the request target is the local custom provider.

### Additional information

_No response_

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• Mobile Remote: Android Remote should preserve host provider config #23659

Powered by Codex Action

[51798a-alt]

This looks like the selected provider config and the selected credential source need to remain coupled.

For a custom Responses/OpenAI-compatible provider, I would expect the resolved request context to be something like:

• provider name
• base_url
• wire_api
• requires_openai_auth
• token source / credential scope

If the base_url is resolved from the local custom provider but the bearer token is resolved from the remote active Codex environment, the request can end up targeting provider A with provider B's credential.

A safer behavior might be:

• When a local custom provider is selected, use the local provider's configured credential source with that provider.
• Do not fall back to the remote/default auth source unless the selected provider is the remote/default provider.
• Treat base_url and token source as one resolved provider context.
• For debugging, show the resolved provider name and base URL, while redacting the token.

This matters for OpenAI-compatible custom providers because they intentionally use OpenAI-style request shapes while requiring provider-specific credentials.