Commit Graph

7 Commits

  • feat: support allowed_sandbox_modes in requirements.toml (#8298)
    This adds support for `allowed_sandbox_modes` in `requirements.toml` and
    provides legacy support for constraining sandbox modes in
    `managed_config.toml`. This is converted to `Constrained<SandboxPolicy>`
    in `ConfigRequirements` and applied to `Config` such that constraints
    are enforced throughout the harness.
    
    Note that, because `managed_config.toml` is deprecated, we do not add
    support for the new `external-sandbox` variant recently introduced in
    https://github.com/openai/codex/pull/8290. As noted, that variant is not
    supported in `config.toml` today, but can be configured programmatically
    via app server.
  • feat: Constrain values for approval_policy (#7778)
    Constrain `approval_policy` through new `admin_policy` config.
    
    This PR will:
    1. Add a `admin_policy` section to config, with a single field (for now)
    `allowed_approval_policies`. This list constrains the set of
    user-settable `approval_policy`s.
    2. Introduce a new `Constrained<T>` type, which combines a current value
    and a validator function. The validator function ensures disallowed
    values are not set.
    3. Change the type of `approval_policy` on `Config` and
    `SessionConfiguration` from `AskForApproval` to
    `Constrained<AskForApproval>`. The validator function is set by the
    values passed into `allowed_approval_policies`.
    4. `GenericDisplayRow`: add a `disabled_reason: Option<String>`. When
    set, it disables selection of the value and indicates as such in the
    menu. This also makes it unselectable with arrow keys or numbers. This
    is used in the `/approvals` menu.
    
    Follow ups are:
    1. Do the same thing to `sandbox_policy`.
    2. Propagate the allowed set of values through app-server for the
    extension (though already this should prevent app-server from setting
    this values, it's just that we want to disable UI elements that are
    unsettable).
    
    Happy to split this PR up if you prefer, into the logical numbered areas
    above. Especially if there are parts we want to gavel on separately
    (e.g. admin_policy).
    
    Disabled full access:
    <img width="1680" height="380" alt="image"
    src="https://github.com/user-attachments/assets/1fb61c8c-1fcb-4dc4-8355-2293edb52ba0"
    />
    
    Disabled `--yolo` on startup:
    <img width="749" height="76" alt="image"
    src="https://github.com/user-attachments/assets/0a1211a0-6eb1-40d6-a1d7-439c41e94ddb"
    />
    
    CODEX-4087
  • make model optional in config (#7769)
    - Make Config.model optional and centralize default-selection logic in
    ModelsManager, including a default_model helper (with
    codex-auto-balanced when available) so sessions now carry an explicit
    chosen model separate from the base config.
    - Resolve `model` once in `core` and `tui` from config. Then store the
    state of it on other structs.
    - Move refreshing models to be before resolving the default model
  • remove model_family from `config (#7571)
    - Remove `model_family` from `config`
    - Make sure to still override config elements related to `model_family`
    like supporting reasoning
  • Fix/correct reasoning display (#6749)
    This closes #6748 by implementing fallback to
    `model_family.default_reasoning_effort` in `reasoning_effort` display of
    `/status` when no `model_reasoning_effort` is set in the configuration.
    
    ## common/src/config_summary.rs
    
    - `create_config_summary_entries` now fills the "reasoning effort" entry
    with the explicit `config.model_reasoning_effort` when present and falls
    back to `config.model_family.default_reasoning_effort` when it is
    `None`, instead of emitting the literal string `none`.
    - This ensures downstream consumers such as `tui/src/status/helpers.rs`
    continue to work unchanged while automatically picking up model-family
    defaults when the user has not selected a reasoning effort.
    
    ## tui/src/status/helpers.rs / core/src/model_family.rs
    
    `ModelFamily::default_reasoning_effort` metadata is set to `medium` for
    both `gpt-5*-codex` and `gpt-5` models following the default behaviour
    of the API and recommendation of the codebase:
    - per https://platform.openai.com/docs/api-reference/responses/create
    `gpt-5` defaults to `medium` reasoning when no preset is passed
    - there is no mention of the preset for `gpt-5.1-codex` in the API docs
    but `medium` is the default setting for `gpt-5.1-codex` as per
    `codex-rs/tui/src/chatwidget/snapshots/codex_tui__chatwidget__tests__model_reasoning_selection_popup.snap`
    
    ---------
    
    Signed-off-by: lionelchg <lionel.cheng@hotmail.fr>
    Co-authored-by: Eric Traut <etraut@openai.com>
  • feat: reasoning effort as optional (#3527)
    Allow the reasoning effort to be optional
  • [feat] add /status slash command (#1873)
    - Added a `/status` command, which will be useful when we update the
    home screen to print less status.
    - Moved `create_config_summary_entries` to common since it's used in a
    few places.
    - Noticed we inconsistently had periods in slash command descriptions
    and just removed them everywhere.
    - Noticed the diff description was overflowing so made it shorter.