feat(codex): export an API-key-scoped model_catalog_json

Summary

Codex supports model_catalog_json, but custom-provider users currently have to build and maintain that file manually. For gateways that expose different model permissions per API key, Codex should be able to export a static catalog from the models visible to the active provider credential.

The exported catalog should contain only models authorized for that API key, rather than the provider's global catalog or Codex's bundled first-party catalog.

Motivation

A custom OpenAI-compatible gateway may serve multiple isolated workspaces from one endpoint. Each API key can have a different model allowlist, for example:

• workspace A: one free model and one explicitly approved paid model
• workspace B: a different set of personal models
• other models present in the gateway catalog but not permitted for that credential

Codex CLI can use a manually authored model_catalog_json, and /model can then switch among those entries. The missing piece is a supported way to derive that static catalog from the active credential's effective permissions.

Without this capability, users must:

1. Query the provider manually.
2. Copy model IDs into a hand-maintained catalog.
3. Rebuild the file whenever API-key permissions change.
4. Take extra care not to expose models belonging to another workspace or credential.

That creates drift and makes least-privilege model selection harder to enforce.

Proposed behavior

Add a Codex command or configuration workflow that exports a valid model_catalog_json for the active custom provider, for example:

codex models export \
  --provider unified_router \
  --output ~/.codex-unified/model-catalog.json

The exact command name is flexible. The important behavior is:

• Authenticate using the active provider's configured credential mechanism (env_key, auth command, or equivalent).
• Call the provider's model-list endpoint using that credential.
• Export only models returned for that credential.
• Preserve provider-specific model slugs exactly.
• Produce the complete schema expected by the running Codex version, including required default fields.
• Avoid printing or persisting the provider secret.
• Fail closed if model discovery is unavailable or ambiguous.
• Do not merge in bundled OpenAI models unless explicitly requested.
• Support an atomic replace/write mode so an interrupted refresh cannot corrupt the existing catalog.

An optional refresh mode could compare the newly discovered allowlist with the existing file and show added or removed models before replacing it.

Security and isolation requirements

This feature should be credential-scoped, not endpoint-scoped.

Two API keys using the same gateway URL may legitimately receive different model lists. Codex must not reuse or cache one key's discovered catalog for another key, profile, CODEX_HOME, or workspace.

The export should never include:

• models hidden from the active credential
• models discovered using another provider profile
• secrets, bearer tokens, or auth-command output
• inferred fallback models that were not returned by the active credential

Example use case

A local gateway exposes an OpenAI-compatible /v1/models endpoint. The active API key returns only:

mta/granite-4-h-small
mta/claude-sonnet-5

A different personal key against another provider or route returns:

personal/glm-5.2
personal/deepseek-v4-flash
personal/deepseek-v4-pro

Codex should be able to generate separate valid catalogs for these credentials without combining the two sets. This is especially important when the lists cross free/paid or organizational workspace boundaries.

Expected result

Custom-provider users can generate a version-valid, API-key-scoped model_catalog_json directly from the provider's effective model allowlist, then use /model without manually editing JSON or risking cross-workspace model exposure.

Relationship to existing issues

This is narrower than Desktop custom-provider/model-picker issues such as [#10867](<https://github.com/openai/codex/issues/10867>), openai/codex#19694, and openai/codex#29156. Those concern GUI visibility, provider-aware switching, or additive catalogs. This request concerns safe generation of the static catalog from the active credential's authorized model list, including CLI-only deployments.