Skip to content

[Feature]: Support Daybreak in Codex CLI and expose Daybreak availability in the model catalog #7226

Open
Open
[Feature]: Support Daybreak in Codex CLI and expose Daybreak availability in the model catalog#7226
Labels
catalogModel catalog, slugs, visibility, routed entriesenhancementNew feature or requestneeds-infoWaiting on reporter for a concrete spec or reproduction

Description

@heegong
heegong
opened on Oct 16, 2026

Area

Catalog / models

What are you trying to accomplish?

I want to enable and use Daybreak (Trusted Access for Cyber) in Codex CLI with OpenCodex, following OpenAI's official guide: Customer guide: Using Daybreak in Codex CLI.

What prevents this today?

When running the /daybreak command in interactive mode, it fails with the following message:

Daybreak availability could not be determined from the connected host's model catalog

According to the official specification, Codex CLI determines Daybreak availability by inspecting the host's model catalog (model/list response for availableAccessPrograms.cyber such as daybreakBlue, daybreakRed, or standard). Currently, OpenCodex does not appear to expose this metadata in its model catalog or handle the corresponding Daybreak configuration parameters (daybreak = true in config.toml and cyberAccessProgram in turn/start).

What should OpenCodex do?

Currently, there is no known workaround to bypass the model catalog check in interactive mode when connected to OpenCodex, as the CLI relies on the host's catalog response to verify Daybreak eligibility.

Example usage or interface

  1. Interactive CLI:
    Running /daybreak in an interactive session should properly detect Daybreak availability from the connected host's model catalog and allow toggling Daybreak on/off.
  2. Headless CLI / Config (~/.codex/config.toml): 
    daybreak = true
    Or overriding per invocation: 
    codex -c daybreak=true ...
  3. App Server / Model Catalog & Turn Parameters:
    • Expose availableAccessPrograms.cyber in the model/list catalog response.
    • Accept cyberAccessProgram ("daybreakBlue" | "daybreakRed" | "standard") in turn/start requests when experimentalApi capability is enabled.

Alternatives or workarounds

Currently, there is no known workaround to bypass the model catalog check in interactive mode when connected to OpenCodex, as the CLI relies on the host's catalog response to verify Daybreak eligibility.

Additional context

Checks

  • I searched existing issues and documentation.
  • This request describes a concrete OpenCodex workflow rather than merely naming a desired technology.
  • I removed secrets and personal data.

Activity

  1. heegong
    added
    enhancementNew feature or request
    on Oct 16, 2026

  2. Ingwannu commented on Oct 16, 2026

    @Ingwannu
    Ingwannu
    on Oct 16, 2026
    Owner

    Current source already preserves account-scoped Daybreak metadata: #5898 and #5907 project upstream available_access_programs into native catalog rows. At inspected dev@4ae49360b7, src/codex/catalog/access-programs.ts uses confirmed main-account evidence for bare native rows and the mapped account's evidence for selector rows. Routed/combo aliases cannot inherit another account's grant.

    That does not establish that your connected host has a confirmed eligible roster. Please provide OpenCodex and Codex CLI versions, local versus remote-host mode, the selected model ID and provider kind, and only that model's redacted model/list entry (id and availableAccessPrograms). If available, compare the same row in the generated catalog (slug and available_access_programs). Do not post authentication files, account IDs, tokens, or the full catalog.

    The app-server camelCase fields and Responses wire fields are separate contracts. OpenAI's API documentation uses access_programs.cyber with snake_case program values; selecting a program does not grant access. We must preserve the host/account evidence rather than advertise Daybreak on every routed model.

    Keeping this open for the exact missing-metadata case; no client session or live configuration was changed or tested in this pass.

  3. Ingwannu
    added
    needs-infoWaiting on reporter for a concrete spec or reproduction
    on Oct 16, 2026
  4. github-actions
    added
    catalogModel catalog, slugs, visibility, routed entries
    on Oct 16, 2026

  5. heegong commented on Oct 16, 2026

    @heegong
    heegong
    on Oct 16, 2026
    Author

    To clarify: my account already has Daybreak active and confirmed upstream. When running vanilla Codex CLI (v0.163.0) directly without OpenCodex, the /daybreak command and toggle work completely fine.

    This issue specifically occurs only when routing through OpenCodex with Codex CLI v0.163.0 (released today), which introduced the interactive /daybreak command (a TUI toggle switch to turn Daybreak on and off directly within the CLI). Under OpenCodex, running /daybreak immediately fails with:

    Daybreak availability could not be determined from the connected host's model catalog

    Even though OpenCodex projects available_access_programs into native catalog rows (#5898 / #5907), the new /daybreak interactive toggle in Codex CLI v0.163.0 isn't recognizing the eligibility from OpenCodex's exposed catalog / app-server response (likely expecting the updated v0.163.0 contract such as camelCase availableAccessPrograms.cyber in model/list and cyberAccessProgram in turn/start).

    Environment Details

    • Codex CLI version: v0.163.0 (works natively without OpenCodex)
    • OpenCodex version: latest
    • Account status: Daybreak already enabled/active on the main account
    • Host mode: Local
    • Selected model ID: gpt-5.6-sol
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    catalogModel catalog, slugs, visibility, routed entriesenhancementNew feature or requestneeds-infoWaiting on reporter for a concrete spec or reproduction

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions