feat(codex): choose a cyber access program for Daybreak-eligible models#27928

Approvability

Verdict: Approved at e960980

Macroscope's review found this PR approvable — Adds a Cyber Access choice for eligible Codex models and sends explicit selections with each turn. Automatic preserves existing behavior, and custom models do not inherit the new selector.

^{You can add or adjust custom eligibility rules. Learn more.}

Explain Change →

No actionable comments were generated in the recent review.

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

External image Recent review info

External image Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: bd7da7f
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: b3228482-8057-4d71-bb01-34c99ecd4709

External image Commits

Reviewing files that changed from the base of the PR and between 7cd0e5736ba6f09858b314aff63b3129b476ba44 and d6d1dad98cbb43d18ac33dbee2c9505a8b2510a6.

External image Files selected for processing: 5

• apps/server/src/orchestration-v2/Adapters/CodexAdapterV2.test.ts
• apps/server/src/orchestration-v2/Adapters/CodexAdapterV2.ts
• apps/server/src/provider/CodexProvider.test.ts
• apps/server/src/provider/CodexProvider.ts
• apps/server/src/provider/Drivers/CodexDriver.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.

Seconding this. It would be very welcome to have the ability to select cyber access mode.

Also, @JacksonBarker made a really good point - with the changes - there's no way to specifically turn off daybreak access with t3 currently, I believe it'll send auto instead of standard, which will let codex choose

Verified in a real dev environment

verified the server/provider forwarding on Linux at 5492df89e135b279885f6d6c6681c6e6253fb829, without code changes. compared with github/main at 54c5f25249961a1aa0b61932329092eadbd9d6fc in a separate worktree. installed both with vp i and ran one background dev server at a time with isolated data.

used repo Playwright and /usr/bin/google-chrome to add the real git repository, create threads, submit real Codex gpt-6.1-sol turns, and inspect responses. no mocks, fixtures, demo provider, or invented catalog entries.

this proxy catalog returns availableAccessPrograms: null for every model. the Cyber Access selector therefore correctly stays hidden on Sol and Luna. to exercise the changed server path, sent explicit model options through the authenticated running servers WebSocket orchestration.dispatchCommand API, then observed the actual Codex app-server protocol log and the response in the web client.

short transcript, reduced from the real outbound turn/start frames:

daybreak forwarding also passed again after restarting the pr server. the neighboring normal-turn and follow-up flows returned the requested text, and Sol retained reasoning, service tier, and permission controls. filtered protocol transcript.

ran through blacksmith-check: vp i followed by vp test run apps/server/src/provider/CodexProvider.test.ts apps/server/src/orchestration-v2/Adapters/CodexAdapterV2.test.ts. both files passed, 131 tests. the current head also has 28 green CI results (20 passed, 8 skipped), zero failing or pending.

matching conversation crops below show the same response on main and the pr. these images alone do not prove forwarding; the protocol transcript above distinguishes them.

main: matching real Sol conversation, program silently omitted

pr: matching real Sol conversation, daybreakBlue forwarded

12-second recording of the pr response and a follow-up submitted with the real composer. inspected the exported clip and verified uploaded playback and seeking.

pr: real Sol daybreak request response and UI follow-up

Not verified

• inline video playback inside the GitHub comment: GitHub treats the externally hosted mp4 as an image. the uploaded video itself passed playback and seeking in the T3 browser player; the PNGs render correctly on GitHub. Cafe renders external media as links.
• eligible-model selector, changing its selection, and persistence through reload: the real proxy catalog advertises no eligible models. the server API checks above do not substitute for this UI check.
• actual Daybreak entitlement or backend program execution: the proxy completed the requests, but Codex supplies no completed-turn confirmation of the applied program. this proves T3 forwarding, not that the upstream ran Daybreak.
• native iOS/Android, Electron-specific behavior, macOS/Windows, remote/relay/tunnel connections, custom-model UI, and Codex-native subagent inheritance were not exercised on this Linux VM.

no source changes or pushes were needed. no merge, close, rebase, force-push, or label changes.

@maria-rcks I ran your open checks on an account with Daybreak Blue, at 5492df89e1 on macOS with Codex CLI 0.165.0. The selector and its persistence work, and OpenAI's backend does act on the field.

