1012 Commits

• fix: introduce ConfigBuilder (#8235)

  Introduce `ConfigBuilder` as an alternative to our existing `Config`
  constructors.
  
  I noticed that the existing constructors,
  `Config::load_with_cli_overrides()` and
  `Config::load_with_cli_overrides_and_harness_overrides()`, did not take
  `codex_home` as a parameter, which can be a problem.
  
  Historically, when Codex was purely a CLI, we wanted to be extra sure
  that the creation of `codex_home` was always done via
  `find_codex_home()`, so we did not expose `codex_home` as a parameter
  when creating `Config` in business logic. But in integration tests,
  `codex_home` nearly always needs to be configured (as a temp directory),
  which is why callers would have to go through
  `Config::load_from_base_config_with_overrides()` instead.
  
  Now that the Codex harness also functions as an app server, which could
  conceivably load multiple threads where `codex_home` is parameterized
  differently in each one, I think it makes sense to make this
  configurable. Going to a builder pattern makes it more flexible to
  ensure an arbitrary permutation of options can be set when constructing
  a `Config` while using the appropriate defaults for the options that
  aren't set explicitly.
  
  Ultimately, I think this should make it possible for us to make
  `Config::load_from_base_config_with_overrides()` private because all
  integration tests should be able to leverage `ConfigBuilder` instead.
  Though there could be edge cases, so I'll pursue that migration after we
  get through the current config overhaul.
  
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/8235).
  * #8237
  * __->__ #8235

  Michael Bolin · 2025-12-17 23:45:09 -08:00
  580c59aa9a
