213 Commits

• feat(app-server): add an --analytics-default-enabled flag (#9118)

  Add a new `codex app-server --analytics-default-enabled` CLI flag that
  controls whether analytics are enabled by default.
  
  Analytics are disabled by default for app-server. Users have to
  explicitly opt in
  via the `analytics` section in the config.toml file.
  
  However, for first-party use cases like the VSCode IDE extension, we
  default analytics
  to be enabled by default by setting this flag. Users can still opt out
  by setting this
  in their config.toml:
  
  ```toml
  [analytics]
  enabled = false
  ```
  
  See https://developers.openai.com/codex/config-advanced/#metrics for
  more details.

  Owen Lin · 2026-01-13 11:59:39 -08:00
  bde734fd1e
• Assemble sandbox/approval/network prompts dynamically (#8961)

  - Add a single builder for developer permissions messaging that accepts
  SandboxPolicy and approval policy. This builder now drives the developer
  “permissions” message that’s injected at session start and any time
  sandbox/approval settings change.
  - Trim EnvironmentContext to only include cwd, writable roots, and
  shell; removed sandbox/approval/network duplication and adjusted XML
  serialization and tests accordingly.
  
  Follow-up: adding a config value to replace the developer permissions
  message for custom sandboxes.

  Ahmed Ibrahim · 2026-01-12 23:12:59 +00:00
  87f7226cca
• fix(app-server): set originator header from initialize (re-revert) (#8988)

  Reapplies https://github.com/openai/codex/pull/8873 which was reverted
  due to merge conflicts

  Owen Lin · 2026-01-09 12:09:30 -08:00
  fbe883318d
• 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
• renaming: task to turn (#8963)
  jif-oai · 2026-01-09 17:31:17 +00:00
  1aed01e99f
• Revert "fix(app-server): set originator header from initialize JSON-RPC request" (#8986)

  Reverts openai/codex#8873

  jif-oai · 2026-01-09 17:00:53 +00:00
  5c380d5b1e
• fix(app-server): set originator header from initialize JSON-RPC request (#8873)

  **Motivation**
  The `originator` header is important for codex-backend’s Responses API
  proxy because it identifies the real end client (codex cli, codex vscode
  extension, codex exec, future IDEs) and is used to categorize requests
  by client for our enterprise compliance API.
  
  Today the `originator` header is set by either:
  - the `CODEX_INTERNAL_ORIGINATOR_OVERRIDE` env var (our VSCode extension
  does this)
  - calling `set_default_originator()` which sets a global immutable
  singleton (`codex exec` does this)
  
  For `codex app-server`, we want the `initialize` JSON-RPC request to set
  that header because it is a natural place to do so. Example:
  ```json
  {
    "method": "initialize",
    "id": 0,
    "params": {
      "clientInfo": {
        "name": "codex_vscode",
        "title": "Codex VS Code Extension",
        "version": "0.1.0"
      }
    }
  }
  ```
  and when app-server receives that request, it can call
  `set_default_originator()`. This is a much more natural interface than
  asking third party developers to set an env var.
  
  One hiccup is that `originator()` reads the global singleton and locks
  in the value, preventing a later `set_default_originator()` call from
  setting it. This would be fine but is brittle, since any codepath that
  calls `originator()` before app-server can process an `initialize`
  JSON-RPC call would prevent app-server from setting it. This was
  actually the case with OTEL initialization which runs on boot, but I
  also saw this behavior in certain tests.
  
  Instead, what we now do is:
  - [unchanged] If `CODEX_INTERNAL_ORIGINATOR_OVERRIDE` env var is set,
  `originator()` would return that value and `set_default_originator()`
  with some other value does NOT override it.
  - [new] If no env var is set, `originator()` would return the default
  value which is `codex_cli_rs` UNTIL `set_default_originator()` is called
  once, in which case it is set to the new value and becomes immutable.
  Later calls to `set_default_originator()` returns
  `SetOriginatorError::AlreadyInitialized`.
  
  **Other notes**
  - I updated `codex_core::otel_init::build_provider` to accepts a service
  name override, and app-server sends a hardcoded `codex_app_server`
  service name to distinguish it from `codex_cli_rs` used by default (e.g.
  TUI).
  
  **Next steps**
  - Update VSCE to set the proper value for `clientInfo.name` on
  `initialize` and drop the `CODEX_INTERNAL_ORIGINATOR_OVERRIDE` env var.
  - Delete support for `CODEX_INTERNAL_ORIGINATOR_OVERRIDE` in codex-rs.

  Owen Lin · 2026-01-09 08:17:13 -08:00
  ea56186c2b
• [chore] move app server tests from chat completion to responses (#8939)

  We are deprecating chat completions. Move all app server tests from chat
  completion to responses.

  Celia Chen · 2026-01-08 22:27:55 +00:00
  be4364bb80
• feat: fork conversation/thread (#8866)

  ## Summary
  - add thread/conversation fork endpoints to the protocol (v1 + v2)
  - implement fork handling in app-server using thread manager and config
  overrides
  - add fork coverage in app-server tests and document `thread/fork` usage

  Anton Panasenko · 2026-01-08 12:54:20 -08:00
  41a317321d
• [fix] app server flaky send_messages test (#8874)

  Fix flakiness of CI test:
  https://github.com/openai/codex/actions/runs/20350530276/job/58473691434?pr=8282
  
  This PR does two things:
  1. move the flakiness test to use responses API instead of chat
  completion API
  2. make mcp_process agnostic to the order of
  responses/notifications/requests that come in, by buffering messages not
  read

  Celia Chen · 2026-01-08 20:41:21 +00:00
  051bf81df9
• [fix] app server flaky thread/resume tests (#8870)

  Fix flakiness of CI tests:
  https://github.com/openai/codex/actions/runs/20350530276/job/58473691443?pr=8282
  
  This PR does two things:
  1. test with responses API instead of chat completions API in
  thread_resume tests;
  2. have a new responses API fixture that mocks out arbitrary numbers of
  responses API calls (including no calls) and have the same repeated
  response.
  
  Tested by CI

  Celia Chen · 2026-01-08 10:17:05 -08:00
  c4af304c77
• feat: add list loaded threads to app server (#8902)
  jif-oai · 2026-01-08 17:48:20 +00:00
  5b7707dfb1
• fix: implement 'Allow this session' for apply_patch approvals (#8451)

  **Summary**
  This PR makes “ApprovalDecision::AcceptForSession / don’t ask again this
  session” actually work for `apply_patch` approvals by caching approvals
  based on absolute file paths in codex-core, properly wiring it through
  app-server v2, and exposing the choice in both TUI and TUI2.
  - This brings `apply_patch` calls to be at feature-parity with general
  shell commands, which also have a "Yes, and don't ask again" option.
  - This also fixes VSCE's "Allow this session" button to actually work.
  
  While we're at it, also split the app-server v2 protocol's
  `ApprovalDecision` enum so execpolicy amendments are only available for
  command execution approvals.
  
  **Key changes**
  - Core: per-session patch approval allowlist keyed by absolute file
  paths
  - Handles multi-file patches and renames/moves by recording both source
  and destination paths for `Update { move_path: Some(...) }`.
  - Extend the `Approvable` trait and `ApplyPatchRuntime` to work with
  multiple keys, because an `apply_patch` tool call can modify multiple
  files. For a request to be auto-approved, we will need to check that all
  file paths have been approved previously.
  - App-server v2: honor AcceptForSession for file changes
  - File-change approval responses now map AcceptForSession to
  ReviewDecision::ApprovedForSession (no longer downgraded to plain
  Approved).
  - Replace `ApprovalDecision` with two enums:
  `CommandExecutionApprovalDecision` and `FileChangeApprovalDecision`
  - TUI / TUI2: expose “don’t ask again for these files this session”
  - Patch approval overlays now include a third option (“Yes, and don’t
  ask again for these files this session (s)”).
      - Snapshot updates for the approval modal.
  
  **Tests added/updated**
  - Core:
  - Integration test that proves ApprovedForSession on a patch skips the
  next patch prompt for the same file
  - App-server:
  - v2 integration test verifying
  FileChangeApprovalDecision::AcceptForSession works properly
  
  **User-visible behavior**
  - When the user approves a patch “for session”, future patches touching
  only those previously approved file(s) will no longer prompt gain during
  that session (both via app-server v2 and TUI/TUI2).
  
  **Manual testing**
  Tested both TUI and TUI2 - see screenshots below.
  
  TUI:
  <img width="1082" height="355" alt="image"
  src="https://github.com/user-attachments/assets/adcf45ad-d428-498d-92fc-1a0a420878d9"
  />
  
  
  TUI2:
  <img width="1089" height="438" alt="image"
  src="https://github.com/user-attachments/assets/dd768b1a-2f5f-4bd6-98fd-e52c1d3abd9e"
  />

  Owen Lin · 2026-01-07 20:11:12 +00:00
  66450f0445
• Fix app-server write_models_cache to treat models with less priority number as higher priority. (#8844)

  Rank models with p0 higher than p1. This shouldn't result in any
  behavioral changes. Just reordering.

  Ahmed Ibrahim · 2026-01-07 11:22:13 -08:00
  4c9b4b684f
• Merge Modelfamily into modelinfo (#8763)

  - Merge ModelFamily into ModelInfo
  - Remove logic for adding instructions to apply patch
  - Add compaction limit and visible context window to `ModelInfo`

  Ahmed Ibrahim · 2026-01-07 10:35:09 -08:00
  9179c9deac
• chore: unify conversation with thread name (#8830)

  Done and verified by Codex + refactor feature of RustRover

  jif-oai · 2026-01-07 17:04:53 +00:00
  116059c3a0
• Enable model upgrade popup even when selected model is no longer in picker (#8802)

  With `config.toml`:
  ```
  model = "gpt-5.1-codex"
  ```
  (where `gpt-5.1-codex` has `show_in_picker: false` in
  [`model_presets.rs`](https://github.com/openai/codex/blob/main/codex-rs/core/src/models_manager/model_presets.rs);
  this happens if the user hasn't used codex in a while so they didn't see
  the popup before their model was changed to `show_in_picker: false`)
  
  The upgrade picker used to not show (because `gpt-5.1-codex` was
  filtered out of the model list in code). Now, the filtering is done
  downstream in tui and app-server, so the model upgrade popup shows:
  
  <img width="1503" height="227" alt="Screenshot 2026-01-06 at 5 04 37 PM"
  src="https://github.com/user-attachments/assets/26144cc2-0b3f-4674-ac17-e476781ec548"
  />

  charley-oai · 2026-01-06 19:32:27 -08:00
  3389465c8d
• feat(app-server): thread/rollback API (#8454)

  Add `thread/rollback` to app-server to support IDEs undo-ing the last N
  turns of a thread.
  
  For context, an IDE partner will be supporting an "undo" capability
  where the IDE (the app-server client) will be responsible for reverting
  the local changes made during the last turn. To support this well, we
  also need a way to drop the last turn (or more generally, the last N
  turns) from the agent's context. This is what `thread/rollback` does.
  
  **Core idea**: A Thread rollback is represented as a persisted event
  message (EventMsg::ThreadRollback) in the rollout JSONL file, not by
  rewriting history. On resume, both the model's context (core replay) and
  the UI turn list (app-server v2's thread history builder) apply these
  markers so the pruned history is consistent across live conversations
  and `thread/resume`.
  
  Implementation notes:
  - Rollback only affects agent context and appends to the rollout file;
  clients are responsible for reverting files on disk.
  - If a thread rollback is currently in progress, subsequent
  `thread/rollback` calls are rejected.
  - Because we use `CodexConversation::submit` and codex core tracks
  active turns, returning an error on concurrent rollbacks is communicated
  via an `EventMsg::Error` with a new variant
  `CodexErrorInfo::ThreadRollbackFailed`. app-server watches for that and
  sends the BAD_REQUEST RPC response.
  
  Tests cover thread rollbacks in both core and app-server, including when
  `num_turns` > existing turns (which clears all turns).
  
  **Note**: this explicitly does **not** behave like `/undo` which we just
  removed from the CLI, which does the opposite of what `thread/rollback`
  does. `/undo` reverts local changes via ghost commits/snapshots and does
  not modify the agent's context / conversation history.

  Owen Lin · 2026-01-06 21:23:48 +00:00
  8b7ec31ba7
• fix: stop honoring CODEX_MANAGED_CONFIG_PATH environment variable in production (#8762)
  Michael Bolin · 2026-01-06 07:10:27 -08:00
  7ecd0dc9b3
• feat: expose outputSchema to user_turn/turn_start app_server API (#8377)

  What changed
  - Added `outputSchema` support to the app-server APIs, mirroring `codex
  exec --output-schema` behavior.
  - V1 `sendUserTurn` now accepts `outputSchema` and constrains the final
  assistant message for that turn.
  - V2 `turn/start` now accepts `outputSchema` and constrains the final
  assistant message for that turn (explicitly per-turn only).
  
  Core behavior
  - `Op::UserTurn` already supported `final_output_json_schema`; now V1
  `sendUserTurn` forwards `outputSchema` into that field.
  - `Op::UserInput` now carries `final_output_json_schema` for per-turn
  settings updates; core maps it into
  `SessionSettingsUpdate.final_output_json_schema` so it applies to the
  created turn context.
  - V2 `turn/start` does NOT persist the schema via `OverrideTurnContext`
  (it’s applied only for the current turn). Other overrides
  (cwd/model/etc) keep their existing persistent behavior.
  
  API / docs
  - `codex-rs/app-server-protocol/src/protocol/v1.rs`: add `output_schema:
  Option<serde_json::Value>` to `SendUserTurnParams` (serialized as
  `outputSchema`).
  - `codex-rs/app-server-protocol/src/protocol/v2.rs`: add `output_schema:
  Option<JsonValue>` to `TurnStartParams` (serialized as `outputSchema`).
  - `codex-rs/app-server/README.md`: document `outputSchema` for
  `turn/start` and clarify it applies only to the current turn.
  - `codex-rs/docs/codex_mcp_interface.md`: document `outputSchema` for v1
  `sendUserTurn` and v2 `turn/start`.
  
  Tests added/updated
  - New app-server integration tests asserting `outputSchema` is forwarded
  into outbound `/responses` requests as `text.format`:
    - `codex-rs/app-server/tests/suite/output_schema.rs`
    - `codex-rs/app-server/tests/suite/v2/output_schema.rs`
  - Added per-turn semantics tests (schema does not leak to the next
  turn):
    - `send_user_turn_output_schema_is_per_turn_v1`
    - `turn_start_output_schema_is_per_turn_v2`
  - Added protocol wire-compat tests for the merged op:
    - serialize omits `final_output_json_schema` when `None`
    - deserialize works when field is missing
    - serialize includes `final_output_json_schema` when `Some(schema)`
  
  Call site updates (high level)
  - Updated all `Op::UserInput { .. }` constructions to include
  `final_output_json_schema`:
    - `codex-rs/app-server/src/codex_message_processor.rs`
    - `codex-rs/core/src/codex_delegate.rs`
    - `codex-rs/mcp-server/src/codex_tool_runner.rs`
    - `codex-rs/tui/src/chatwidget.rs`
    - `codex-rs/tui2/src/chatwidget.rs`
    - plus impacted core tests.
  
  Validation
  - `just fmt`
  - `cargo test -p codex-core`
  - `cargo test -p codex-app-server`
  - `cargo test -p codex-mcp-server`
  - `cargo test -p codex-tui`
  - `cargo test -p codex-tui2`
  - `cargo test -p codex-protocol`
  - `cargo clippy --all-features --tests --profile dev --fix -- -D
  warnings`

  Anton Panasenko · 2026-01-05 10:27:00 -08:00
  807f8a43c2
• feat: introduce codex-utils-cargo-bin as an alternative to assert_cmd::Command (#8496)

  This PR introduces a `codex-utils-cargo-bin` utility crate that
  wraps/replaces our use of `assert_cmd::Command` and
  `escargot::CargoBuild`.
  
  As you can infer from the introduction of `buck_project_root()` in this
  PR, I am attempting to make it possible to build Codex under
  [Buck2](https://buck2.build) as well as `cargo`. With Buck2, I hope to
  achieve faster incremental local builds (largely due to Buck2's
  [dice](https://buck2.build/docs/insights_and_knowledge/modern_dice/)
  build strategy, as well as benefits from its local build daemon) as well
  as faster CI builds if we invest in remote execution and caching.
  
  See
  https://buck2.build/docs/getting_started/what_is_buck2/#why-use-buck2-key-advantages
  for more details about the performance advantages of Buck2.
  
  Buck2 enforces stronger requirements in terms of build and test
  isolation. It discourages assumptions about absolute paths (which is key
  to enabling remote execution). Because the `CARGO_BIN_EXE_*` environment
  variables that Cargo provides are absolute paths (which
  `assert_cmd::Command` reads), this is a problem for Buck2, which is why
  we need this `codex-utils-cargo-bin` utility.
  
  My WIP-Buck2 setup sets the `CARGO_BIN_EXE_*` environment variables
  passed to a `rust_test()` build rule as relative paths.
  `codex-utils-cargo-bin` will resolve these values to absolute paths,
  when necessary.
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/8496).
  * #8498
  * __->__ #8496

  Michael Bolin · 2025-12-23 19:29:32 -08:00
  e61bae12e3
• Remove reasoning format (#8484)

  This isn't very useful parameter. 
  
  logic:
  ```
  if model puts `**` in their reasoning, trim it and visualize the header.
  if couldn't trim: don't render
  if model doesn't support: don't render
  ```
  
  We can simplify to:
  ```
  if could trim, visualize header.
  if not, don't render
  ```

  Ahmed Ibrahim · 2025-12-23 16:01:46 -08:00
  40de81e7af
• feat: honor /etc/codex/config.toml (#8461)

  This adds logic to load `/etc/codex/config.toml` and associate it with
  `ConfigLayerSource::System` on UNIX. I refactored the code so it shares
  logic with the creation of the `ConfigLayerSource::User` layer.

  Michael Bolin · 2025-12-22 19:06:04 -08:00
  e27d9bd88f
• remove minimal client version (#8447)

  This isn't needed value by client

  Ahmed Ibrahim · 2025-12-22 12:52:24 -08:00
  6b2ef216f1
• Rename OpenAI models to models manager (#8346)

  # External (non-OpenAI) Pull Request Requirements
  
  Before opening this Pull Request, please read the dedicated
  "Contributing" markdown file or your PR may be closed:
  https://github.com/openai/codex/blob/main/docs/contributing.md
  
  If your PR conforms to our contribution guidelines, replace this text
  with a detailed and high quality description of your changes.
  
  Include a link to a bug report or enhancement request.

  Ahmed Ibrahim · 2025-12-19 16:20:05 -08:00
  f0dc6fd3c7
• feat: migrate to new constraint-based loading strategy (#8251)

  This is a significant change to how layers of configuration are applied.
  In particular, the `ConfigLayerStack` now has two important fields:
  
  - `layers: Vec<ConfigLayerEntry>`
  - `requirements: ConfigRequirements`
  
  We merge `TomlValue`s across the layers, but they are subject to
  `ConfigRequirements` before creating a `Config`.
  
  How I would review this PR:
  
  - start with `codex-rs/app-server-protocol/src/protocol/v2.rs` and note
  the new variants added to the `ConfigLayerSource` enum:
  `LegacyManagedConfigTomlFromFile` and `LegacyManagedConfigTomlFromMdm`
  - note that `ConfigLayerSource` now has a `precedence()` method and
  implements `PartialOrd`
  - `codex-rs/core/src/config_loader/layer_io.rs` is responsible for
  loading "admin" preferences from `/etc/codex/managed_config.toml` and
  MDM. Because `/etc/codex/managed_config.toml` is now deprecated in favor
  of `/etc/codex/requirements.toml` and `/etc/codex/config.toml`, we now
  include some extra information on the `LoadedConfigLayers` returned in
  `layer_io.rs`.
  - `codex-rs/core/src/config_loader/mod.rs` has major changes to
  `load_config_layers_state()`, which is what produces `ConfigLayerStack`.
  The docstring has the new specification and describes the various layers
  that will be loaded and the precedence order.
  - It uses the information from `LoaderOverrides` "twice," both in the
  spirit of legacy support:
  - We use one instances to derive an instance of `ConfigRequirements`.
  Currently, the only field in `managed_config.toml` that contributes to
  `ConfigRequirements` is `approval_policy`. This PR introduces
  `Constrained::allow_only()` to support this.
  - We use a clone of `LoaderOverrides` to derive
  `ConfigLayerSource::LegacyManagedConfigTomlFromFile` and
  `ConfigLayerSource::LegacyManagedConfigTomlFromMdm` layers, as
  appropriate. As before, this ends up being a "best effort" at enterprise
  controls, but is enforcement is not guaranteed like it is for
  `ConfigRequirements`.
  - Now we only create a "user" layer if `$CODEX_HOME/config.toml` exists.
  (Previously, a user layer was always created for `ConfigLayerStack`.)
  - Similarly, we only add a "session flags" layer if there are CLI
  overrides.
  - `config_loader/state.rs` contains the updated implementation for
  `ConfigLayerStack`. Note the public API is largely the same as before,
  but the implementation is quite different. We leverage the fact that
  `ConfigLayerSource` is now `PartialOrd` to ensure layers are in the
  correct order.
  - A `Config` constructed via `ConfigBuilder.build()` will use
  `load_config_layers_state()` to create the `ConfigLayerStack` and use
  the associated `ConfigRequirements` when constructing the `Config`
  object.
  - That said, a `Config` constructed via
  `Config::load_from_base_config_with_overrides()` does _not_ yet use
  `ConfigBuilder`, so it creates a `ConfigRequirements::default()` instead
  of loading a proper `ConfigRequirements`. I will fix this in a
  subsequent PR.
  
  Then the following files are mostly test changes:
  
  ```
  codex-rs/app-server/tests/suite/v2/config_rpc.rs
  codex-rs/core/src/config/service.rs
  codex-rs/core/src/config_loader/tests.rs
  ```
  
  Again, because we do not always include "user" and "session flags"
  layers when the contents are empty, `ConfigLayerStack` sometimes has
  fewer layers than before (and the precedence order changed slightly),
  which is the main reason integration tests changed.

  Michael Bolin · 2025-12-18 10:06:05 -08:00
  b903285746
• caribou (#8265)

  Welcome caribou
  
  <img width="1536" height="1024" alt="image"
  src="https://github.com/user-attachments/assets/2a67b21f-40cf-4518-aee4-691af331ab50"
  />

  Ahmed Ibrahim · 2025-12-18 08:58:44 -08:00
  f084e5264b
• chores: clean picker (#8232)

  # External (non-OpenAI) Pull Request Requirements
  
  Before opening this Pull Request, please read the dedicated
  "Contributing" markdown file or your PR may be closed:
  https://github.com/openai/codex/blob/main/docs/contributing.md
  
  If your PR conforms to our contribution guidelines, replace this text
  with a detailed and high quality description of your changes.
  
  Include a link to a bug report or enhancement request.

  Ahmed Ibrahim · 2025-12-18 08:41:34 -08:00
  374d591311
• feat: model picker (#8209)

  # External (non-OpenAI) Pull Request Requirements
  
  Before opening this Pull Request, please read the dedicated
  "Contributing" markdown file or your PR may be closed:
  https://github.com/openai/codex/blob/main/docs/contributing.md
  
  If your PR conforms to our contribution guidelines, replace this text
  with a detailed and high quality description of your changes.
  
  Include a link to a bug report or enhancement request.

  Ahmed Ibrahim · 2025-12-17 16:12:35 -08:00
  774bd9e432
• Load models from static file (#8153)

  - Load models from static file as a fallback
  - Make API users use this file directly
  - Add tests to make sure updates to the file always serialize

  Ahmed Ibrahim · 2025-12-17 14:34:13 -08:00
  927a6acbea
• feat: make list_models non-blocking (#8198)

  ### Summary
  * Make `app_server.list_models` to be non-blocking and consumers (i.e.
  extension) can manage the flow themselves.
  * Force config to use remote models and therefore fetch codex-auto model
  list.

  Shijie Rao · 2025-12-17 12:13:16 -08:00
  df35189366
• feat: change ConfigLayerName into a disjoint union rather than a simple enum (#8095)

  This attempts to tighten up the types related to "config layers."
  Currently, `ConfigLayerEntry` is defined as follows:
  
  
  https://github.com/openai/codex/blob/bef36f4ae765f471d7cd69372fcf1b92c8f0367a/codex-rs/core/src/config_loader/state.rs#L19-L25
  
  but the `source` field is a bit of a lie, as:
  
  - for `ConfigLayerName::Mdm`, it is
  `"com.openai.codex/config_toml_base64"`
  - for `ConfigLayerName::SessionFlags`, it is `"--config"`
  - for `ConfigLayerName::User`, it is `"config.toml"` (just the file
  name, not the path to the `config.toml` on disk that was read)
  - for `ConfigLayerName::System`, it seems like it is usually
  `/etc/codex/managed_config.toml` in practice, though on Windows, it is
  `%CODEX_HOME%/managed_config.toml`:
  
  
  https://github.com/openai/codex/blob/bef36f4ae765f471d7cd69372fcf1b92c8f0367a/codex-rs/core/src/config_loader/layer_io.rs#L84-L101
  
  All that is to say, in three out of the four `ConfigLayerName`, `source`
  is a `PathBuf` that is not an absolute path (or even a true path).
  
  This PR tries to uplevel things by eliminating `source` from
  `ConfigLayerEntry` and turning `ConfigLayerName` into a disjoint union
  named `ConfigLayerSource` that has the appropriate metadata for each
  variant, favoring the use of `AbsolutePathBuf` where appropriate:
  
  ```rust
  pub enum ConfigLayerSource {
      /// Managed preferences layer delivered by MDM (macOS only).
      #[serde(rename_all = "camelCase")]
      #[ts(rename_all = "camelCase")]
      Mdm { domain: String, key: String },
      /// Managed config layer from a file (usually `managed_config.toml`).
      #[serde(rename_all = "camelCase")]
      #[ts(rename_all = "camelCase")]
      System { file: AbsolutePathBuf },
      /// Session-layer overrides supplied via `-c`/`--config`.
      SessionFlags,
      /// User config layer from a file (usually `config.toml`).
      #[serde(rename_all = "camelCase")]
      #[ts(rename_all = "camelCase")]
      User { file: AbsolutePathBuf },
  }
  ```

  Michael Bolin · 2025-12-17 08:13:59 -08:00
  de3fa03e1c
• fix: added test helpers for platform-specific paths (#7954)

  This addresses post-merge feedback from
  https://github.com/openai/codex/pull/7856.

  Michael Bolin · 2025-12-13 00:14:12 +00:00
  b1905d3754
• fix: introduce AbsolutePathBuf as part of sandbox config (#7856)

  Changes the `writable_roots` field of the `WorkspaceWrite` variant of
  the `SandboxPolicy` enum from `Vec<PathBuf>` to `Vec<AbsolutePathBuf>`.
  This is helpful because now callers can be sure the value is an absolute
  path rather than a relative one. (Though when using an absolute path in
  a Seatbelt config policy, we still have to _canonicalize_ it first.)
  
  Because `writable_roots` can be read from a config file, it is important
  that we are able to resolve relative paths properly using the parent
  folder of the config file as the base path.

  Michael Bolin · 2025-12-12 15:25:22 -08:00
  642b7566df
• chores: models manager (#7937)
  Ahmed Ibrahim · 2025-12-12 18:59:39 +00:00
  149696d959
• Fix misleading 'maximize' high effort description on xhigh models (#7874)

  ## Notes
  - switch misleading High reasoning effort descriptions from "Maximizes
  reasoning depth" to "Higher reasoning depth" across models with xhigh
  reasoning. Affects GPT-5.1 Codex Max and Robin
  - refresh model list fixtures and chatwidget snapshots to match new copy
  
  ## Revision
  - R2: Change 'Higher' to 'Greater'
  - R1: Initial
  
  ## Testing
  
  <img width="583" height="142" alt="image"
  src="https://github.com/user-attachments/assets/1ddd8971-7841-4cb3-b9ba-91095a7435d2"
  />
  
  <img width="838" height="142" alt="image"
  src="https://github.com/user-attachments/assets/79aaedbf-7624-4695-b822-93dea7d6a800"
  />

  Victor Vannara · 2025-12-11 16:38:52 -08:00
  95f7d37ec6
• Update Model Info (#7853)
  Ahmed Ibrahim · 2025-12-11 14:06:07 -08:00
  b7fa7ca8e9
• feat: robin (#7882)

  <img width="554" height="554" alt="image"
  src="https://github.com/user-attachments/assets/aa86f4c8-fb34-4b0e-8b03-3a9980dfdb08"
  />
  
  ---------
  
  Co-authored-by: Dylan Hurd <dylan.hurd@openai.com>

  Ahmed Ibrahim · 2025-12-11 09:04:08 -08:00
  238ce7dfad
• feat: add shell snapshot for shell command (#7786)
  jif-oai · 2025-12-11 13:46:43 +00:00
  29381ba5c2
• fix(stuff) (#7855)

  Co-authored-by: Ahmed Ibrahim <aibrahim@openai.com>

  Dylan Hurd · 2025-12-11 00:39:47 -08:00
  dca7f4cb60
• [app-server] make app server not throw error when login id is not found (#7831)

  Our previous design of cancellation endpoint is not idempotent, which
  caused a bunch of flaky tests. Make app server just returned a not_found
  status instead of throwing an error if the login id is not found. Keep
  V1 endpoint behavior the same.

  Celia Chen · 2025-12-10 16:19:40 -08:00
  7cabe54fc7
• fix: thread/list returning fewer than the requested amount due to filtering CXA-293 (#7509)

  This caused some conversations to not appear when they otherwise should.
  
  Prior to this change, `thread/list`/`list_conversations_common` would:
  - Fetch N conversations from `RolloutRecorder::list_conversations`
  - Then it would filter those (like by the provided `model_providers`)
  - This would make it potentially return less than N items.
  
  With this change:
  - `list_conversations_common` now continues fetching more conversations
  from `RolloutRecorder::list_conversations` until it "fills up" the
  `requested_page_size`.
  - Ultimately this means that clients can rely on getting eg 20
  conversations if they request 20 conversations.

  Javi · 2025-12-10 23:06:32 +00:00
  e2559ab28d
• [app-server-protocol] Add types for config (#7658)

  Currently the config returned by `config/read` in untyped. Add types so
  it's easier for client to parse the config. Since currently configs are
  all defined in snake case we'll keep that instead of using camel case
  like the rest of V2.
  
  Sample output by testing using the app server test client:
  ```
  {
  <   "id": "f28449f4-b015-459b-b07b-eef06980165d",
  <   "result": {
  <     "config": {
  <       "approvalPolicy": null,
  <       "compactPrompt": null,
  <       "developerInstructions": null,
  <       "features": {
  <         "experimental_use_rmcp_client": true
  <       },
  <       "forcedChatgptWorkspaceId": null,
  <       "forcedLoginMethod": null,
  <       "instructions": null,
  <       "model": "gpt-5.1-codex-max",
  <       "modelAutoCompactTokenLimit": null,
  <       "modelContextWindow": null,
  <       "modelProvider": null,
  <       "modelReasoningEffort": null,
  <       "modelReasoningSummary": null,
  <       "modelVerbosity": null,
  <       "model_providers": {
  <         "local": {
  <           "base_url": "http://localhost:8061/api/codex",
  <           "env_http_headers": {
  <             "ChatGPT-Account-ID": "OPENAI_ACCOUNT_ID"
  <           },
  <           "env_key": "CHATGPT_TOKEN_STAGING",
  <           "name": "local",
  <           "wire_api": "responses"
  <         }
  <       },
  <       "model_reasoning_effort": "medium",
  <       "notice": {
  <         "hide_gpt-5.1-codex-max_migration_prompt": true,
  <         "hide_gpt5_1_migration_prompt": true
  <       },
  <       "profile": null,
  <       "profiles": {},
  <       "projects": {
  <         "/Users/celia/code": {
  <           "trust_level": "trusted"
  <         },
  <         "/Users/celia/code/codex": {
  <           "trust_level": "trusted"
  <         },
  <         "/Users/celia/code/openai": {
  <           "trust_level": "trusted"
  <         }
  <       },
  <       "reviewModel": null,
  <       "sandboxMode": null,
  <       "sandboxWorkspaceWrite": null,
  <       "tools": {
  <         "viewImage": null,
  <         "webSearch": null
  <       }
  <     },
  <     "origins": {
  <       "features.experimental_use_rmcp_client": {
  <         "name": "user",
  <         "source": "/Users/celia/.codex/config.toml",
  <         "version": "sha256:a1d8eaedb5d9db5dfdfa69f30fa9df2efec66bb4dd46aa67f149fcc67cd0711c"
  <       },
  <       "model": {
  <         "name": "user",
  <         "source": "/Users/celia/.codex/config.toml",
  <         "version": "sha256:a1d8eaedb5d9db5dfdfa69f30fa9df2efec66bb4dd46aa67f149fcc67cd0711c"
  <       },
  <       "model_providers.local.base_url": {
  <         "name": "user",
  <         "source": "/Users/celia/.codex/config.toml",
  <         "version": "sha256:a1d8eaedb5d9db5dfdfa69f30fa9df2efec66bb4dd46aa67f149fcc67cd0711c"
  <       },
  <       "model_providers.local.env_http_headers.ChatGPT-Account-ID": {
  <         "name": "user",
  <         "source": "/Users/celia/.codex/config.toml",
  <         "version": "sha256:a1d8eaedb5d9db5dfdfa69f30fa9df2efec66bb4dd46aa67f149fcc67cd0711c"
  <       },
  <       "model_providers.local.env_key": {
  <         "name": "user",
  <         "source": "/Users/celia/.codex/config.toml",
  <         "version": "sha256:a1d8eaedb5d9db5dfdfa69f30fa9df2efec66bb4dd46aa67f149fcc67cd0711c"
  <       },
  <       "model_providers.local.name": {
  <         "name": "user",
  <         "source": "/Users/celia/.codex/config.toml",
  <         "version": "sha256:a1d8eaedb5d9db5dfdfa69f30fa9df2efec66bb4dd46aa67f149fcc67cd0711c"
  <       },
  <       "model_providers.local.wire_api": {
  <         "name": "user",
  <         "source": "/Users/celia/.codex/config.toml",
  <         "version": "sha256:a1d8eaedb5d9db5dfdfa69f30fa9df2efec66bb4dd46aa67f149fcc67cd0711c"
  <       },
  <       "model_reasoning_effort": {
  <         "name": "user",
  <         "source": "/Users/celia/.codex/config.toml",
  <         "version": "sha256:a1d8eaedb5d9db5dfdfa69f30fa9df2efec66bb4dd46aa67f149fcc67cd0711c"
  <       },
  <       "notice.hide_gpt-5.1-codex-max_migration_prompt": {
  <         "name": "user",
  <         "source": "/Users/celia/.codex/config.toml",
  <         "version": "sha256:a1d8eaedb5d9db5dfdfa69f30fa9df2efec66bb4dd46aa67f149fcc67cd0711c"
  <       },
  <       "notice.hide_gpt5_1_migration_prompt": {
  <         "name": "user",
  <         "source": "/Users/celia/.codex/config.toml",
  <         "version": "sha256:a1d8eaedb5d9db5dfdfa69f30fa9df2efec66bb4dd46aa67f149fcc67cd0711c"
  <       },
  <       "projects./Users/celia/code.trust_level": {
  <         "name": "user",
  <         "source": "/Users/celia/.codex/config.toml",
  <         "version": "sha256:a1d8eaedb5d9db5dfdfa69f30fa9df2efec66bb4dd46aa67f149fcc67cd0711c"
  <       },
  <       "projects./Users/celia/code/codex.trust_level": {
  <         "name": "user",
  <         "source": "/Users/celia/.codex/config.toml",
  <         "version": "sha256:a1d8eaedb5d9db5dfdfa69f30fa9df2efec66bb4dd46aa67f149fcc67cd0711c"
  <       },
  <       "projects./Users/celia/code/openai.trust_level": {
  <         "name": "user",
  <         "source": "/Users/celia/.codex/config.toml",
  <         "version": "sha256:a1d8eaedb5d9db5dfdfa69f30fa9df2efec66bb4dd46aa67f149fcc67cd0711c"
  <       },
  <       "tools.web_search": {
  <         "name": "user",
  <         "source": "/Users/celia/.codex/config.toml",
  <         "version": "sha256:a1d8eaedb5d9db5dfdfa69f30fa9df2efec66bb4dd46aa67f149fcc67cd0711c"
  <       }
  <     }
  <   }
  < }
  ```

  Celia Chen · 2025-12-10 21:35:31 +00:00
  bfb4d5710b
• 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

  Ahmed Ibrahim · 2025-12-10 11:19:00 -08:00
  cb9a189857
• Removed experimental "command risk assessment" feature (#7799)

  This experimental feature received lukewarm reception during internal
  testing. Removing from the code base.

  Eric Traut · 2025-12-10 09:48:11 -08:00
  c4af707e09
• updating app server types to support execpoilcy amendment (#7747)

  also includes minor refactor merging `ApprovalDecision` with
  `CommandExecutionRequestAcceptSettings`

  zhao-oai · 2025-12-08 13:56:22 -08:00
  0a32acaa2d
• fix: taking plan type from usage endpoint instead of thru auth token (#7610)

  pull plan type from the usage endpoint, persist it in session state /
  tui state, and propagate through rate limit snapshots

  zhao-oai · 2025-12-04 23:34:13 -08:00
  b8eab7ce90
• [app-server] make file_path for config optional (#7560)

  When we are writing to config using `config/value/write` or
  `config/batchWrite`, it always require a `config/read` before it right
  now in order to get the correct file path to write to. make this
  optional so we read from the default user config file if this is not
  passed in.

  Celia Chen · 2025-12-04 03:08:18 +00:00
  3e6cd5660c
• Migrate model preset (#7542)

  - Introduce `openai_models` in `/core`
  - Move `PRESETS` under it
  - Move `ModelPreset`, `ModelUpgrade`, `ReasoningEffortPreset`,
  `ReasoningEffortPreset`, and `ReasoningEffortPreset` to `protocol`
  - Introduce `Op::ListModels` and `EventMsg::AvailableModels`
  
  Next steps:
  - migrate `app-server` and `tui` to use the introduced Operation

  Ahmed Ibrahim · 2025-12-03 20:30:43 +00:00
  71504325d3
• chore: review everywhere (#7444)
  jif-oai · 2025-12-02 11:26:27 +00:00
  4b78e2ab09