Selector, using the account's real catalog. I checked these in the web UI against an isolated dev server.

A Daybreak Blue selection on Luna survived a page reload.

Screenshots, in table order, taken at 1920x1200 and saved at 1280x800. The thread behind each menu holds four earlier "reply ok" turns on the same commit.

Real composer turns. A logging wrapper around codex recorded these outbound turn/start frames. All four turns completed.

The last line shows the Blue selection doesn't carry over to a model that doesn't offer it. Sending it there would get a 403, as the next section shows.

A recording of these four turns, plus the Sol, Daybreak Blue and custom-model menus, in one take at 3360x2100. It came from a later run on the same commit, using Playwright with Chrome at 2x because the T3 browser panel's captures were blurry. The logged frames for that run match the block above.

https://github.com/user-attachments/assets/2a1b45e6-79a9-4c25-8769-e577d7a88ca3

Backend enforcement. I sent these directly to codex app-server on the same login, using ephemeral threads.

The two rejections show OpenAI reads the program. A completed turn still doesn't report which program ran, so I can't confirm that from the Luna turns. Because Standard is rejected on the Blue model and omission isn't, omission there can't mean Standard.

What omission does on the wire. I ran the real app-server against a local mock Responses API with a dummy API key.

-c daybreak=false gave the same results. So main sends no program at all, and OpenAI's server decides. cyber_access_program.rs forwards the same value for ChatGPT sign-in, but I only read that path and didn't run it against the mock.

The Automatic default differs from the CLI. daybreak defaults to false in Codex config. With it off, Codex's TUI and exec send explicit standard for eligible accounts when the model advertises it (tui/src/daybreak.rs, exec/src/daybreak.rs). So the PR's Automatic matches app-server omission, not the CLI's default. This is the gap Jackson raised, and it's why #27835 asks for an explicit opt-out. Standard-only and custom models also have no selector, so T3 can't send standard for them.

The selection carries into new threads. After I picked Daybreak Blue on Luna in one thread, a new thread's composer opened on Luna with Daybreak Blue already selected. The docs in this PR say the choice applies "in that thread". I set Automatic before sending, so I didn't test a turn from that state.

Not verified:

• native iOS/Android, Electron, Windows
• remote, relay and tunnel connections
• a live Codex-native subagent turn. Codex's source says the turn's program includes child-agent inheritance, but I didn't run one.

@maria-rcks I pushed 5b6fdd1d7b (rebased onto current main, with the captures and turns below redone on it), which replaces Automatic with Codex's default, so this replaces the evidence in my earlier comment wherever the two differ. T3 now sends Standard unless the user picks Daybreak or sets daybreak = true.

What changed

• A model in Codex's catalog now defaults to Standard when it offers it. With daybreak = true, it defaults to Daybreak when it offers that. This matches tui/src/daybreak.rs and exec/src/daybreak.rs.
• Automatic is gone. Standard-only and Daybreak-only models show a one-option selector, so the program being sent is visible.
• Turns with no selection use the model's default from the provider snapshot, with no extra app-server requests.
• Custom models still omit the field, as Codex does for models missing from the catalog.
• The carry-over into new threads stays, because Codex's /daybreak also saves the choice for new threads (tui/src/app/daybreak.rs). The docs now say so instead of "in that thread".

I couldn't read OpenAI's help articles, which return 403 to my tools, so this follows Codex's source and the guidance quoted in #27835.

One deliberate difference from Codex. With Daybreak on and a model that doesn't offer it, Codex stops with an error and T3 stays on Standard, so an existing daybreak = true config doesn't break every Sol turn.

Recording. The full flow in one take on 5b6fdd1d7b, 3360x2100, from a fresh browser profile. I used Playwright with Chrome at 2x because the T3 browser panel's captures were blurry.

https://github.com/user-attachments/assets/ab238685-e96d-4485-b732-71d4763ade5c

Real composer turns on that take. A logging wrapper around codex recorded these outbound turn/start frames. All six turns completed.

The first turn is stored with no cyber option on the run, so it exercised the snapshot fallback.

With -c daybreak=true in the provider's launch arguments, from another fresh profile. Both turns completed.

