[Bug]: gpt-daybreak-blue-latest missing from OpenCodex and Codex App model lists

[liewcf]

Client or integration

Codex App

Provider or upstream service

openai

OpenCodex version

2.10.0

Endpoint or capability

model discovery / model catalog

Current behaviour

When Codex App is routed through OpenCodex 2.10.0 on macOS, gpt-daybreak-blue-latest is absent from both the OpenCodex model list and the Codex App model picker. There is no response body or error because the model is omitted from discovery.

Expected behaviour

OpenCodex should discover and expose gpt-daybreak-blue-latest for an eligible OpenAI account, so it appears in OpenCodex's catalog and in the connected Codex App model picker. The same account shows the model when Codex connects directly without OpenCodex.

Minimal redacted request or reproduction

1. On macOS, configure Codex App to route through OpenCodex 2.10.0 using the OpenAI provider.
2. Open the OpenCodex model list and search for `gpt-daybreak-blue-latest`.
3. Open the Codex App model picker and search for the same model.
4. Disconnect or bypass OpenCodex and connect Codex directly with the same OpenAI account.
5. Open the Codex App model picker again.

Result: the model is missing in steps 2 and 3, but appears in step 5.

Actual response or error

No HTTP error was displayed. `gpt-daybreak-blue-latest` was simply absent from both model lists while routed through OpenCodex.

Upstream documentation

No public model-specific specification is available. Expected behavior is based on the concrete Codex App client behavior: the same eligible OpenAI account exposes gpt-daybreak-blue-latest when connected directly, but not when routed through OpenCodex.

Suggested mapping or implementation notes

Ensure OpenAI model discovery/catalog synchronization preserves newly available model slugs such as gpt-daybreak-blue-latest and propagates them to the Codex App catalog instead of filtering them out.

Additional context and attachments

• Reproduced on macOS on August 11, 2026.
• OpenCodex version: 2.10.0.
• Client: Codex App.
• Provider: OpenAI.
• Direct routing of the slug through OpenCodex was not tested.
• OpenCodex was uninstalled after reproducing, so additional proxy logs are not available.

Checks

• I searched existing provider and compatibility issues.
• The request and response were redacted.
• The expected behaviour is based on an upstream specification or a concrete client requirement.

[Ingwannu]

Thanks for the report. Current dev already contains the documented OpenAI API-key Daybreak aliases daybreak-red-latest and daybreak-blue-latest (commit e2f7f2ba7), but the identifier in this report is different: gpt-daybreak-blue-latest.

I do not want to add a guessed compatibility alias until we know which catalog actually emitted that identifier. Could you please confirm:

1. whether "OpenAI provider" here means ChatGPT/Codex account login or an OpenAI API key;
2. the exact model id shown by the direct Codex App picker or model cache (with account details redacted);
3. whether invoking gpt-daybreak-blue-latest directly succeeds, or whether it is only a display/picker id.

If the account-scoped catalog really returns the gpt--prefixed id, we should preserve that upstream id at the correct authentication surface. If not, fabricating a second alias could expose a model that the selected provider cannot serve. Marking this as needs-info while keeping it open.

[0disoft]

I can provide the requested confirmation from a separate Windows reproduction on OpenCodex 2.12.0.

1. Authentication surface: this is the ChatGPT/Codex account-login path (openai provider using authMode: forward and https://chatgpt.com/backend-api/codex), not an OpenAI API key provider.

2. Exact direct Codex identifier: on another laptop without OpenCodex, signed into the same ChatGPT account, the Codex App picker exposes Daybreak Blue and the environment reports the exact model id as:

gpt-daybreak-blue-latest

3. Direct invocation through OpenCodex succeeds: on OpenCodex 2.12.0 I manually registered this exact upstream id under the account-login provider:

openai/gpt-daybreak-blue-latest

A redacted POST /v1/responses test using the Codex account bearer context completed successfully and returned:

DAYBREAK_OK
response.completed

The account is therefore provisioned for and can serve the gpt--prefixed id; it is not only a display label.

Additional catalog behavior:

• OpenCodex 2.12.0's built-in native list does not contain any Daybreak id.
• The manually registered custom model appears as openai/gpt-daybreak-blue-latest and works.
• Attempting to expose the exact bare alias with ocx combo ... --native-alias is rejected with:

nativeAlias requires a currently supported bare OpenAI-native model alias

• A normal bare combo alias is also rejected because OpenAI-family bare aliases require nativeAlias=true.

This supports preserving gpt-daybreak-blue-latest from the account-scoped ChatGPT/Codex catalog at the account-login authentication surface. It should not be conflated with the API-key aliases already added on dev.

[Yuxin-Qiao]

Implementation handoff: PR #1515 is now rebased onto current dev@567a6d4ffe6a7d7b341b5cc11e736081e1bb4522 at head ddc192c668cf36d13ff189b71363341c4f01d81b.

The exact-head focused matrix passes 84 tests / 616 assertions, with typecheck, privacy scan, diff check, and the four repository PR gates green. The PR body contains Closes #1480 and the implementation now covers the concrete account surface and gpt-daybreak-blue-latest evidence reported above. Issue closure is intentionally left to the merge outcome.

[Wibias]

Fixed by #1515