Codex model picker: Daybreak as a switch for any supported model #4802

The workflow

I use Codex with Daybreak for security research. bb already lets me select Daybreak, but only as a single model called "Daybreak Blue". In Codex Desktop Daybreak is a switch, and it lets you select any supported model. I'd like bb's picker to work the same way.

What happens today

• bb's Codex model picker lists a "Daybreak Blue" entry. This is gpt-daybreak-blue-latest.
• That entry is an opaque alias, and you can't tell which model you're getting.
• You can't use Daybreak and pick an exact model.

What you would expect

Daybreak in bb's Codex model picker, working the way it does in Codex Desktop:

1. A Daybreak switch in the model picker. It appears only when the account has Daybreak, meaning some model in model/list advertises a Daybreak program.
2. Models that can't run in the current state are greyed out with a reason.
   • With Daybreak on, a model without a Daybreak program, such as gpt-6-astra, shows as disabled: "Turn off Daybreak to use this model".
   • With Daybreak off, a Daybreak-only model shows as disabled: "Turn on Daybreak to use this model".
   • Desktop hides the gpt-daybreak-*-latest alias models from the picker once the switch is available, since the switch replaces them. bb should do the same, so "Daybreak Blue" no longer appears as a model of its own.
3. Turning Daybreak on switches to a supported model. If the selected model doesn't support it (for example Astra, the default), bb switches to the first compatible model, such as gpt-6-sol. Turning it off does the same in reverse.
4. Each turn asks for the right program. No blue/red choice is shown to the user.
5. The choice is remembered for the thread and as the default for new threads.
6. CLI and SDK parity, per AGENTS.md. For example, a Daybreak provider option on bb thread spawn / bb thread tell, documented in the Codex plugin skill.

How Codex implements it. I checked the openai/codex source at b741e480, Codex Desktop 26.924's bundle, and a live model/list.

• The client picks the program. It sends cyberAccessProgram on every turn/start, and the app-server passes it through unchanged (turn_processor.rs#L659).
• The program comes from the selected model's availableAccessPrograms.cyber. The catalog is per account, so it already reflects the account's access:
  • Daybreak on: daybreakBlue if the model lists it, otherwise daybreakRed (ModelAccessPrograms::daybreak()).
  • Daybreak off: standard if the model lists it.
  • Codex's TUI does this in program_for_turn, and Codex Desktop uses the same rule.
• daybreakEnabled stores the choice on the thread. It's sent on thread/start and thread/metadata/update, and forks inherit it. App-server rejects it for ephemeral threads. On its own it doesn't select a program.
• The new-thread default is kept by the client. The TUI and codex exec use daybreak = true in config.toml.
• Example model/list on a Daybreak Blue account (codex-cli 0.156.1):
  • gpt-6-astra (the default) → ["standard"]
  • gpt-6-sol, gpt-6-luna, gpt-5.6-*, gpt-5.5 → ["standard","daybreakBlue"]
  • gpt-daybreak-blue-latest → ["daybreakBlue"]

Context and alternatives

No response

Checks

• I searched open and closed issues for the same request.
• If an agent wrote this, the body ends with > AGENT GENERATED.

AGENT GENERATED and edited by me