This gives #27835 its separate on and off providers.

Before and after, matching captures. Before is main at 54c5f25249, the commit this PR is rebased on.

	GPT-6-Luna	GPT-6.1-Sol
Before
After

Daybreak Blue after reload	New thread, carried over	daybreak = true default

Daybreak Blue model	Custom model

Backend enforcement, rerun today against codex app-server on the same login. The results match my earlier comment.

A completed turn still doesn't report which program ran, so T3's forwarding and these rejections are provable, but what ran on a completed turn isn't.

Local checks and review. vp run check:changed passed on the rebased commit. GPT-6.1-Sol approved after 2 review rounds. Its one finding was that a saved explicit program still reaches Codex in an API-key session with features.api_key_cyber_access_programs = false. We kept that, because Codex then rejects the turn visibly, which is what #27835 asks for. CodeRabbit raised the same point for stale selections, and I dismissed it with the same reason on its thread.

Not verified:

• API-key accounts and the managed Codex provider, which got the same change
• native iOS/Android, Electron, Windows
• remote, relay and tunnel connections
• a live Codex-native subagent turn or T3 delegated task

@coderabbitai review

The automated pipeline stopped on this pull request and will not merge it:

the proof has no capture anyone can open:

• Permanent blocker: first-party ChatGPT OAuth is unavailable on this VM; local Codex authentication has no OAuth tokens.
• The Cyber Access selector, default selection, reload persistence, and standard → daybreakBlue → standard outbound turn/start sequence remain unverified on both commits.
• Pass-through of recognized explicit selections and visible rejection of unsupported choices remain unverified.
• No captures or driver scripts were produced, so no ghdrop upload was attempted.

It stays open for a person to finish or close.

@juliusmarminge The pipeline VM had no ChatGPT OAuth, so I reran the checks on an account with Daybreak Blue. Everything below is on the current head, 29f5fefec3, on macOS with Codex CLI 0.167.0 and no daybreak setting in ~/.codex/config.toml. I used an isolated dev server and a fresh scratch project, and drove the real composer in T3's browser panel. Every turn is a real Codex turn. Nothing is mocked.

Selector

These come from the account's live catalog, with the Cyber Access submenu open on each model.

Daybreak Blue offering Standard is the 29f5fefec3 change. In that capture Standard is ticked because I had picked it in the thread before (turn 6 below), and the choice carries into new threads.

Turns and outbound frames

I typed each message into the composer and sent it with Enter. I made the Cyber Access picks in the model picker's submenu, using scripted clicks inside the page, and did the reload by navigating to the thread URL again. The frames are the turn/start requests T3 sent to codex app-server, read from the provider protocol log by the script at the end.

1. Luna, nothing chosen. Sent standard.
2. Luna, Daybreak Blue chosen in the menu. Sent daybreakBlue.
3. Page reloaded. The menu still showed Daybreak Blue, and the turn sent daybreakBlue.
4. Standard chosen again. Sent standard.
5. New thread on the Daybreak Blue model with its default. Sent daybreakBlue and completed.
6. Same thread, Standard chosen. Sent standard. OpenAI rejected it with a 400, and the thread shows the error and is marked Failed.
7. New thread with Daybreak Blue chosen on Luna, then switched to Sol. The menu dropped back to Standard, Sol's only program, and the turn sent standard.

Luna thread after the reload, with Daybreak Blue still selected:

Daybreak Blue model with Standard chosen, rejected visibly:

On 29f5fefec3 these all hold: the default selection, reload persistence, the standard → daybreakBlue → standard sequence, pass-through of an explicit choice and a visible rejection.

Not covered here: sending Daybreak Blue to a Standard-only model. The composer can't produce that turn, because switching models drops the choice to one the new model offers (turn 7).

As a side note: It's likely that y'all are eligible for Cyber Access as maintainers of this project to be frank. Given some of the access that this project has to machines, and agents, I wouldn't be surprised if it's not a target already.

Taking over this one — thanks @Mezzle. I'll rebuild on current main (merging, not force-pushing), trim the tests, and add delegated-task inheritance of the cyber access program. Standard-by-default is approved on the maintainer side, per #27835.