• Support SYSTEM skills. (#8220)

  1. Remove PUBLIC skills and introduce SYSTEM skills embedded in the
  binary and installed into $CODEX_HOME/skills/.system at startup.
  2. Skills are now always enabled (feature flag removed).
  3. Update skills/list to accept forceReload and plumb it through (not
  used by clients yet).

  xl-openai · 2025-12-17 18:48:28 -08:00
  da3869eeb6
• Show migration link (#8228)

  # 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 02:03:40 +00:00
  6f102e18c4
• chore: cleanup Config instantiation codepaths (#8226)

  This PR does various types of cleanup before I can proceed with more
  ambitious changes to config loading.
  
  First, I noticed duplicated code across these two methods:
  
  
  https://github.com/openai/codex/blob/774bd9e432fa2e0f4e059e97648cf92216912e19/codex-rs/core/src/config/mod.rs#L314-L324
  
  
  https://github.com/openai/codex/blob/774bd9e432fa2e0f4e059e97648cf92216912e19/codex-rs/core/src/config/mod.rs#L334-L344
  
  This has now been consolidated in
  `load_config_as_toml_with_cli_overrides()`.
  
  Further, I noticed that `Config::load_with_cli_overrides()` took two
  similar arguments:
  
  
  https://github.com/openai/codex/blob/774bd9e432fa2e0f4e059e97648cf92216912e19/codex-rs/core/src/config/mod.rs#L308-L311
  
  The difference between `cli_overrides` and `overrides` was not
  immediately obvious to me. At first glance, it appears that one should
  be able to be expressed in terms of the other, but it turns out that
  some fields of `ConfigOverrides` (such as `cwd` and
  `codex_linux_sandbox_exe`) are, by design, not configurable via a
  `.toml` file or a command-line `--config` flag.
  
  That said, I discovered that many callers of
  `Config::load_with_cli_overrides()` were passing
  `ConfigOverrides::default()` for `overrides`, so I created two separate
  methods:
  
  - `Config::load_with_cli_overrides(cli_overrides: Vec<(String,
  TomlValue)>)`
  - `Config::load_with_cli_overrides_and_harness_overrides(cli_overrides:
  Vec<(String, TomlValue)>, harness_overrides: ConfigOverrides)`
  
  The latter has a long name, as it is _not_ what should be used in the
  common case, so the extra typing is designed to draw attention to this
  fact. I tried to update the existing callsites to use the shorter name,
  where possible.
  
  Further, in the cases where `ConfigOverrides` is used, usually only a
  limited subset of fields are actually set, so I updated the declarations
  to leverage `..Default::default()` where possible.

  Michael Bolin · 2025-12-17 18:01:17 -08:00
  a8797019a1
• 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
• fix: PathBuf -> AbsolutePathBuf in ConfigToml struct (#8205)

  We should not have any `PathBuf` fields in `ConfigToml` or any of the
  transitive structs we include, as we should use `AbsolutePathBuf`
  instead so that we do not have to keep track of the file from which
  `ConfigToml` was loaded such that we need it to resolve relative paths
  later when the values of `ConfigToml` are used.
  
  I only found two instances of this: `experimental_instructions_file` and
  `experimental_compact_prompt_file`. Incidentally, when these were
  specified as relative paths, they were resolved against `cwd` rather
  than `config.toml`'s parent, which seems wrong to me. I changed the
  behavior so they are resolved against the parent folder of the
  `config.toml` being parsed, which we get "for free" due to the
  introduction of `AbsolutePathBufGuard ` in
  https://github.com/openai/codex/pull/7796.
  
  While it is not great to change the behavior of a released feature,
  these fields are prefixed with `experimental_`, which I interpret to
  mean we have the liberty to change the contract.
  
  For reference:
  
  - `experimental_instructions_file` was introduced in
  https://github.com/openai/codex/pull/1803
  - `experimental_compact_prompt_file` was introduced in
  https://github.com/openai/codex/pull/5959

  Michael Bolin · 2025-12-17 12:08:18 -08:00
  1e9babe178
• feat: add config to disable warnings around ghost snapshot (#8178)
  jif-oai · 2025-12-17 18:50:22 +00:00
  3d92b443b0
• fix: session downgrade (#8196)

  The problem is that the `tokio` task own an `Arc` reference of the
  session and that this task only exit with the broadcast channel get
  closed. But this never get closed if the session is not dropped. So it's
  a snake biting his tail basically
  
  The most notable result was that non of the `Drop` implementation were
  triggered (temporary files, shell snapshots, session cleaning etc etc)
  when closing the session (through a `/new` for example)
  
  The fix is just to weaken the `Arc` and upgrade it on the fly

  jif-oai · 2025-12-17 10:44:39 -08:00
  167553f00d
• fix: proper skills dir cleanup (#8194)
  jif-oai · 2025-12-17 18:31:03 +00:00
  9f28c6251d
• chore: move back stuff out of beta program (#8199)
  jif-oai · 2025-12-17 17:58:47 +00:00
  a2cc0032e0
• feat: experimental menu (#8071)

  This will automatically render any `Stage::Beta` features.
  
  The change only gets applied to the *next session*. This started as a
  bug but actually this is a good thing to prevent out of distribution
  push
  
  <img width="986" height="288" alt="Screenshot 2025-12-15 at 15 38 35"
  src="https://github.com/user-attachments/assets/78b7a71d-0e43-4828-a118-91c5237909c7"
  />
  
  
  <img width="509" height="109" alt="Screenshot 2025-12-15 at 17 35 44"
  src="https://github.com/user-attachments/assets/6933de52-9b66-4abf-b58b-a5f26d5747e2"
  />

  jif-oai · 2025-12-17 17:08:03 +00:00
  ac6ba286aa
• feat: Constrain values for approval_policy (#7778)

  Constrain `approval_policy` through new `admin_policy` config.
  
  This PR will:
  1. Add a `admin_policy` section to config, with a single field (for now)
  `allowed_approval_policies`. This list constrains the set of
  user-settable `approval_policy`s.
  2. Introduce a new `Constrained<T>` type, which combines a current value
  and a validator function. The validator function ensures disallowed
  values are not set.
  3. Change the type of `approval_policy` on `Config` and
  `SessionConfiguration` from `AskForApproval` to
  `Constrained<AskForApproval>`. The validator function is set by the
  values passed into `allowed_approval_policies`.
  4. `GenericDisplayRow`: add a `disabled_reason: Option<String>`. When
  set, it disables selection of the value and indicates as such in the
  menu. This also makes it unselectable with arrow keys or numbers. This
  is used in the `/approvals` menu.
  
  Follow ups are:
  1. Do the same thing to `sandbox_policy`.
  2. Propagate the allowed set of values through app-server for the
  extension (though already this should prevent app-server from setting
  this values, it's just that we want to disable UI elements that are
  unsettable).
  
  Happy to split this PR up if you prefer, into the logical numbered areas
  above. Especially if there are parts we want to gavel on separately
  (e.g. admin_policy).
  
  Disabled full access:
  <img width="1680" height="380" alt="image"
  src="https://github.com/user-attachments/assets/1fb61c8c-1fcb-4dc4-8355-2293edb52ba0"
  />
  
  Disabled `--yolo` on startup:
  <img width="749" height="76" alt="image"
  src="https://github.com/user-attachments/assets/0a1211a0-6eb1-40d6-a1d7-439c41e94ddb"
  />
  
  CODEX-4087

  gt-oai · 2025-12-17 16:19:27 +00:00
  9352c6b235
• 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
• nit: doc (#8186)
  jif-oai · 2025-12-17 15:29:29 +00:00
  45c164a982
• nit: drop dead branch with unified_exec tool (#8182)
  jif-oai · 2025-12-17 13:55:13 +00:00
  2e7e4f6ea6
• nit: prevent race in event rendering (#8181)
  jif-oai · 2025-12-17 13:24:02 +00:00
  0abaf1b57c
• fix: flaky test 6 (#8175)
  jif-oai · 2025-12-17 11:59:13 +00:00
  2bf57674d6
• feat: fallback unified_exec to shell_command (#8075)
  jif-oai · 2025-12-17 10:29:45 +00:00
  813bdb9010
• Add public skills + improve repo skill discovery and error UX (#8098)

  1. Adds SkillScope::Public end-to-end (core + protocol) and loads skills
  from the public cache directory
  2. Improves repo skill discovery by searching upward for the nearest
  .codex/skills within a git repo
  3. Deduplicates skills by name with deterministic ordering to avoid
  duplicates across sources
  4. Fixes garbled “Skill errors” overlay rendering by preventing pending
  history lines from being injected during the modal
  5. Updates the project docs “Skills” intro wording to avoid hardcoded
  paths

  xl-openai · 2025-12-17 01:35:49 -08:00
  4897efcced
• Fixed resume matching to respect case insensitivity when using WSL mount points (#8000)

  This fixes #7995

  Eric Traut · 2025-12-16 16:27:38 -08:00
  42b8f28ee8
• Revert "chore: review in read-only (#7593)" (#8127)

  This reverts commit 291b54a762.
  
  This commit was intended to prevent the model from making code changes
  during `/review`, which is sometimes does. Unfortunately, it has other
  unintended side effects that cause `/review` to fail in a variety of
  ways. See #8115 and #7815. We've therefore decided to revert this
  change.

  Eric Traut · 2025-12-16 12:01:54 -08:00
  bbc5675974
• nit: trace span for regular task (#8053)

  Logs are too spammy
  
  ---------
  
  Co-authored-by: Anton Panasenko <apanasenko@openai.com>

  jif-oai · 2025-12-16 16:53:15 +00:00
  d7482510b1
• feat: do not compact on last user turn (#8060)
  jif-oai · 2025-12-16 15:36:33 +00:00
  c9f5b9a6df
• feat: close unified_exec at end of turn (#8052)
  jif-oai · 2025-12-16 12:16:43 +00:00
  ae57e18947
• feat: if .codex is a sub-folder of a writable root, then make it read-only to the sandbox (#8088)

  In preparation for in-repo configuration support, this updates
  `WritableRoot::get_writable_roots_with_cwd()` to include the `.codex`
  subfolder in `WritableRoot.read_only_subpaths`, if it exists, as we
  already do for `.git`.
  
  As noted, currently, like `.git`, `.codex` will only be read-only under
  macOS Seatbelt, but we plan to bring support to other OSes, as well.
  
  Updated the integration test in `seatbelt.rs` so that it actually
  attempts to run the generated Seatbelt commands, verifying that:
  
  - trying to write to `.codex/config.toml` in a writable root fails
  - trying to write to `.git/hooks/pre-commit` in a writable root fails
  - trying to write to the writable root containing the `.codex` and
  `.git` subfolders succeeds

  Michael Bolin · 2025-12-15 22:54:43 -08:00
  bef36f4ae7
• chore(shell_command) fix freeform timeout output (#7791)

  ## Summary
  Adding an additional integration test for timeout_ms
  
  ## Testing
  - [x] these are tests

  Dylan Hurd · 2025-12-15 19:26:39 -08:00
  b9d1a087ee
• feat: merge remote models instead of destructing (#7997)

  - merge remote models instead of destructing
  - make config values have more precedent over remote values

  Ahmed Ibrahim · 2025-12-15 18:02:35 -08:00
  c0a12b3952
• fix parallel tool calls (#7956)
  Ahmed Ibrahim · 2025-12-16 01:28:27 +00:00
  d802b18716
• Fixes mcp elicitation test that fails for me when run locally (#8020)
  Eric Traut · 2025-12-15 16:23:04 -08:00
  d9554c8191
• chore: persist comments in edit (#7931)

  This PR makes sure that inline comment is preserved for mcp server
  config and arbitrary key/value setPath config.
  
  ---------
  
  Co-authored-by: celia-oai <celia@openai.com>

  jif-oai · 2025-12-15 16:05:49 -08:00
  3ee5c40261
• better name for windows sandbox features (#8077)

  `--enable enable...` is a bad look

  iceweasel-oai · 2025-12-15 10:15:40 -08:00
  b4635ccc07
• feat: ghost snapshot v2 (#8055)

  This PR updates ghost snapshotting to avoid capturing oversized
  untracked artifacts while keeping undo safe. Snapshot creation now
  builds a temporary index from `git status --porcelain=2 -z`, writes a
  tree and detached commit without touching refs, and records any ignored
  large files/dirs in the snapshot report. Undo uses that metadata to
  preserve large local artifacts while still cleaning up new transient
  files.

  jif-oai · 2025-12-15 11:14:36 +01:00
  0d9801d448
• feat: config ghost commits (#7873)
  jif-oai · 2025-12-15 09:13:06 +01:00
  4274e6189a
• Do not panic when session contains a tool call without an output (#8048)

  Normally, all tool calls within a saved session should have a response,
  but there are legitimate reasons for the response to be missing. This
  can occur if the user canceled the call or there was an error of some
  sort during the rollout. We shouldn't panic in this case.
  
  This is a partial fix for #7990

  Eric Traut · 2025-12-14 22:16:49 -08:00
  1e3cad95c0
• Reimplement skills loading using SkillsManager + skills/list op. (#7914)

  refactor the way we load and manage skills:
  1. Move skill discovery/caching into SkillsManager and reuse it across
  sessions.
  2. Add the skills/list API (Op::ListSkills/SkillsListResponse) to fetch
  skills for one or more cwds. Also update app-server for VSCE/App;
  3. Trigger skills/list during session startup so UIs preload skills and
  handle errors immediately.

  xl-openai · 2025-12-14 09:58:17 -08:00
  5d77d4db6b
• [codex] add otel tracing (#7844)
  Anton Panasenko · 2025-12-12 17:07:17 -08:00
  ad7b9d63c3
• 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
• fix: restore MCP startup progress messages in TUI (fixes #7827) (#7828)

  ## Problem
  
  The introduction of `notify_sandbox_state_change()` in #7112 caused a
  regression where the blocking call in `Session::new()` waits for all MCP
  servers to fully initialize before returning. This prevents the TUI
  event loop from starting, resulting in `McpStartupUpdateEvent` messages
  being emitted but never consumed or displayed. As a result, the app
  appears to hang during startup, and users do not see the expected
  "Booting MCP server: {name}" status line.
  
  Issue: [#7827](https://github.com/openai/codex/issues/7827)
  
  ## Solution
  This change moves sandbox state notification into each MCP server's
  background initialization task. The notification is sent immediately
  after the server transitions to the Ready state. This approach:
  - Avoids blocking `Session::new()`, allowing the TUI event loop to start
  promptly.
  - Ensures each MCP server receives its sandbox state before handling any
  tool calls.
  - Restores the display of "Booting MCP server" status lines during
  startup.
  
  ## Key Changes
  - Added `ManagedClient::notify_sandbox_state()` method.
  - Passed sandbox_state to `McpConnectionManager::initialize()`.
  - Sends sandbox state notification in the background task after the
  server reaches Ready status.
  - Removed blocking notify_sandbox_state_change() methods.
  - Added a chatwidget snapshot test for the "Booting MCP server" status
  line.
  
  ## Regression Details
  
  Regression was bisected to #7112, which introduced the blocking
  behavior.
  
  ---------
  
  Co-authored-by: Michael Bolin <bolinfest@gmail.com>
  Co-authored-by: Michael Bolin <mbolin@openai.com>

  Ivan Murashko · 2025-12-12 22:07:03 +00:00
  c978b6e222
• support 1p (#7945)

  # 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-12 13:36:20 -08:00
  54feceea46
• fix: use PowerShell to parse PowerShell (#7607)

  Previous to this PR, we used a hand-rolled PowerShell parser in
  `windows_safe_commands.rs` to take a `&str` of PowerShell script see if
  it is equivalent to a list of `execvp(3)` invocations, and if so, we
  then test each using `is_safe_powershell_command()` to determine if the
  overall command is safe:
  
  
  https://github.com/openai/codex/blob/6e6338aa876bb4258abe25b02ac6417b8ea9dff0/codex-rs/core/src/command_safety/windows_safe_commands.rs#L89-L98
  
  Unfortunately, our PowerShell parser did not recognize `@(...)` as a
  special construct, so it was treated as an ordinary token. This meant
  that the following would erroneously be considered "safe:"
  
  ```powershell
  ls @(calc.exe)
  ```
  
  The fix introduced in this PR is to do something comparable what we do
  for Bash/Zsh, which is to use a "proper" parser to derive the list of
  `execvp(3)` calls. For Bash/Zsh, we rely on
  https://crates.io/crates/tree-sitter-bash, but there does not appear to
  be a crate of comparable quality for parsing PowerShell statically
  (https://github.com/airbus-cert/tree-sitter-powershell/ is the best
  thing I found).
  
  Instead, in this PR, we use a PowerShell script to parse the input
  PowerShell program to produce the AST.

  Michael Bolin · 2025-12-12 13:06:49 -08:00
  9009490357
• chore(prompt) Update base prompt (#7943)

  ## Summary
  Update base prompt

  Dylan Hurd · 2025-12-12 20:50:49 +00:00
  26d0d822a2
• Elevated Sandbox 4 (#7889)
  iceweasel-oai · 2025-12-12 12:30:38 -08:00
  677732ff65
• chore(prompt) Remove truncation details (#7941)

  Fixes #7867 and #7906
  
  ## Summary
  Update truncation details.

  Dylan Hurd · 2025-12-12 20:21:53 +00:00
  570eb5fe78
• feat: clean config loading and config api (#7924)

  Check the README of the `config_loader` for details

  jif-oai · 2025-12-12 12:01:24 -08:00
  92098d36e8
• chores: models manager (#7937)
  Ahmed Ibrahim · 2025-12-12 18:59:39 +00:00
  149696d959
• Remote compact for API-key users (#7835)
  pakrym-oai · 2025-12-12 10:05:02 -08:00
  b3ddd50eee
• chore(gpt-5.2) prompt update (#7934)

  ## Summary
  Updates

  Dylan Hurd · 2025-12-12 17:50:09 +00:00
  9429e8b219
• feat: more safe commands (#7728)
  jif-oai · 2025-12-12 11:48:25 +01:00
  49bf49c2fa