88 Commits

• 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
• [app-server] fix: emit item/fileChange/outputDelta for file change items (#7399)
  Owen Lin · 2025-12-01 17:52:34 +00:00
  8532876ad8
• fix: other flaky tests (#7372)
  jif-oai · 2025-11-28 15:29:44 +00:00
  6eeaf46ac1
• feat: detached review (#7292)
  jif-oai · 2025-11-28 11:34:57 +00:00
  aaec8abf58
• feat: update process ID for event handling (#7261)
  jif-oai · 2025-11-25 14:21:05 -08:00
  28ff364c3a
• chore: proper client extraction (#6996)
  jif-oai · 2025-11-25 18:06:12 +00:00
  4502b1b263
• [app-server] feat: add thread_id and turn_id to item and error notifications (#7124)

  Add `thread_id` and `turn_id` to `item/started`, `item/completed`, and
  `error` notifications. Otherwise the client will have a hard time
  knowing which thread & turn (if multiple threads are running in
  parallel) a new item/error is for.
  
  Also add `thread_id` to `turn/started` and `turn/completed`.

  Owen Lin · 2025-11-25 08:05:47 -08:00
  157a16cefa
• feat[app-serve]: config management (#7241)
  jif-oai · 2025-11-25 09:29:38 +00:00
  523b40a129
• chore: add cargo-deny configuration (#7119)

  - add GitHub workflow running cargo-deny on push/PR
  - document cargo-deny allowlist with workspace-dep notes and advisory
  ignores
  - align workspace crates to inherit version/edition/license for
  consistent checks

  Josh McKinney · 2025-11-24 12:22:18 -08:00
  ec49b56874
• fix(windows) support apply_patch parsing in powershell (#7221)

  ## Summary
  Support powershell parsing of apply_patch
  
  ## Testing
  - [x] Enable apply_patch unit tests
  
  ---------
  
  Co-authored-by: jif-oai <jif@openai.com>

  Dylan Hurd · 2025-11-24 19:32:47 +00:00
  1e832b1438
• [app-server] feat: expose gitInfo/cwd/etc. on Thread (#7060)

  Port the new additions from https://github.com/openai/codex/pull/6337 on
  the legacy API to v2. Mainly need `gitInfo` and `cwd` for VSCE.

  Owen Lin · 2025-11-21 10:37:12 -08:00
  aa4e0d823e
• [app-server] feat: add Declined status for command exec (#7101)

  Add a `Declined` status for when we request an approval from the user
  and the user declines. This allows us to distinguish from commands that
  actually ran, but failed.
  
  This behaves similarly to apply_patch / FileChange, which does the same
  thing.

  Owen Lin · 2025-11-21 09:19:39 -08:00
  2ae1f81d84
• Migrate coverage to shell_command (#7042)
  pakrym-oai · 2025-11-21 03:44:00 +00:00
  767b66f407
• [app-server] feat: v2 apply_patch approval flow (#6760)

  This PR adds the API V2 version of the apply_patch approval flow, which
  centers around `ThreadItem::FileChange`.
  
  This PR wires the new RPC (`item/fileChange/requestApproval`, V2 only)
  and related events (`item/started`, `item/completed` for
  `ThreadItem::FileChange`, which are emitted in both V1 and V2) through
  the app-server
  protocol. The new approval RPC is only sent when the user initiates a
  turn with the new `turn/start` API so we don't break backwards
  compatibility with VSCE.
  
  Similar to https://github.com/openai/codex/pull/6758, the approach I
  took was to make as few changes to the Codex core as possible,
  leveraging existing `EventMsg` core events, and translating those in
  app-server. I did have to add a few additional fields to
  `EventMsg::PatchApplyBegin` and `EventMsg::PatchApplyEnd`, but those
  were fairly lightweight.
  
  However, the `EventMsg`s emitted by core are the following:
  ```
  1) Auto-approved (no request for approval)

  - EventMsg::PatchApplyBegin
  - EventMsg::PatchApplyEnd
  
  2) Approved by user
  - EventMsg::ApplyPatchApprovalRequest
  - EventMsg::PatchApplyBegin
  - EventMsg::PatchApplyEnd
  
  3) Declined by user
  - EventMsg::ApplyPatchApprovalRequest
  - EventMsg::PatchApplyBegin
  - EventMsg::PatchApplyEnd
  ```
  
  For a request triggering an approval, this would result in:
  ```
  item/fileChange/requestApproval
  item/started
  item/completed
  ```
  
  which is different from the `ThreadItem::CommandExecution` flow
  introduced in https://github.com/openai/codex/pull/6758, which does the
  below and is preferable:
  ```
  item/started
  item/commandExecution/requestApproval
  item/completed
  ```
  
  To fix this, we leverage `TurnSummaryStore` on codex_message_processor
  to store a little bit of state, allowing us to fire `item/started` and
  `item/fileChange/requestApproval` whenever we receive the underlying
  `EventMsg::ApplyPatchApprovalRequest`, and no-oping when we receive the
  `EventMsg::PatchApplyBegin` later.
  
  This is much less invasive than modifying the order of EventMsg within
  core (I tried).
  
  The resulting payloads:
  ```
  {
    "method": "item/started",
    "params": {
      "item": {
        "changes": [
          {
            "diff": "Hello from Codex!\n",
            "kind": "add",
            "path": "/Users/owen/repos/codex/codex-rs/APPROVAL_DEMO.txt"
          }
        ],
        "id": "call_Nxnwj7B3YXigfV6Mwh03d686",
        "status": "inProgress",
        "type": "fileChange"
      }
    }
  }
  ```
  
  ```
  {
    "id": 0,
    "method": "item/fileChange/requestApproval",
    "params": {
      "grantRoot": null,
      "itemId": "call_Nxnwj7B3YXigfV6Mwh03d686",
      "reason": null,
      "threadId": "019a9e11-8295-7883-a283-779e06502c6f",
      "turnId": "1"
    }
  }
  ```
  
  ```
  {
    "id": 0,
    "result": {
      "decision": "accept"
    }
  }
  ```
  
  ```
  {
    "method": "item/completed",
    "params": {
      "item": {
        "changes": [
          {
            "diff": "Hello from Codex!\n",
            "kind": "add",
            "path": "/Users/owen/repos/codex/codex-rs/APPROVAL_DEMO.txt"
          }
        ],
        "id": "call_Nxnwj7B3YXigfV6Mwh03d686",
        "status": "completed",
        "type": "fileChange"
      }
    }
  }
  ```

  Owen Lin · 2025-11-19 20:13:31 -08:00
  d6c30ed25e
• storing credits (#6858)

  Expand the rate-limit cache/TUI: store credit snapshots alongside
  primary and secondary windows, render “Credits” when the backend reports
  they exist (unlimited vs rounded integer balances)

  zhao-oai · 2025-11-19 10:49:35 -08:00
  72af589398
• feat: arcticfox in the wild (#6906)

  <img width="485" height="600" alt="image"
  src="https://github.com/user-attachments/assets/4341740d-dd58-4a3e-b69a-33a3be0606c5"
  />
  
  ---------
  
  Co-authored-by: jif-oai <jif@openai.com>

  Ahmed Ibrahim · 2025-11-19 16:31:06 +00:00
  d5dfba2509
• [app-server] populate thread>turns>items on thread/resume (#6848)

  This PR allows clients to render historical messages when resuming a
  thread via `thread/resume` by reading from the list of `EventMsg`
  payloads loaded from the rollout, and then transforming them into Turns
  and ThreadItems to be returned on the `Thread` object.
  
  This is implemented by leveraging `SessionConfiguredNotification` which
  returns this list of `EventMsg` objects when resuming a conversation,
  and then applying a stateful `ThreadHistoryBuilder` that parses from
  this EventMsg log and transforms it into Turns and ThreadItems.
  
  Note that we only persist a subset of `EventMsg`s in a rollout as
  defined in `policy.rs`, so we lose fidelity whenever we resume a thread
  compared to when we streamed the thread's turns originally. However,
  this behavior is at parity with the legacy API.

  Owen Lin · 2025-11-19 15:58:09 +00:00
  1924500250
• fix: typos in model picker (#6859)

  # 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-11-19 06:29:02 +00:00
  793063070b
• fix: add more fields to ThreadStartResponse and ThreadResumeResponse (#6847)

  This adds the following fields to `ThreadStartResponse` and
  `ThreadResumeResponse`:
  
  ```rust
      pub model: String,
      pub model_provider: String,
      pub cwd: PathBuf,
      pub approval_policy: AskForApproval,
      pub sandbox: SandboxPolicy,
      pub reasoning_effort: Option<ReasoningEffort>,
  ```
  
  This is important because these fields are optional in
  `ThreadStartParams` and `ThreadResumeParams`, so the caller needs to be
  able to determine what values were ultimately used to start/resume the
  conversation. (Though note that any of these could be changed later
  between turns in the conversation.)
  
  Though to get this information reliably, it must be read from the
  internal `SessionConfiguredEvent` that is created in response to the
  start of a conversation. Because `SessionConfiguredEvent` (as defined in
  `codex-rs/protocol/src/protocol.rs`) did not have all of these fields, a
  number of them had to be added as part of this PR.
  
  Because `SessionConfiguredEvent` is referenced in many tests, test
  instances of `SessionConfiguredEvent` had to be updated, as well, which
  is why this PR touches so many files.

  Michael Bolin · 2025-11-18 21:18:43 -08:00
  a75321a64c
• [app-server] introduce turn/completed v2 event (#6800)

  similar to logic in
  `codex/codex-rs/exec/src/event_processor_with_jsonl_output.rs`.
  translation of v1 -> v2 events:
  `codex/event/task_complete` -> `turn/completed`
  `codex/event/turn_aborted` -> `turn/completed` with `interrupted` status
  `codex/event/error` -> `turn/completed` with `error` status
  
  this PR also makes `items` field in `Turn` optional. For now, we only
  populate it when we resume a thread, and leave it as None for all other
  places until we properly rewrite core to keep track of items.
  
  tested using the codex app server client. example new event:
  ```
  < {
  <   "method": "turn/completed",
  <   "params": {
  <     "turn": {
  <       "id": "0",
  <       "items": [],
  <       "status": "interrupted"
  <     }
  <   }
  < }
  ```

  Celia Chen · 2025-11-19 01:55:24 +00:00
  b395dc1be6
• feat: review in app server (#6613)
  jif-oai · 2025-11-18 21:58:54 +00:00
  8ddae8cde3
• Update defaults to gpt-5.1 (#6652)

  ## Summary
  - update documentation, example configs, and automation defaults to
  reference gpt-5.1 / gpt-5.1-codex
  - bump the CLI and core configuration defaults, model presets, and error
  messaging to the new models while keeping the model-family/tool coverage
  for legacy slugs
  - refresh tests, fixtures, and TUI snapshots so they expect the upgraded
  defaults
  
  ## Testing
  - `cargo test -p codex-core
  config::tests::test_precedence_fixture_with_gpt5_profile`
  
  
  ------
  [Codex
  Task](https://chatgpt.com/codex/tasks/task_i_6916c5b3c2b08321ace04ee38604fc6b)

  Ahmed Ibrahim · 2025-11-17 17:40:11 -08:00
  ddcc60a085
• [app-server] feat: add v2 command execution approval flow (#6758)

  This PR adds the API V2 version of the command‑execution approval flow
  for the shell tool.
  
  This PR wires the new RPC (`item/commandExecution/requestApproval`, V2
  only) and related events (`item/started`, `item/completed`, and
  `item/commandExecution/delta`, which are emitted in both V1 and V2)
  through the app-server
  protocol. The new approval RPC is only sent when the user initiates a
  turn with the new `turn/start` API so we don't break backwards
  compatibility with VSCE.
  
  The approach I took was to make as few changes to the Codex core as
  possible, leveraging existing `EventMsg` core events, and translating
  those in app-server. I did have to add additional fields to
  `EventMsg::ExecCommandEndEvent` to capture the command's input so that
  app-server can statelessly transform these events to a
  `ThreadItem::CommandExecution` item for the `item/completed` event.
  
  Once we stabilize the API and it's complete enough for our partners, we
  can work on migrating the core to be aware of command execution items as
  a first-class concept.
  
  **Note**: We'll need followup work to make sure these APIs work for the
  unified exec tool, but will wait til that's stable and landed before
  doing a pass on app-server.
  
  Example payloads below:
  ```
  {
    "method": "item/started",
    "params": {
      "item": {
        "aggregatedOutput": null,
        "command": "/bin/zsh -lc 'touch /tmp/should-trigger-approval'",
        "cwd": "/Users/owen/repos/codex/codex-rs",
        "durationMs": null,
        "exitCode": null,
        "id": "call_lNWWsbXl1e47qNaYjFRs0dyU",
        "parsedCmd": [
          {
            "cmd": "touch /tmp/should-trigger-approval",
            "type": "unknown"
          }
        ],
        "status": "inProgress",
        "type": "commandExecution"
      }
    }
  }
  ```
  
  ```
  {
    "id": 0,
    "method": "item/commandExecution/requestApproval",
    "params": {
      "itemId": "call_lNWWsbXl1e47qNaYjFRs0dyU",
      "parsedCmd": [
        {
          "cmd": "touch /tmp/should-trigger-approval",
          "type": "unknown"
        }
      ],
      "reason": "Need to create file in /tmp which is outside workspace sandbox",
      "risk": null,
      "threadId": "019a93e8-0a52-7fe3-9808-b6bc40c0989a",
      "turnId": "1"
    }
  }
  ```
  
  ```
  {
    "id": 0,
    "result": {
      "acceptSettings": {
        "forSession": false
      },
      "decision": "accept"
    }
  }
  ```
  
  ```
  {
    "params": {
      "item": {
        "aggregatedOutput": null,
        "command": "/bin/zsh -lc 'touch /tmp/should-trigger-approval'",
        "cwd": "/Users/owen/repos/codex/codex-rs",
        "durationMs": 224,
        "exitCode": 0,
        "id": "call_lNWWsbXl1e47qNaYjFRs0dyU",
        "parsedCmd": [
          {
            "cmd": "touch /tmp/should-trigger-approval",
            "type": "unknown"
          }
        ],
        "status": "completed",
        "type": "commandExecution"
      }
    }
  }
  ```

  Owen Lin · 2025-11-18 00:23:54 +00:00
  cecbd5b021
• [app-server] small fixes for JSON schema export and one-of types (#6614)

  A partner is consuming our generated JSON schema bundle for app-server
  and identified a few issues:
  - not all polymorphic / one-of types have a type descriminator
  - `"$ref": "#/definitions/v2/SandboxPolicy"` is missing
  - "Option<>" is an invalid schema name, and also unnecessary
  
  This PR:
  - adds the type descriminator to the various types that are missing it
  except for `SessionSource` and `SubAgentSource` because they are
  serialized to disk (adding this would break backwards compat for
  resume), and they should not be necessary to consume for an integration
  with app-server.
  - removes the special handling in `export.rs` of various types like
  SandboxPolicy, which turned out to be unnecessary and incorrect
  - filters out `Option<>` which was auto-generated for request params
  that don't need a body
  
  For context, we currently pull in wayyy more types than we need through
  the `EventMsg` god object which we are **not** planning to expose in API
  v2 (this is how I suspect `SessionSource` and `SubAgentSource` are being
  pulled in). But until we have all the necessary v2 notifications in
  place that will allow us to remove `EventMsg`, we will keep exporting it
  for now.

  Owen Lin · 2025-11-13 16:25:17 -08:00
  db2aa57d73
• Reasoning level update (#6586)

  Automatically update reasoning levels when migrating between models

  pakrym-oai · 2025-11-13 06:24:36 +00:00
  e3dd362c94
• feat: show gpt mini (#6583)
  Ahmed Ibrahim · 2025-11-13 05:21:00 +00:00
  e3aaee00c8