Commit Graph

3 Commits

  • Apply argument comment lint across codex-rs (#14652)
    ## Why
    
    Once the repo-local lint exists, `codex-rs` needs to follow the
    checked-in convention and CI needs to keep it from drifting. This commit
    applies the fallback `/*param*/` style consistently across existing
    positional literal call sites without changing those APIs.
    
    The longer-term preference is still to avoid APIs that require comments
    by choosing clearer parameter types and call shapes. This PR is
    intentionally the mechanical follow-through for the places where the
    existing signatures stay in place.
    
    After rebasing onto newer `main`, the rollout also had to cover newly
    introduced `tui_app_server` call sites. That made it clear the first cut
    of the CI job was too expensive for the common path: it was spending
    almost as much time installing `cargo-dylint` and re-testing the lint
    crate as a representative test job spends running product tests. The CI
    update keeps the full workspace enforcement but trims that extra
    overhead from ordinary `codex-rs` PRs.
    
    ## What changed
    
    - keep a dedicated `argument_comment_lint` job in `rust-ci`
    - mechanically annotate remaining opaque positional literals across
    `codex-rs` with exact `/*param*/` comments, including the rebased
    `tui_app_server` call sites that now fall under the lint
    - keep the checked-in style aligned with the lint policy by using
    `/*param*/` and leaving string and char literals uncommented
    - cache `cargo-dylint`, `dylint-link`, and the relevant Cargo
    registry/git metadata in the lint job
    - split changed-path detection so the lint crate's own `cargo test` step
    runs only when `tools/argument-comment-lint/*` or `rust-ci.yml` changes
    - continue to run the repo wrapper over the `codex-rs` workspace, so
    product-code enforcement is unchanged
    
    Most of the code changes in this commit are intentionally mechanical
    comment rewrites or insertions driven by the lint itself.
    
    ## Verification
    
    - `./tools/argument-comment-lint/run.sh --workspace`
    - `cargo test -p codex-tui-app-server -p codex-tui`
    - parsed `.github/workflows/rust-ci.yml` locally with PyYAML
    
    ---
    
    * -> #14652
    * #14651
  • app-server: propagate nested experimental gating for AskForApproval::Reject (#14191)
    ## Summary
    This change makes `AskForApproval::Reject` gate correctly anywhere it
    appears inside otherwise-stable app-server protocol types.
    
    Previously, experimental gating for `approval_policy: Reject` was
    handled with request-specific logic in `ClientRequest` detection. That
    covered a few request params types, but it did not generalize to other
    nested uses such as `ProfileV2`, `Config`, `ConfigReadResponse`, or
    `ConfigRequirements`.
    
    This PR replaces that ad hoc handling with a generic nested experimental
    propagation mechanism.
    
    ## Testing
    
    seeing this when run app-server-test-client without experimental api
    enabled:
    ```
     initialize response: InitializeResponse { user_agent: "codex-toy-app-server/0.0.0 (Mac OS 26.3.1; arm64) vscode/2.4.36 (codex-toy-app-server; 0.0.0)" }
    > {
    >   "id": "50244f6a-270a-425d-ace0-e9e98205bde7",
    >   "method": "thread/start",
    >   "params": {
    >     "approvalPolicy": {
    >       "reject": {
    >         "mcp_elicitations": false,
    >         "request_permissions": true,
    >         "rules": false,
    >         "sandbox_approval": true
    >       }
    >     },
    >     "baseInstructions": null,
    >     "config": null,
    >     "cwd": null,
    >     "developerInstructions": null,
    >     "dynamicTools": null,
    >     "ephemeral": null,
    >     "experimentalRawEvents": false,
    >     "mockExperimentalField": null,
    >     "model": null,
    >     "modelProvider": null,
    >     "persistExtendedHistory": false,
    >     "personality": null,
    >     "sandbox": null,
    >     "serviceName": null
    >   }
    > }
    < {
    <   "error": {
    <     "code": -32600,
    <     "message": "askForApproval.reject requires experimentalApi capability"
    <   },
    <   "id": "50244f6a-270a-425d-ace0-e9e98205bde7"
    < }
    [verified] thread/start rejected approvalPolicy=Reject without experimentalApi
    ```
    
    ---------
    
    Co-authored-by: celia-oai <celia@openai.com>
  • feat: experimental flags (#10231)
    ## Problem being solved
    - We need a single, reliable way to mark app-server API surface as
    experimental so that:
      1. the runtime can reject experimental usage unless the client opts in
    2. generated TS/JSON schemas can exclude experimental methods/fields for
    stable clients.
    
    Right now that’s easy to drift or miss when done ad-hoc.
    
    ## How to declare experimental methods and fields
    - **Experimental method**: add `#[experimental("method/name")]` to the
    `ClientRequest` variant in `client_request_definitions!`.
    - **Experimental field**: on the params struct, derive `ExperimentalApi`
    and annotate the field with `#[experimental("method/name.field")]` + set
    `inspect_params: true` for the method variant so
    `ClientRequest::experimental_reason()` inspects params for experimental
    fields.
    
    ## How the macro solves it
    - The new derive macro lives in
    `codex-rs/codex-experimental-api-macros/src/lib.rs` and is used via
    `#[derive(ExperimentalApi)]` plus `#[experimental("reason")]`
    attributes.
    - **Structs**:
    - Generates `ExperimentalApi::experimental_reason(&self)` that checks
    only annotated fields.
      - The “presence” check is type-aware:
        - `Option<T>`: `is_some_and(...)` recursively checks inner.
        - `Vec`/`HashMap`/`BTreeMap`: must be non-empty.
        - `bool`: must be `true`.
        - Other types: considered present (returns `true`).
    - Registers each experimental field in an `inventory` with `(type_name,
    serialized field name, reason)` and exposes `EXPERIMENTAL_FIELDS` for
    that type. Field names are converted from `snake_case` to `camelCase`
    for schema/TS filtering.
    - **Enums**:
    - Generates an exhaustive `match` returning `Some(reason)` for annotated
    variants and `None` otherwise (no wildcard arm).
    - **Wiring**:
    - Runtime gating uses `ExperimentalApi::experimental_reason()` in
    `codex-rs/app-server/src/message_processor.rs` to reject requests unless
    `InitializeParams.capabilities.experimental_api == true`.
    - Schema/TS export filters use the inventory list and
    `EXPERIMENTAL_CLIENT_METHODS` from `client_request_definitions!` to
    strip experimental methods/fields when `experimental_api` is false.