Desktop: show effective request endpoint and config provenance, warn on third-party routing, and restore OpenAI defaults

Summary

Codex Desktop should always show the effective model provider and request destination, explain where that configuration came from, and provide a safe way to restore the official OpenAI defaults.

Today, a user can successfully sign in with a ChatGPT account while model requests are still routed to a custom third-party base_url configured earlier by a local integration. The UI can look like a normal ChatGPT/Codex session. The user may only discover the actual destination after a request fails with repeated reconnect attempts and a 401 response containing the third-party URL.

This creates a serious security and trust problem: signing in with ChatGPT does not necessarily mean prompts and files are being sent to OpenAI, but the Desktop UI does not make that distinction sufficiently visible.

Observed scenario

1. A third-party integration configures a custom model provider or openai_base_url in the user-level Codex configuration and/or environment.
2. The user later signs in successfully with a ChatGPT Work account.
3. ChatGPT in the browser works normally.
4. Codex Desktop continues sending model requests to the custom third-party /responses endpoint.
5. When the third-party API key expires or no longer matches, Desktop shows Reconnecting 5/5 followed by 401 INVALID_API_KEY.
6. Reinstalling the Desktop application does not necessarily fix the problem because user-level configuration survives application reinstall.
7. The only clear indication of the actual destination is the URL embedded in the final error.

Requested UX

Persistent provider indicator

Show a persistent, user-visible status near the account/workspace control:

• OpenAI official
• or Custom provider: example.com

This should not be hidden only inside logs or error details.

Provider and endpoint settings

Add a settings page showing:

• Effective model provider
• Effective request base URL/domain
• Authentication mode: ChatGPT sign-in, API key, workload identity, or custom provider
• Whether WebSocket/HTTPS fallback is enabled
• Secrets must remain masked

Configuration provenance

For each effective provider/routing setting, show where it came from:

• Desktop setting
• $CODEX_HOME/config.toml
• selected profile
• environment variable
• managed organization policy
• launch argument

Merely displaying an editable URL is not enough; users need provenance to distinguish an intentional configuration from an unexpected local modification.

Third-party destination warning

Before sending prompts or files to a non-OpenAI domain for the first time, show a confirmation explaining that content and attachments may be transmitted to that third party. Remember the decision per domain and make it reviewable/revocable in Settings.

Restore official defaults

Provide a one-click action that:

• selects the built-in OpenAI/ChatGPT provider
• removes or disables effective custom endpoint overrides
• explains any remaining environment- or policy-level override that the app cannot edit
• restarts/reloads the provider state safely

Better errors

Connection and authentication errors should state:

• the effective destination domain
• whether it is OpenAI or a custom provider
• the configuration source that selected it
• the relevant remediation action

For example:

Authentication failed for custom provider example.com. This endpoint was selected by $CODEX_HOME/config.toml. Review provider settings or restore OpenAI defaults.

Acceptance criteria

• A user can identify the effective request destination before sending a prompt.
• A ChatGPT-authenticated session that uses a custom provider is visibly distinguished from an official OpenAI-routed session.
• Every effective custom endpoint has a visible configuration source.
• Non-OpenAI destinations require informed confirmation before sending user content.
• A user can restore official routing without manually editing configuration files.
• Reconnect and 401 errors identify the effective endpoint and its source.

Priority recommendation

P1 / High

Reason: this is not only a troubleshooting problem. A stale or externally modified custom endpoint can silently route proprietary prompts, source code, and attachments to an unintended third party while the user believes they are using their authenticated ChatGPT workspace.

Related issues

• #40435 — stale custom openai_base_url appears as a generic reconnect/network failure
• #24457 — Desktop can combine a custom provider URL with a mismatched API key
• #13838 — browser authentication can work while Desktop continues to fail with 401

No files, tests, or implementation entry points are named. Start by mapping how Desktop resolves provider settings across Desktop configuration, $CODEX_HOME/config.toml, profiles, environment variables, policies, and launch arguments; done means the requested visibility, warning, restore, and error behavior meet all listed acceptance criteria.