Repository navigation
Conversation
Codex's app server only applies Daybreak when each turn/start carries cyberAccessProgram; its config.toml `daybreak` setting does not reach app-server turns. T3 never sent the field, and the turn/start encode schema dropped it. Models whose catalog entry lists a Daybreak program in availableAccessPrograms.cyber now get a Cyber Access select. Its default, Automatic, omits the field so Codex keeps its own behaviour. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review.
|
| Layer / File(s) | Summary |
|---|---|
Expose cyber access options apps/server/src/codexModelOptions.ts, apps/server/src/provider/CodexProvider.ts, apps/server/src/provider/CodexProvider.test.ts, docs/user/providers-codex.md |
Adds an Automatic option and labels for known programs. Models with a non-standard program receive a Cyber Access selector. Custom models do not inherit this selector from fallback capabilities. Tests and documentation cover the option behavior. |
Pass the selection to turn/start packages/effect-codex-app-server/src/client.ts, apps/server/src/orchestration-v2/Adapters/CodexAdapterV2.ts, apps/server/src/orchestration-v2/Adapters/CodexAdapterV2.test.ts |
The turn-start schemas accept an optional cyber access program. The adapter sends defined selections and omits absent or Automatic values. Tests cover value handling and a completed replay turn. |
Priority:
Estimated code review effort: 2 (Simple) | ~12 minutes
Change: Feature
Sequence Diagram(s)
sequenceDiagram
participant CodexProvider
participant ModelSelection
participant CodexAdapterV2
participant turnStart
CodexProvider->>ModelSelection: Exposes cyber access program options
ModelSelection->>CodexAdapterV2: Provides selected program
CodexAdapterV2->>turnStart: Sends defined cyberAccessProgram
Possibly related PRs
- pingdotgg/t3code#23184: Implements Codex cyber access program capability and turn forwarding, which this change extends with Automatic handling and custom-model filtering.
Suggested reviewers: juliusmarminge, t3dotgg
Merge Risk: 
Minimal · up to d4613
-
No actionable merge-blocking risk remains from the reviewed changes.
Pre-merge checks: 
4
Finishing Touches
-
🧪 Generate unit tests (beta)
-
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Comment @coderabbitai help to get the list of available commands.
e03f822 to
4cdbb99
Compare
|
Apologies for the rebase - didn't realise I'd done this against an old version. |
A bare custom Codex slug borrows the first built-in model's options, so it could show Cyber Access even though Daybreak eligibility is per model. Strip that option from borrowed capabilities, type the turn/start field with the turn/start schema, and document the setting. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Note Written by dry-run draft, no action taken. closure is warranted under the verification rule. The Cyber Access option is supported by focused tests and live Codex requests, but its new model option is shown only in an after screenshot without the required before/after UI evidence. Add matching before/after captures of the model options, including an eligible model and the unchanged unsupported-model state, alongside the existing provider-path checks. |
Continued in #27928 with the rebased commits and the before/after evidence requested below. GitHub rejected reopening this PR after the branch rebase.
Problem
OpenAI's Daybreak programme only applies to a Codex app-server turn when that turn's
turn/startcarriescyberAccessProgram. Thedaybreaksetting inconfig.tomland saved thread preferences do not reach app-server turns (OpenAI guide). T3 never sent the field, so a user with Daybreak access cannot use it from T3. The turn/start encode schema ineffect-codex-app-serveralso dropped the field, because Codex marks it experimental and leaves it out of the stable JSON schema the generator reads.Change
CodexProvider.ts: models whosemodel/listentry lists a programme other thanstandardinavailableAccessPrograms.cyberget a "Cyber Access" select. Its options are "Automatic" (the default) plus the programmes Codex lists. Other models are unchanged.CodexAdapterV2.ts:buildCodexTurnStartParamssends the chosen programme on every turn. "Automatic" omits the field, so Codex keeps its current behaviour.client.tsand the adapter's turn/start schema: addcyberAccessProgramwithSchema.fieldsAssign, as T3 already does forcollaborationModeandadditionalContext. Without this, the client strips the field before it reaches Codex. No generated code changes.CodexProvider.ts: a bare custom Codex model borrows the first built-in model's options, but not Cyber Access, because Daybreak eligibility is per model.docs/user/providers-codex.md: a short "Use Daybreak" section.delegate_taskchecks options against the model's option list, so agents can set the option with no further change.Scope and approval
Proposed in #26995.
This is a configuration option for a capability Codex already has. The app server accepts
cyberAccessProgram, the Codex CLI exposes the same setting as/daybreak, and T3 already decodesavailableAccessProgramsfrommodel/list. The option controls only that one turn parameter, and it appears only on models where Codex offers a Daybreak programme.Verification
Focused tests:
CodexProvider.test.ts: there is no select for a standard-only model, and the expected options appear for["standard", "daybreakBlue"].CodexProvider.test.ts: a custom model that borrows a Daybreak-eligible model's options gets reasoning but not Cyber Access. It fails without the fix.CodexAdapterV2.test.ts: the field is omitted when nothing or "Automatic" is chosen, and set forstandardanddaybreakBlue.CodexAdapterV2.test.tsreplay test:cyberAccessProgram: "daybreakBlue"reaches the outboundturn/startframe. With theclient.tschange reverted, this test fails because the client strips the field.Rebased onto
mainatd92c437baa19; current head ise960980a5f6c.git range-diffconfirms both original commits are unchanged by the rebase, with authorship preserved.vp run check:changedpassed: format, lint, both knip checks, GraphQL generation, typecheck (4 packages), and 5 test files (137 tests).Browser verification on the rebased branch: GPT-6-Luna offers Automatic, Standard, and Daybreak Blue; selecting Daybreak Blue survives a reload. GPT-6.1-Sol keeps its existing options without Cyber Access. Captures compare current
mainand the rebased branch using the same isolated environment and 1280 × 800 viewport.Original implementation verification (not repeated during this rebase): live checks against Codex 0.164.0 with a ChatGPT account approved for Daybreak Blue:
model/listreturned["standard", "daybreakBlue"]for gpt-6-sol, gpt-6-luna and the gpt-5.6 models,["daybreakBlue"]for gpt-daybreak-blue-latest, and["standard"]for gpt-6.1-sol, gpt-6.1-terra and gpt-6-astra.cyberAccessProgram: "daybreakBlue"completed normally.403 Daybreak isn't available for this model, so the backend reads the field. This is why the select only appears where Codex lists a Daybreak programme.Not checked:
updateSubagentSelectionrebuilds onlyreasoningEffortandserviceTier, so a native subagent spawned mid-turn does not inherit the choice. I left that out of this PR to keep it to one problem.Before / after UI evidence
Matching captures from the same isolated development environment at 1280 × 800. Before:
mainatd92c437baa19. After: rebased PR ate960980a5f6c.Eligible model: GPT-6-Luna
Before: the model options have reasoning, service tier, and permissions, with no Cyber Access choice.
After: Cyber Access offers Automatic, Standard, and Daybreak Blue. Daybreak Blue is selected and survives a page reload.
Unsupported model: GPT-6.1-Sol
Before: the model options show reasoning, service tier, and permissions.
After: the same controls remain, with no Cyber Access choice.
Original implementation by Martin Meredith, assisted by Claude Opus 5.5 in Claude Code. Rebased and verified with gpt-6.1-sol in the Codex harness through T3 Code.
🤖 Generated with Claude Code