2 Commits

• config: enforce enterprise feature requirements (#13388)

  ## Why
  
  Enterprises can already constrain approvals, sandboxing, and web search
  through `requirements.toml` and MDM, but feature flags were still only
  configurable as managed defaults. That meant an enterprise could suggest
  feature values, but it could not actually pin them.
  
  This change closes that gap and makes enterprise feature requirements
  behave like the other constrained settings. The effective feature set
  now stays consistent with enterprise requirements during config load,
  when config writes are validated, and when runtime code mutates feature
  flags later in the session.
  
  It also tightens the runtime API for managed features. `ManagedFeatures`
  now follows the same constraint-oriented shape as `Constrained<T>`
  instead of exposing panic-prone mutation helpers, and production code
  can no longer construct it through an unconstrained `From<Features>`
  path.
  
  The PR also hardens the `compact_resume_fork` integration coverage on
  Windows. After the feature-management changes,
  `compact_resume_after_second_compaction_preserves_history` was
  overflowing the libtest/Tokio thread stacks on Windows, so the test now
  uses an explicit larger-stack harness as a pragmatic mitigation. That
  may not be the ideal root-cause fix, and it merits a parallel
  investigation into whether part of the async future chain should be
  boxed to reduce stack pressure instead.
  
  ## What Changed
  
  Enterprises can now pin feature values in `requirements.toml` with the
  requirements-side `features` table:
  
  ```toml
  [features]
  personality = true
  unified_exec = false
  ```
  
  Only canonical feature keys are allowed in the requirements `features`
  table; omitted keys remain unconstrained.
  
  - Added a requirements-side pinned feature map to
  `ConfigRequirementsToml`, threaded it through source-preserving
  requirements merge and normalization in `codex-config`, and made the
  TOML surface use `[features]` (while still accepting legacy
  `[feature_requirements]` for compatibility).
  - Exposed `featureRequirements` from `configRequirements/read`,
  regenerated the JSON/TypeScript schema artifacts, and updated the
  app-server README.
  - Wrapped the effective feature set in `ManagedFeatures`, backed by
  `ConstrainedWithSource<Features>`, and changed its API to mirror
  `Constrained<T>`: `can_set(...)`, `set(...) -> ConstraintResult<()>`,
  and result-returning `enable` / `disable` / `set_enabled` helpers.
  - Removed the legacy-usage and bulk-map passthroughs from
  `ManagedFeatures`; callers that need those behaviors now mutate a plain
  `Features` value and reapply it through `set(...)`, so the constrained
  wrapper remains the enforcement boundary.
  - Removed the production loophole for constructing unconstrained
  `ManagedFeatures`. Non-test code now creates it through the configured
  feature-loading path, and `impl From<Features> for ManagedFeatures` is
  restricted to `#[cfg(test)]`.
  - Rejected legacy feature aliases in enterprise feature requirements,
  and return a load error when a pinned combination cannot survive
  dependency normalization.
  - Validated config writes against enterprise feature requirements before
  persisting changes, including explicit conflicting writes and
  profile-specific feature states that normalize into invalid
  combinations.
  - Updated runtime and TUI feature-toggle paths to use the constrained
  setter API and to persist or apply the effective post-constraint value
  rather than the requested value.
  - Updated the `core_test_support` Bazel target to include the bundled
  core model-catalog fixtures in its runtime data, so helper code that
  resolves `core/models.json` through runfiles works in remote Bazel test
  environments.
  - Renamed the core config test coverage to emphasize that effective
  feature values are normalized at runtime, while conflicting persisted
  config writes are rejected.
  - Ran `compact_resume_after_second_compaction_preserves_history` inside
  an explicit 8 MiB test thread and Tokio runtime worker stack, following
  the existing larger-stack integration-test pattern, to keep the Windows
  `compact_resume_fork` test slice from aborting while a parallel
  investigation continues into whether some of the underlying async
  futures should be boxed.
  
  ## Verification
  
  - `cargo test -p codex-config`
  - `cargo test -p codex-core feature_requirements_ -- --nocapture`
  - `cargo test -p codex-core
  load_requirements_toml_produces_expected_constraints -- --nocapture`
  - `cargo test -p codex-core
  compact_resume_after_second_compaction_preserves_history -- --nocapture`
  - `cargo test -p codex-core compact_resume_fork -- --nocapture`
  - Re-ran the built `codex-core` `tests/all` binary with
  `RUST_MIN_STACK=262144` for
  `compact_resume_after_second_compaction_preserves_history` to confirm
  the explicit-stack harness fixes the deterministic low-stack repro.
  - `cargo test -p codex-core`
  - This still fails locally in unrelated integration areas that expect
  the `codex` / `test_stdio_server` binaries or hit existing `search_tool`
  wiremock mismatches.
  
  ## Docs
  
  `developers.openai.com/codex` should document the requirements-side
  `[features]` table for enterprise and MDM-managed configuration,
  including that it only accepts canonical feature keys and that
  conflicting config writes are rejected.

  Michael Bolin · 2026-03-04 04:40:22 +00:00
  bfff0c729f
• feat: add support for building with Bazel (#8875)

  This PR configures Codex CLI so it can be built with
  [Bazel](https://bazel.build) in addition to Cargo. The `.bazelrc`
  includes configuration so that remote builds can be done using
  [BuildBuddy](https://www.buildbuddy.io).
  
  If you are familiar with Bazel, things should work as you expect, e.g.,
  run `bazel test //... --keep-going` to run all the tests in the repo,
  but we have also added some new aliases in the `justfile` for
  convenience:
  
  - `just bazel-test` to run tests locally
  - `just bazel-remote-test` to run tests remotely (currently, the remote
  build is for x86_64 Linux regardless of your host platform). Note we are
  currently seeing the following test failures in the remote build, so we
  still need to figure out what is happening here:
  
  ```
  failures:
      suite::compact::manual_compact_twice_preserves_latest_user_messages
      suite::compact_resume_fork::compact_resume_after_second_compaction_preserves_history
      suite::compact_resume_fork::compact_resume_and_fork_preserve_model_history_view
  ```
  
  - `just build-for-release` to build release binaries for all
  platforms/architectures remotely
  
  To setup remote execution:
  - [Create a buildbuddy account](https://app.buildbuddy.io/) (OpenAI
  employees should also request org access at
  https://openai.buildbuddy.io/join/ with their `@openai.com` email
  address.)
  - [Copy your API key](https://app.buildbuddy.io/docs/setup/) to
  `~/.bazelrc` (add the line `build
  --remote_header=x-buildbuddy-api-key=YOUR_KEY`)
  - Use `--config=remote` in your `bazel` invocations (or add `common
  --config=remote` to your `~/.bazelrc`, or use the `just` commands)
  
  ## CI
  
  In terms of CI, this PR introduces `.github/workflows/bazel.yml`, which
  uses Bazel to run the tests _locally_ on Mac and Linux GitHub runners
  (we are working on supporting Windows, but that is not ready yet). Note
  that the failures we are seeing in `just bazel-remote-test` do not occur
  on these GitHub CI jobs, so everything in `.github/workflows/bazel.yml`
  is green right now.
  
  The `bazel.yml` uses extra config in `.github/workflows/ci.bazelrc` so
  that macOS CI jobs build _remotely_ on Linux hosts (using the
  `docker://docker.io/mbolin491/codex-bazel` Docker image declared in the
  root `BUILD.bazel`) using cross-compilation to build the macOS
  artifacts. Then these artifacts are downloaded locally to GitHub's macOS
  runner so the tests can be executed natively. This is the relevant
  config that enables this:
  
  ```
  common:macos --config=remote
  common:macos --strategy=remote
  common:macos --strategy=TestRunner=darwin-sandbox,local
  ```
  
  Because of the remote caching benefits we get from BuildBuddy, these new
  CI jobs can be extremely fast! For example, consider these two jobs that
  ran all the tests on Linux x86_64:
  
  - Bazel 1m37s
  https://github.com/openai/codex/actions/runs/20861063212/job/59940545209?pr=8875
  - Cargo 9m20s
  https://github.com/openai/codex/actions/runs/20861063192/job/59940559592?pr=8875
  
  For now, we will continue to run both the Bazel and Cargo jobs for PRs,
  but once we add support for Windows and running Clippy, we should be
  able to cutover to using Bazel exclusively for PRs, which should still
  speed things up considerably. We will probably continue to run the Cargo
  jobs post-merge for commits that land on `main` as a sanity check.
  
  Release builds will also continue to be done by Cargo for now.
  
  Earlier attempt at this PR: https://github.com/openai/codex/pull/8832
  Earlier attempt to add support for Buck2, now abandoned:
  https://github.com/openai/codex/pull/8504
  
  ---------
  
  Co-authored-by: David Zbarsky <dzbarsky@gmail.com>
  Co-authored-by: Michael Bolin <mbolin@openai.com>

  zbarsky-openai · 2026-01-09 11:09:43 -08:00
  2a06d64bc9