8 Commits

  • Enable V8 sandboxing for source-built builds (#21146)
    ## Summary
    
    This is the first PR in the V8 in-process sandboxing rollout.
    
    It adds the build-system and Rust feature plumbing needed to support
    sandboxed V8 builds, then enables sandboxing by default for the
    source-built Bazel V8 path that we control directly. It deliberately
    keeps the published `rusty_v8` artifact workflows on their current
    non-sandboxed contract so this PR can land and ship independently before
    we change any released artifacts.
    
    ## Rollout plan
    
    - [x] **PR 1: land sandbox plumbing and default source-built Bazel V8 to
    sandboxed mode**
    
    - [ ] **PR 2: publish sandbox-enabled release artifacts and add
    compatibility validation**
    - Produce sandboxed artifact pairs for every released Cargo target that
    does not already use the source-built Bazel path.
    - Add CI coverage that consumes those sandboxed artifacts and verifies:
        - `codex-v8-poc` reports sandbox enabled
        - `codex-code-mode` builds/tests against the sandboxed path
    
    - [ ] **PR 3: switch release consumers to sandboxed artifacts by
    default**
      - Update released artifact selectors/checksums.
    - Enable the Rust `v8_enable_sandbox` feature in the default release
    path.
    - Make the sandboxed artifact family the normal path for published
    builds.
    
    - [ ] **PR 4: remove rollout-only compatibility paths**
    - Remove the temporary non-sandbox release compatibility config once the
    new default has shipped and baked.
      - Keep the invariant tests permanently.
  • ci: stop running rust CI with --all-features (#16473)
    ## Why
    
    Now that workspace crate features have been removed and
    `.github/scripts/verify_cargo_workspace_manifests.py` hard-bans new
    ones, Rust CI should stop building and testing with `--all-features`.
    
    Keeping `--all-features` in CI no longer buys us meaningful coverage for
    `codex-rs`, but it still makes the workflow look like we rely on Cargo
    feature permutations that we are explicitly trying to eliminate. It also
    leaves stale examples in the repo that suggest `--all-features` is a
    normal or recommended way to run the workspace.
    
    ## What changed
    
    - removed `--all-features` from the Rust CI `cargo chef cook`, `cargo
    clippy`, and `cargo nextest` invocations in
    `.github/workflows/rust-ci-full.yml`
    - updated the `just test` guidance in `justfile` to reflect that
    workspace crate features are banned and there should be no need to add
    `--all-features`
    - updated the multiline command example and snapshot in
    `codex-rs/tui/src/history_cell.rs` to stop rendering `cargo test
    --all-features --quiet`
    - tightened the verifier docstring in
    `.github/scripts/verify_cargo_workspace_manifests.py` so it no longer
    talks about temporary remaining exceptions
    
    ## How tested
    
    - `python3 .github/scripts/verify_cargo_workspace_manifests.py`
    - `cargo test -p codex-tui`
  • otel: remove the last workspace crate feature (#16469)
    ## Why
    
    `codex-otel` still carried `disable-default-metrics-exporter`, which was
    the last remaining workspace crate feature.
    
    We are removing workspace crate features because they do not fit our
    current build model well:
    
    - our Bazel setup does not honor crate features today, which can let
    feature-gated issues go unnoticed
    - they create extra crate build permutations that we want to avoid
    
    For this case, the feature was only being used to keep the built-in
    Statsig metrics exporter off in test and debug-oriented contexts. This
    repo already treats `debug_assertions` as the practical proxy for that
    class of behavior, so OTEL should follow the same convention instead of
    keeping a dedicated crate feature alive.
    
    ## What changed
    
    - removed `disable-default-metrics-exporter` from
    `codex-rs/otel/Cargo.toml`
    - removed the `codex-otel` dev-dependency feature activation from
    `codex-rs/core/Cargo.toml`
    - changed `codex-rs/otel/src/config.rs` so the built-in
    `OtelExporter::Statsig` default resolves to `None` when
    `debug_assertions` is enabled, with a focused unit test covering that
    behavior
    - removed the final feature exceptions from
    `.github/scripts/verify_cargo_workspace_manifests.py`, so workspace
    crate features are now hard-banned instead of temporarily allowlisted
    - expanded the verifier error message to explain the Bazel mismatch and
    build-permutation cost behind that policy
    
    ## How tested
    
    - `python3 .github/scripts/verify_cargo_workspace_manifests.py`
    - `cargo test -p codex-otel`
    - `cargo test -p codex-core
    metrics_exporter_defaults_to_statsig_when_missing`
    - `cargo test -p codex-app-server app_server_default_analytics_`
    - `just bazel-lock-check`
  • tui: remove the voice-input crate feature (#16467)
    ## Why
    
    `voice-input` is the only remaining TUI crate feature, but it is also a
    default feature and nothing in the workspace selects it explicitly. In
    practice it is just acting as a proxy for platform support, which is
    better expressed with target-specific dependencies and cfgs.
    
    ## What changed
    
    - remove the `voice-input` feature from `codex-tui`
    - make `cpal` a normal non-Linux target dependency
    - replace the feature-based voice and audio cfgs with pure
    Linux-vs-non-Linux cfgs
    - shrink the workspace-manifest verifier allowlist to remove the
    remaining `codex-tui` exception
    
    ## How tested
    
    - `python3 .github/scripts/verify_cargo_workspace_manifests.py`
    - `cargo test -p codex-tui`
    - `just bazel-lock-check`
    - `just argument-comment-lint -p codex-tui`
  • tui: remove debug/test-only crate features (#16457)
    ## Why
    
    The remaining `vt100-tests` and `debug-logs` features in `codex-tui`
    were only gating test-only and debug-only behavior. Those feature
    toggles add Cargo and Bazel permutations without buying anything, and
    they make it easier for more crate features to linger in the workspace.
    
    ## What changed
    
    - delete `vt100-tests` and `debug-logs` from `codex-tui`
    - always compile the VT100 integration tests in the TUI test target
    instead of hiding them behind a Cargo feature
    - remove the unused textarea debug logging branch instead of replacing
    it with another gate
    - add the required argument-comment annotations in the VT100 tests now
    that Bazel sees those callsites during linting
    - shrink the manifest verifier allowlist again so only the remaining
    real feature exceptions stay permitted
    
    ## How tested
    
    - `cargo test -p codex-tui`
    - `just argument-comment-lint -p codex-tui`
  • cloud-tasks: split the mock client out of cloud-tasks-client (#16456)
    ## Why
    
    `codex-cloud-tasks-client` was mixing two different roles: the real HTTP
    client and the mock implementation used by tests and local mock mode.
    Keeping both in the same crate forced Cargo feature toggles and Bazel
    `crate_features` just to pick an implementation.
    
    This change keeps `codex-cloud-tasks-client` focused on the shared API
    surface and real backend client, and moves the mock implementation into
    its own crate so we can remove those feature permutations cleanly.
    
    ## What changed
    
    - add a new `codex-cloud-tasks-mock-client` crate that owns `MockClient`
    - remove the `mock` and `online` features from
    `codex-cloud-tasks-client`
    - make `codex-cloud-tasks-client` unconditionally depend on
    `codex-backend-client` and export `HttpClient` directly
    - gate the mock-mode path in `codex-cloud-tasks` behind
    `#[cfg(debug_assertions)]`, so release builds always initialize the real
    HTTP client
    - update `codex-cloud-tasks` and its tests to use
    `codex-cloud-tasks-mock-client::MockClient` wherever mock behavior is
    needed
    - remove the matching Bazel `crate_features` override and shrink the
    manifest verifier allowlist accordingly
    
    ## How tested
    
    - `cargo test -p codex-cloud-tasks-client`
    - `cargo test -p codex-cloud-tasks-mock-client`
    - `cargo test -p codex-cloud-tasks`
    
    ---
    [//]: # (BEGIN SAPLING FOOTER)
    Stack created with [Sapling](https://sapling-scm.com). Best reviewed
    with [ReviewStack](https://reviewstack.dev/openai/codex/pull/16456).
    * #16457
    * __->__ #16456
  • ci: block new workspace crate features (#16455)
    ## Why
    
    We already enforce workspace metadata and lint inheritance for
    `codex-rs` manifests, but we still allow new crate features to slip into
    the workspace. That makes it too easy to add more Cargo-only feature
    permutations while we are trying to eliminate them.
    
    ## What changed
    
    - extend `verify_cargo_workspace_manifests.py` to reject new
    `[features]` tables in workspace crates
    - reject new optional dependencies that create implicit crate features
    - reject new workspace-to-workspace `features = [...]` activations and
    `default-features = false`
    - add a narrow temporary allowlist for the existing feature-bearing
    manifests and internal feature activations
    - make the allowlist self-shrinking so a follow-up removal has to delete
    its corresponding exception
    
    
    ---
    [//]: # (BEGIN SAPLING FOOTER)
    Stack created with [Sapling](https://sapling-scm.com). Best reviewed
    with [ReviewStack](https://reviewstack.dev/openai/codex/pull/16455).
    * #16457
    * #16456
    * __->__ #16455
  • ci: verify codex-rs Cargo manifests inherit workspace settings (#16353)
    ## Why
    
    Bazel clippy now catches lints that `cargo clippy` can still miss when a
    crate under `codex-rs` forgets to opt into workspace lints. The concrete
    example here was `codex-rs/app-server/tests/common/Cargo.toml`: Bazel
    flagged a clippy violation in `models_cache.rs`, but Cargo did not
    because that crate inherited workspace package metadata without
    declaring `[lints] workspace = true`.
    
    We already mirror the workspace clippy deny list into Bazel after
    [#15955](https://github.com/openai/codex/pull/15955), so we also need a
    repo-side check that keeps every `codex-rs` manifest opted into the same
    workspace settings.
    
    ## What changed
    
    - add `.github/scripts/verify_cargo_workspace_manifests.py`, which
    parses every `codex-rs/**/Cargo.toml` with `tomllib` and verifies:
      - `version.workspace = true`
      - `edition.workspace = true`
      - `license.workspace = true`
      - `[lints] workspace = true`
    - top-level crate names follow the `codex-*` / `codex-utils-*`
    conventions, with explicit exceptions for `windows-sandbox-rs` and
    `utils/path-utils`
    - run that script in `.github/workflows/ci.yml`
    - update the current outlier manifests so the check is enforceable
    immediately
    - fix the newly exposed clippy violations in the affected crates
    (`app-server/tests/common`, `file-search`, `feedback`,
    `shell-escalation`, and `debug-client`)
    
    
    
    
    
    
    ---
    [//]: # (BEGIN SAPLING FOOTER)
    Stack created with [Sapling](https://sapling-scm.com). Best reviewed
    with [ReviewStack](https://reviewstack.dev/openai/codex/pull/16353).
    * #16351
    * __->__ #16353