Codex model picker does not list models from alternative endpoints (e.g. CC Switch)

[AuroraAeon]

What happened

When Codex is configured to route requests to an alternative endpoint, the Codex model picker only lists the built-in OpenAI catalog (gpt-6-astra, gpt-5.6-sol, gpt-5.6-terra, gpt-5.6-luna, gpt-5.5). The model that Codex actually uses from config.toml is not selectable.

What I expected

The picker should offer the model configured for the active provider, so a conversation can run against the endpoint that is actually configured.

Environment

• Claudian 2.2.7, Codex CLI 0.155.0-alpha.9.2 (ChatGPT desktop build), macOS, Obsidian 1.x
• Codex configured through CC Switch 3.20.3: ~/.codex/config.toml contains model_provider = "custom", model = "step-5-preview", and [model_providers.custom] base_url = "https://api.stepfun.com/step_plan/v1" (or the CC Switch local proxy at http://127.0.0.1:15721/v1 when its proxy is enabled)

Reproduction

1. Switch Codex to a third-party provider with CC Switch (or configure model_providers manually).
2. Open the Codex model picker in Claudian.

Observed: only the five built-in OpenAI models are listed; step-5-preview is absent. Selecting a listed model sends an unknown model name to the third-party endpoint and fails.

Investigation

The picker is populated from the Codex app-server model/list RPC. That RPC returns the build's built-in OpenAI catalog regardless of model_provider / base_url in config.toml, and regardless of auth mode. Verified experimentally: pointing the custom provider at a logging HTTP server produced zero requests to that server during model/list, and the returned catalog was identical under chatgpt and apikey auth modes.

So the configured provider affects inference routing only, not the catalog. Reading the configured model from the local Codex config is the reliable signal.

Proposed direction

During Codex model discovery, read $CODEX_HOME/config.toml (default ~/.codex/config.toml). When the active model_provider points at a non-OpenAI base_url, offer the configured model first in the catalog with fallback metadata, and include the provider signature in the catalog fingerprint so switching providers invalidates the cached catalog. The app-server catalog stays listed after the configured model, and behavior for the official endpoint is unchanged.

A pull request implementing this is ready: #1380