149 Commits

• feat: external artifacts builder (#13485)

  This PR reverts the built-in artifact render while a decision is being
  reached. No impact expected on any features

  jif-oai · 2026-03-04 20:22:34 +00:00
  2322e49549
• feat(app-server): propagate app-server trace context into core (#13368)

  ### Summary
  Propagate trace context originating at app-server RPC method handlers ->
  codex core submission loop (so this includes spans such as `run_turn`!).
  This implements PR 2 of the app-server tracing rollout.
  
  This also removes the old lower-level env-based reparenting in core so
  explicit request/submission ancestry wins instead of being overridden by
  ambient `TRACEPARENT` state.
  
  ### What changed
  - Added `trace: Option<W3cTraceContext>` to codex_protocol::Submission
  - Taught `Codex::submit()` / `submit_with_id()` to automatically capture
  the current span context when constructing or forwarding a submission
  - Wrapped the core submission loop in a submission_dispatch span
  parented from Submission.trace
  - Warn on invalid submission trace carriers and ignore them cleanly
  - Removed the old env-based downstream reparenting path in core task
  execution
  - Stopped OTEL provider init from implicitly attaching env trace context
  process-wide
  - Updated mcp-server Submission call sites for the new field
  
  Added focused unit tests for:
  - capturing trace context into Submission
  - preferring `Submission.trace` when building the core dispatch span
  
  ### Why
  PR 1 gave us consistent inbound request spans in app-server, but that
  only covered the transport boundary. For long-running work like turns
  and reviews, the important missing piece was preserving ancestry after
  the request handler returns and core continues work on a different async
  path.
  
  This change makes that handoff explicit and keeps the parentage rules
  simple:
  - app-server request span sets the current context
  - `Submission.trace` snapshots that context
  - core restores it once, at the submission boundary
  - deeper core spans inherit naturally
  
  That also lets us stop relying on env-based reparenting for this path,
  which was too ambient and could override explicit ancestry.

  Owen Lin · 2026-03-04 01:03:45 +00:00
  52521a5e40
• Add under-development original-resolution view_image support (#13050)

  ## Summary
  
  Add original-resolution support for `view_image` behind the
  under-development `view_image_original_resolution` feature flag.
  
  When the flag is enabled and the target model is `gpt-5.3-codex` or
  newer, `view_image` now preserves original PNG/JPEG/WebP bytes and sends
  `detail: "original"` to the Responses API instead of using the legacy
  resize/compress path.
  
  ## What changed
  
  - Added `view_image_original_resolution` as an under-development feature
  flag.
  - Added `ImageDetail` to the protocol models and support for serializing
  `detail: "original"` on tool-returned images.
  - Added `PromptImageMode::Original` to `codex-utils-image`.
    - Preserves original PNG/JPEG/WebP bytes.
    - Keeps legacy behavior for the resize path.
  - Updated `view_image` to:
  - use the shared `local_image_content_items_with_label_number(...)`
  helper in both code paths
    - select original-resolution mode only when:
      - the feature flag is enabled, and
      - the model slug parses as `gpt-5.3-codex` or newer
  - Kept local user image attachments on the existing resize path; this
  change is specific to `view_image`.
  - Updated history/image accounting so only `detail: "original"` images
  use the docs-based GPT-5 image cost calculation; legacy images still use
  the old fixed estimate.
  - Added JS REPL guidance, gated on the same feature flag, to prefer JPEG
  at 85% quality unless lossless is required, while still allowing other
  formats when explicitly requested.
  - Updated tests and helper code that construct
  `FunctionCallOutputContentItem::InputImage` to carry the new `detail`
  field.
  
  ## Behavior
  
  ### Feature off
  - `view_image` keeps the existing resize/re-encode behavior.
  - History estimation keeps the existing fixed-cost heuristic.
  
  ### Feature on + `gpt-5.3-codex+`
  - `view_image` sends original-resolution images with `detail:
  "original"`.
  - PNG/JPEG/WebP source bytes are preserved when possible.
  - History estimation uses the GPT-5 docs-based image-cost calculation
  for those `detail: "original"` images.
  
  
  #### [git stack](https://github.com/magus/git-stack-cli)
  - 👉 `1` https://github.com/openai/codex/pull/13050
  - ⏳ `2` https://github.com/openai/codex/pull/13331
  - ⏳ `3` https://github.com/openai/codex/pull/13049

  Curtis 'Fjord' Hawthorne · 2026-03-03 15:56:54 -08:00
  b92146d48b
• feat: wire spreadsheet artifact (#13362)
  jif-oai · 2026-03-03 15:27:37 +00:00
  8159f05dfd
• feat: presentation artifact p1 (#13341)

  Part 1 of presentation tool artifact

  jif-oai · 2026-03-03 11:38:03 +00:00
  4874b9291a
• feat: add local date/timezone to turn environment context (#12947)

  ## Summary
  
  This PR includes the session's local date and timezone in the
  model-visible environment context and persists that data in
  `TurnContextItem`.
  
    ## What changed
  - captures the current local date and IANA timezone when building a turn
  context, with a UTC fallback if the timezone lookup fails
  - includes current_date and timezone in the serialized
  <environment_context> payload
  - stores those fields on TurnContextItem so they survive rollout/history
  handling, subagent review threads, and resume flows
  - treats date/timezone changes as environment updates, so prompt caching
  and context refresh logic do not silently reuse stale time context
  - updates tests to validate the new environment fields without depending
  on a single hardcoded environment-context string
  
  ## test
  
  built a local build and saw it in the rollout file:
  ```
  {"timestamp":"2026-02-26T21:39:50.737Z","type":"response_item","payload":{"type":"message","role":"user","content":[{"type":"input_text","text":"<environment_context>\n  <shell>zsh</shell>\n  <current_date>2026-02-26</current_date>\n  <timezone>America/Los_Angeles</timezone>\n</environment_context>"}]}}
  ```

  Celia Chen · 2026-02-26 23:17:35 +00:00
  90cc4e79a2
• Revert "fix(bazel): replace askama templates with include_str! in memories" (#12795)

  Reverts openai/codex#11778

  jif-oai · 2026-02-25 18:06:17 +00:00
  7b39e76a66
• feat: adding stream parser (#12666)

  Add a stream parser to extract citations (and others) from a stream.
  This support cases where markers are split in differen tokens.
  
  Codex never manage to make this code work so everything was done
  manually. Please review correctly and do not touch this part of the code
  without a very clear understanding of it

  jif-oai · 2026-02-25 13:27:58 +00:00
  5441130e0a
• feat: add large stack test macro (#12768)

  This PR adds the macro `#[large_stack_test]`
  
  This spawns the tests in a dedicated tokio runtime with a larger stack.
  It is useful for tests that needs the full recursion on the harness
  (which is now too deep for windows for example)

  jif-oai · 2026-02-25 13:19:21 +00:00
  5a9a5b51b2
• Agent jobs (spawn_agents_on_csv) + progress UI (#10935)

  ## Summary
  - Add agent job support: spawn a batch of sub-agents from CSV, auto-run,
  auto-export, and store results in SQLite.
  - Simplify workflow: remove run/resume/get-status/export tools; spawn is
  deterministic and completes in one call.
  - Improve exec UX: stable, single-line progress bar with ETA; suppress
  sub-agent chatter in exec.
  
  ## Why
  Enables map-reduce style workflows over arbitrarily large repos using
  the existing Codex orchestrator. This addresses review feedback about
  overly complex job controls and non-deterministic monitoring.
  
  ## Demo (progress bar)
  ```
  ./codex-rs/target/debug/codex exec \
    --enable collab \
    --enable sqlite \
    --full-auto \
    --progress-cursor \
    -c agents.max_threads=16 \
    -C /Users/daveaitel/code/codex \
    - <<'PROMPT'
  Create /tmp/agent_job_progress_demo.csv with columns: path,area and 30 rows:
  path = item-01..item-30, area = test.
  
  Then call spawn_agents_on_csv with:
  - csv_path: /tmp/agent_job_progress_demo.csv
  - instruction: "Run `python - <<'PY'` to sleep a random 0.3–1.2s, then output JSON with keys: path, score (int). Set score = 1."
  - output_csv_path: /tmp/agent_job_progress_demo_out.csv
  PROMPT
  ```
  
  ## Review feedback addressed
  - Auto-start jobs on spawn; removed run/resume/status/export tools.
  - Auto-export on success.
  - More descriptive tool spec + clearer prompts.
  - Avoid deadlocks on spawn failure; pending/running handled safely.
  - Progress bar no longer scrolls; stable single-line redraw.
  
  ## Tests
  - `cd codex-rs && cargo test -p codex-exec`
  - `cd codex-rs && cargo build -p codex-cli`

  daveaitel-openai · 2026-02-24 21:00:19 +00:00
  dcab40123f
• feat: run zsh fork shell tool via shell-escalation (#12649)

  ## Why
  
  This PR switches the `shell_command` zsh-fork path over to
  `codex-shell-escalation` so the new shell tool can use the shared
  exec-wrapper/escalation protocol instead of the `zsh_exec_bridge`
  implementation that was introduced in
  https://github.com/openai/codex/pull/12052. `zsh_exec_bridge` relied on
  UNIX domain sockets, which is not as tamper-proof as the FD-based
  approach in `codex-shell-escalation`.
  
  ## What Changed
  
  - Added a Unix zsh-fork runtime adapter in `core`
  (`core/src/tools/runtimes/shell/unix_escalation.rs`) that:
  - runs zsh-fork commands through
  `codex_shell_escalation::run_escalate_server`
    - bridges exec-policy / approval decisions into `ShellActionProvider`
  - executes escalated commands via a `ShellCommandExecutor` that calls
  `process_exec_tool_call`
  - Updated `ShellRuntime` / `ShellCommandHandler` / tool spec wiring to
  select a `shell_command` backend (`classic` vs `zsh-fork`) while leaving
  the generic `shell` tool path unchanged.
  - Removed the `zsh_exec_bridge`-based session service and deleted
  `core/src/zsh_exec_bridge/mod.rs`.
  - Moved exec-wrapper entrypoint dispatch to `arg0` by handling the
  `codex-execve-wrapper` arg0 alias there, and removed the old
  `codex_core::maybe_run_zsh_exec_wrapper_mode()` hooks from `cli` and
  `app-server` mains.
  - Added the needed `codex-shell-escalation` dependencies for `core` and
  `arg0`.
  
  ## Tests
  
  - `cargo test -p codex-core
  shell_zsh_fork_prefers_shell_command_over_unified_exec`
  - `cargo test -p codex-app-server turn_start_shell_zsh_fork --
  --nocapture`
  - verifies zsh-fork command execution and approval flows through the new
  backend
  - includes subcommand approve/decline coverage using the shared zsh
  DotSlash fixture in `app-server/tests/suite/zsh`
  - To test manually, I added the following to `~/.codex/config.toml`:
  
  ```toml
  zsh_path = "/Users/mbolin/code/codex3/codex-rs/app-server/tests/suite/zsh"
  
  [features]
  shell_zsh_fork = true
  ```
  
  Then I ran `just c` to run the dev build of Codex with these changes and
  sent it the message:
  
  ```
  run `echo $0`
  ```
  
  And it replied with:
  
  ```
    echo $0 printed:
  
    /Users/mbolin/code/codex3/codex-rs/app-server/tests/suite/zsh
  
    In this tool context, $0 reflects the script path used to invoke the shell, not just zsh.
  ```
  
  so the tool appears to be wired up correctly.
  
  ## Notes
  
  - The zsh subcommand-decline integration test now uses `rm` under a
  `WorkspaceWrite` sandbox. The previous `/usr/bin/true` scenario is
  auto-allowed by the new `shell-escalation` policy path, which no longer
  produces subcommand approval prompts.

  Michael Bolin · 2026-02-24 10:31:08 -08:00
  3ca0e7673b
• chore: rm hardcoded PRESETS list (#12650)

  rm `PRESETS` list harcoded in `model_presets` as we now have bundled
  `models.json` with equivalent info.
  
  update logic to rely on bundled models instead, update tests.

  sayan-oai · 2026-02-23 22:35:51 -08:00
  7e46e5b9c2
• refactor(core): move embedded system skills into codex-skills crate (#12435)

  ## Why
  
  `codex-core` was carrying the embedded system-skill sample assets (and a
  `build.rs` that walks those files to register rerun triggers). Those
  assets change infrequently, but any change under `codex-core` still ties
  them to `codex-core`'s build/cache lifecycle.
  
  This change moves the embedded system-skills packaging into a dedicated
  `codex-skills` crate so it can be cached independently. That reduces
  unnecessary invalidation/rebuild pressure on `codex-core` when the
  skills bundle is the only thing that changes.
  
  ## What Changed
  
  - Added a new `codex-rs/skills` crate (`codex-skills`) with:
    - `Cargo.toml`
    - `BUILD.bazel`
    - `build.rs` to track skill asset file changes for Cargo rebuilds
  - `src/lib.rs` containing the embedded system-skills install/cache logic
  previously in `codex-core`
  - Moved the embedded sample skill assets from
  `codex-rs/core/src/skills/assets/samples` to
  `codex-rs/skills/src/assets/samples`.
  - Updated `codex-rs/core/Cargo.toml` to depend on `codex-skills` and
  removed `codex-core`'s direct `include_dir` dependency.
  - Removed `codex-core`'s `build.rs`.
  - Replaced `codex-rs/core/src/skills/system.rs` implementation with a
  thin re-export wrapper to keep existing `codex-core` call sites
  unchanged.
  - Updated workspace manifests/lockfile (`codex-rs/Cargo.toml`,
  `codex-rs/Cargo.lock`) for the new crate.

  Michael Bolin · 2026-02-21 08:34:08 +00:00
  85ce91a5b3
• chore: move config diagnostics out of codex-core (#12427)

  ## Why
  
  Compiling `codex-rs/core` is a bottleneck for local iteration, so this
  change continues the ongoing extraction of config-related functionality
  out of `codex-core` and into `codex-config`.
  
  The goal is not just to move code, but to reduce `codex-core` ownership
  and indirection so more code depends on `codex-config` directly.
  
  ## What Changed
  
  - Moved config diagnostics logic from
  `core/src/config_loader/diagnostics.rs` into
  `config/src/diagnostics.rs`.
  - Updated `codex-core` to use `codex-config` diagnostics types/functions
  directly where possible.
  - Removed the `core/src/config_loader/diagnostics.rs` shim module
  entirely; the remaining `ConfigToml`-specific calls are in
  `core/src/config_loader/mod.rs`.
  - Moved `CONFIG_TOML_FILE` into `codex-config` and updated existing
  references to use `codex_config::CONFIG_TOML_FILE` directly.
  - Added a direct `codex-config` dependency to `codex-cli` for its
  `CONFIG_TOML_FILE` use.

  Michael Bolin · 2026-02-20 23:19:29 -08:00
  1a220ad77d
• Move sanitizer into codex-secrets (#12306)

  ## Summary
  - move the sanitizer implementation into `codex-secrets`
  (`secrets/src/sanitizer.rs`) and re-export `redact_secrets`
  - switch `codex-core` to depend on/import `codex-secrets` for sanitizer
  usage
  - remove the old `utils/sanitizer` crate wiring and refresh lockfiles
  
  ## Testing
  - `just fmt`
  - `cargo test -p codex-secrets`
  - `cargo test -p codex-core --no-run`
  - `cargo clippy -p codex-secrets -p codex-core --all-targets
  --all-features -- -D warnings`
  - `just bazel-lock-update`
  - `just bazel-lock-check`
  
  ## Notes
  - not run: `cargo test --all-features` (full workspace suite)

  viyatb-oai · 2026-02-20 22:47:54 +00:00
  64f3827d10
• fix(bazel): replace askama templates with include_str! in memories (#11778)

  ## Summary
  
  - The experimental Bazel CI builds fail on all platforms because askama
  resolves template paths relative to `CARGO_MANIFEST_DIR`, which points
  outside the Bazel sandbox. This produces errors like:
    ```
  error: couldn't read
  `codex-rs/core/src/memories/../../../../../../../../../../../work/codex/codex/codex-rs/core/templates/memories/consolidation.md`:
  No such file or directory
    ```
  - Replaced `#[derive(Template)]` + `#[template(path = "...")]` with
  `include_str!` + `str::replace()` for the three affected templates
  (`consolidation.md`, `stage_one_input.md`, `read_path.md`).
  `include_str!` resolves paths relative to the source file, which works
  correctly in both Cargo and Bazel builds.
  - The templates only use simple `{{ variable }}` substitution with no
  control flow or filters, so no askama functionality is lost.
  - Removes the `askama` dependency from `codex-core` since it was the
  only crate using it. The workspace-level dependency definition is left
  in place.
  - This matches the existing pattern used throughout the codebase — e.g.
  `codex-rs/core/src/memories/mod.rs` already uses
  `include_str!("../../templates/memories/stage_one_system.md")` for the
  fourth template file.
  
  ## Test plan
  
  - [ ] Verify Bazel (experimental) CI passes on all platforms
  - [ ] Verify rust-ci (Cargo) builds and tests continue to pass
  - [ ] Verify `cargo test -p codex-core` passes locally

  Alex Kwiatkowski · 2026-02-19 16:29:26 -05:00
  fe7054a346
• chore(deps): bump arc-swap from 1.8.0 to 1.8.2 in /codex-rs (#11890)

  Bumps [arc-swap](https://github.com/vorner/arc-swap) from 1.8.0 to
  1.8.2.
  <details>
  <summary>Changelog</summary>
  <p><em>Sourced from <a
  href="https://github.com/vorner/arc-swap/blob/master/CHANGELOG.md">arc-swap's
  changelog</a>.</em></p>
  <blockquote>
  <h1>1.8.2</h1>
  <ul>
  <li>Proper gate of <code>Pin</code> (since 1.39 - we are not using only
  <code>Pin</code>, but also
  <code>Pin::into_inner</code>, <a
  href="https://redirect.github.com/vorner/arc-swap/issues/197">#197</a>).</li>
  </ul>
  <h1>1.8.1</h1>
  <ul>
  <li>Some more careful orderings (<a
  href="https://redirect.github.com/vorner/arc-swap/issues/195">#195</a>).</li>
  </ul>
  </blockquote>
  </details>
  <details>
  <summary>Commits</summary>
  <ul>
  <li><a
  href="https://github.com/vorner/arc-swap/commit/19f0d661a27bb6312c6ba9e19e1453db19c30ab5"><code>19f0d66</code></a>
  Version 1.8.2</li>
  <li><a
  href="https://github.com/vorner/arc-swap/commit/c222a22864dce497f1924eb788f6b05b760a9c10"><code>c222a22</code></a>
  Release 1.8.1</li>
  <li><a
  href="https://github.com/vorner/arc-swap/commit/cccf3548a8c1c83028f3a9cff83d89d1b89b17b8"><code>cccf354</code></a>
  Upgrade the other ordering too, for transitivity</li>
  <li><a
  href="https://github.com/vorner/arc-swap/commit/e94df5511ab2eb0b04959af2505ea1be51e67242"><code>e94df55</code></a>
  Merge pull request <a
  href="https://redirect.github.com/vorner/arc-swap/issues/195">#195</a>
  from 0xfMel/master</li>
  <li><a
  href="https://github.com/vorner/arc-swap/commit/bd5d3276e4cfc37b90676260c93d8545d9b9b911"><code>bd5d327</code></a>
  Fix Debt::pay failure ordering</li>
  <li><a
  href="https://github.com/vorner/arc-swap/commit/22431daf6411cedfa3ebdf7fd8777dc579858b9a"><code>22431da</code></a>
  Merge pull request <a
  href="https://redirect.github.com/vorner/arc-swap/issues/189">#189</a>
  from atouchet/rdm</li>
  <li><a
  href="https://github.com/vorner/arc-swap/commit/b142bd81dae89d5f7a934bb399103f7f029faeed"><code>b142bd8</code></a>
  Update Readme</li>
  <li>See full diff in <a
  href="https://github.com/vorner/arc-swap/compare/v1.8.0...v1.8.2">compare
  view</a></li>
  </ul>
  </details>
  <br />
  
  
  [![Dependabot compatibility
  score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=arc-swap&package-manager=cargo&previous-version=1.8.0&new-version=1.8.2)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
  
  Dependabot will resolve any conflicts with this PR as long as you don't
  alter it yourself. You can also trigger a rebase manually by commenting
  `@dependabot rebase`.
  
  [//]: # (dependabot-automerge-start)
  [//]: # (dependabot-automerge-end)
  
  ---
  
  <details>
  <summary>Dependabot commands and options</summary>
  <br />
  
  You can trigger Dependabot actions by commenting on this PR:
  - `@dependabot rebase` will rebase this PR
  - `@dependabot recreate` will recreate this PR, overwriting any edits
  that have been made to it
  - `@dependabot show <dependency name> ignore conditions` will show all
  of the ignore conditions of the specified dependency
  - `@dependabot ignore this major version` will close this PR and stop
  Dependabot creating any more for this major version (unless you reopen
  the PR or upgrade to it yourself)
  - `@dependabot ignore this minor version` will close this PR and stop
  Dependabot creating any more for this minor version (unless you reopen
  the PR or upgrade to it yourself)
  - `@dependabot ignore this dependency` will close this PR and stop
  Dependabot creating any more for this dependency (unless you reopen the
  PR or upgrade to it yourself)
  
  
  </details>
  
  Signed-off-by: dependabot[bot] <support@github.com>
  Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

  dependabot[bot] · 2026-02-17 11:45:45 -08:00
  15cd796749
• core: snapshot tests for compaction requests, post-compaction layout, some additional compaction tests (#11487)

  This PR keeps compaction context-layout test coverage separate from
  runtime compaction behavior changes, so runtime logic review can stay
  focused.
  
  ## Included
  - Adds reusable context snapshot helpers in
  `core/tests/common/context_snapshot.rs` for rendering model-visible
  request/history shapes.
  - Standardizes helper naming for readability:
    - `format_request_input_snapshot`
    - `format_response_items_snapshot`
    - `format_labeled_requests_snapshot`
    - `format_labeled_items_snapshot`
  - Expands snapshot coverage for both local and remote compaction flows:
    - pre-turn auto-compaction
    - pre-turn failure/context-window-exceeded paths
    - mid-turn continuation compaction
    - manual `/compact` with and without prior user turns
  - Captures both sides where relevant:
    - compaction request shape
    - post-compaction history layout shape
  - Adds/uses shared request-inspection helpers so assertions target
  structured request content instead of ad-hoc JSON string parsing.
  - Aligns snapshots/assertions to current behavior and leaves explicit
  `TODO(ccunningham)` notes where behavior is known and intentionally
  deferred.
  
  ## Not Included
  - No runtime compaction logic changes.
  - No model-visible context/state behavior changes.

  Charley Cunningham · 2026-02-14 19:57:10 -08:00
  85034b189e
• chore: drop and clean from phase 1 (#11605)

  This PR is mostly cleaning and simplifying phase 1 of memories

  jif-oai · 2026-02-12 17:23:00 +00:00
  f741fad5c0
• Extract codex-config from codex-core (#11389)

  `codex-core` had accumulated config loading, requirements parsing,
  constraint logic, and config-layer state handling in a single crate.
  This change extracts that subsystem into `codex-config` to reduce
  `codex-core` rebuild/test surface area and isolate future config work.
  
  ## What Changed
  
  ### Added `codex-config`
  
  - Added new workspace crate `codex-rs/config` (`codex-config`).
  - Added workspace/build wiring in:
    - `codex-rs/Cargo.toml`
    - `codex-rs/config/Cargo.toml`
    - `codex-rs/config/BUILD.bazel`
  - Updated lockfiles (`codex-rs/Cargo.lock`, `MODULE.bazel.lock`).
  - Added `codex-core` -> `codex-config` dependency in
  `codex-rs/core/Cargo.toml`.
  
  ### Moved config internals from `core` into `config`
  
  Moved modules to `codex-rs/config/src/`:
  
  - `core/src/config/constraint.rs` -> `config/src/constraint.rs`
  - `core/src/config_loader/cloud_requirements.rs` ->
  `config/src/cloud_requirements.rs`
  - `core/src/config_loader/config_requirements.rs` ->
  `config/src/config_requirements.rs`
  - `core/src/config_loader/fingerprint.rs` -> `config/src/fingerprint.rs`
  - `core/src/config_loader/merge.rs` -> `config/src/merge.rs`
  - `core/src/config_loader/overrides.rs` -> `config/src/overrides.rs`
  - `core/src/config_loader/requirements_exec_policy.rs` ->
  `config/src/requirements_exec_policy.rs`
  - `core/src/config_loader/state.rs` -> `config/src/state.rs`
  
  `codex-config` now re-exports this surface from `config/src/lib.rs` at
  the crate top level.
  
  ### Updated `core` to consume/re-export `codex-config`
  
  - `core/src/config_loader/mod.rs` now imports/re-exports config-loader
  types/functions from top-level `codex_config::*`.
  - Local moved modules were removed from `core/src/config_loader/`.
  - `core/src/config/mod.rs` now re-exports constraint types from
  `codex_config`.

  Michael Bolin · 2026-02-11 10:02:49 -08:00
  577a416f9a
• Remove test-support feature from codex-core and replace it with explicit test toggles (#11405)

  ## Why
  
  `codex-core` was being built in multiple feature-resolved permutations
  because test-only behavior was modeled as crate features. For a large
  crate, those permutations increase compile cost and reduce cache reuse.
  
  ## Net Change
  
  - Removed the `test-support` crate feature and related feature wiring so
  `codex-core` no longer needs separate feature shapes for test consumers.
  - Standardized cross-crate test-only access behind
  `codex_core::test_support`.
  - External test code now imports helpers from
  `codex_core::test_support`.
  - Underlying implementation hooks are kept internal (`pub(crate)`)
  instead of broadly public.
  
  ## Outcome
  
  - Fewer `codex-core` build permutations.
  - Better incremental cache reuse across test targets.
  - No intended production behavior change.

  Michael Bolin · 2026-02-10 22:44:02 -08:00
  476c1a7160
• Remove deterministic_process_ids feature to avoid duplicate codex-core builds (#11393)

  ## Why
  
  `codex-core` enabled `deterministic_process_ids` through a self
  dev-dependency.
  That forced a second feature-resolved build of the same crate, which
  increased
  compile time and test latency.
  
  ## What Changed
  
  - Removed the `deterministic_process_ids` feature from
  `codex-rs/core/Cargo.toml`.
  - Removed the self dev-dependency on `codex-core` that enabled that
  feature.
  - Removed the Bazel `deterministic_process_ids` crate feature for
  `codex-core`.
  - Added a test-only `AtomicBool` override in unified exec process-id
  allocation.
  - Added a test-support setter for that override and re-exported it from
  `codex-core`.
  - Enabled deterministic process IDs in integration tests via
  `core_test_support` ctor.
  
  ## Behavior
  
  - Production behavior remains random process IDs.
  - Unit tests remain deterministic via `cfg(test)`.
  - Integration tests remain deterministic via explicit test-support
  initialization.
  
  ## Validation
  
  - `just fmt`
  - `cargo test -p codex-core unified_exec::`
  - `cargo test -p codex-core --test all unified_exec -- --test-threads=1`
  - `cargo tree -p codex-core -e features` (verified the removed feature
  path)

  Michael Bolin · 2026-02-10 19:07:01 -08:00
  b68a84ee8e
• chore: rename codex-command to codex-shell-command (#11378)

  This addresses some post-merge feedback on
  https://github.com/openai/codex/pull/11361:
  
  - crate rename
  - reuse `detect_shell_type()` utility

  Michael Bolin · 2026-02-10 17:03:46 -08:00
  d44f4205fb
• # Split command parsing/safety out of codex-core into new codex-command (#11361)

  `codex-core` had accumulated command parsing and command safety logic
  (`bash`, `powershell`, `parse_command`, and `command_safety`) that is
  logically cohesive but orthogonal to most core session/runtime logic.
  Keeping this code in `codex-core` made the crate increasingly monolithic
  and raised iteration cost for unrelated core changes.
  
  This change extracts that surface into a dedicated crate,
  `codex-command`, while preserving existing `codex_core::...` call sites
  via re-exports.
  
  ## Why this refactor
  
  During analysis, command parsing/safety stood out as a good first split
  because it has:
  
  - a clear domain boundary (shell parsing + safety classification)
  - relatively self-contained dependencies (notably `tree-sitter` /
  `tree-sitter-bash`)
  - a meaningful standalone test surface (`134` tests moved with the
  crate)
  - many downstream uses that benefit from independent compilation and
  caching
  
  The practical problem was build latency from a large `codex-core`
  compile/test graph. Clean-build timings before and after this split
  showed measurable wins:
  
  - `cargo check -p codex-core`: `57.08s` -> `53.54s` (~`6.2%` faster)
  - `cargo test -p codex-core --no-run`: `2m39.9s` -> `2m20s` (~`12.4%`
  faster)
  - `codex-core lib` compile unit: `57.18s` -> `49.67s` (~`13.1%` faster)
  - `codex-core lib(test)` compile unit: `60.87s` -> `53.21s` (~`12.6%`
  faster)
  
  This gives a concrete reduction in core build overhead without changing
  behavior.
  
  ## What changed
  
  ### New crate
  
  - Added `codex-rs/command` as workspace crate `codex-command`.
  - Added:
    - `command/src/lib.rs`
    - `command/src/bash.rs`
    - `command/src/powershell.rs`
    - `command/src/parse_command.rs`
    - `command/src/command_safety/*`
    - `command/src/shell_detect.rs`
    - `command/BUILD.bazel`
  
  ### Code moved out of `codex-core`
  
  - Moved modules from `core/src` into `command/src`:
    - `bash.rs`
    - `powershell.rs`
    - `parse_command.rs`
    - `command_safety/*`
  
  ### Dependency graph updates
  
  - Added workspace member/dependency entries for `codex-command` in
  `codex-rs/Cargo.toml`.
  - Added `codex-command` dependency to `codex-rs/core/Cargo.toml`.
  - Removed `tree-sitter` and `tree-sitter-bash` from `codex-core` direct
  deps (now owned by `codex-command`).
  
  ### API compatibility for callers
  
  To avoid immediate downstream churn, `codex-core` now re-exports the
  moved modules/functions:
  
  - `codex_command::bash`
  - `codex_command::powershell`
  - `codex_command::parse_command`
  - `codex_command::is_safe_command`
  - `codex_command::is_dangerous_command`
  
  This keeps existing `codex_core::...` paths working while enabling
  gradual migration to direct `codex-command` usage.
  
  ### Internal decoupling detail
  
  - Added `command::shell_detect` so moved `bash`/`powershell` logic no
  longer depends on core shell internals.
  - Adjusted PowerShell helper visibility in `codex-command` for existing
  core test usage (`UTF8` prefix helper + executable discovery functions).
  
  ## Validation
  
  - `just fmt`
  - `just fix -p codex-command -p codex-core`
  - `cargo test -p codex-command` (`134` passed)
  - `cargo test -p codex-core --no-run`
  - `cargo test -p codex-core shell_command_handler`
  
  ## Notes / follow-up
  
  This commit intentionally prioritizes boundary extraction and
  compatibility. A follow-up can migrate downstream crates to depend
  directly on `codex-command` (instead of through `codex-core` re-exports)
  to realize additional incremental build wins.

  Michael Bolin · 2026-02-10 14:43:16 -08:00
  d8f9bb65e2
• Extract hooks into dedicated crate (#11311)

  Summary
  - move `core/src/hooks` implementation into a new `codex-hooks` crate
  with its own manifest
  - update `codex-rs` workspace and `codex-core` crate to depend on the
  extracted `hooks` crate and wire up the shared APIs
  - ensure references, modules, and lockfile reflect the new crate layout
  
  Testing
  - Not run (not requested)

  jif-oai · 2026-02-10 13:42:17 +00:00
  d735df1f50
• memories: add extraction and prompt module foundation (#11200)

  ## Summary
  - add the new `core/src/memories` module (phase-one parsing, rollout
  filtering, storage, selection, prompts)
  - add Askama-backed memory templates for stage-one input/system and
  consolidation prompts
  - add module tests for parsing, filtering, path bucketing, and summary
  maintenance
  
  ## Testing
  - just fmt
  - cargo test -p codex-core --lib memories::

  jif-oai · 2026-02-10 10:10:24 +00:00
  6049ff02a0
• feat: search_tool (#10657)

  **Why We Did This**
  - The goal is to reduce MCP tool context pollution by not exposing the
  full MCP tool list up front
  - It forces an explicit discovery step (`search_tool_bm25`) so the model
  narrows tool scope before making MCP calls, which helps relevance and
  lowers prompt/tool clutter.
  
  **What It Changed**
  - Added a new experimental feature flag `search_tool` in
  `core/src/features.rs:90` and `core/src/features.rs:430`.
  - Added config/schema support for that flag in
  `core/config.schema.json:214` and `core/config.schema.json:1235`.
  - Added BM25 dependency (`bm25`) in `Cargo.toml:129` and
  `core/Cargo.toml:23`.
  - Added new tool handler `search_tool_bm25` in
  `core/src/tools/handlers/search_tool_bm25.rs:18`.
  - Registered the handler and tool spec in
  `core/src/tools/handlers/mod.rs:11` and `core/src/tools/spec.rs:780` and
  `core/src/tools/spec.rs:1344`.
  - Extended `ToolsConfig` to carry `search_tool` enablement in
  `core/src/tools/spec.rs:32` and `core/src/tools/spec.rs:56`.
  - Injected dedicated developer instructions for tool-discovery workflow
  in `core/src/codex.rs:483` and `core/src/codex.rs:1976`, using
  `core/templates/search_tool/developer_instructions.md:1`.
  - Added session state to store one-shot selected MCP tools in
  `core/src/state/session.rs:27` and `core/src/state/session.rs:131`.
  - Added filtering so when feature is enabled, only selected MCP tools
  are exposed on the next request (then consumed) in
  `core/src/codex.rs:3800` and `core/src/codex.rs:3843`.
  - Added E2E suite coverage for
  enablement/instructions/hide-until-search/one-turn-selection in
  `core/tests/suite/search_tool.rs:72`,
  `core/tests/suite/search_tool.rs:109`,
  `core/tests/suite/search_tool.rs:147`, and
  `core/tests/suite/search_tool.rs:218`.
  - Refactored test helper utilities to support config-driven tool
  collection in `core/tests/suite/tools.rs:281`.
  
  **Net Behavioral Effect**
  - With `search_tool` **off**: existing MCP behavior (tools exposed
  normally).
  - With `search_tool` **on**: MCP tools start hidden, model must call
  `search_tool_bm25`, and only returned `selected_tools` are available for
  the next model call.

  Anton Panasenko · 2026-02-09 12:53:50 -08:00
  becc3a0424
• Load requirements on windows (#10770)

  We support requirements on Unix, loading from
  `/etc/codex/requirements.toml`. On MacOS, we also support MDM.
  
  Now, on Windows, we'll load requirements from
  `%ProgramData%\OpenAI\Codex\requirements.toml`

  gt-oai · 2026-02-09 16:05:38 +00:00
  9fe925b15a
• feat: include NetworkConfig through ExecParams (#11105)

  This PR adds the following field to `Config`:
  
  ```rust
  pub network: Option<NetworkProxy>,
  ```
  
  Though for the moment, it will always be initialized as `None` (this
  will be addressed in a subsequent PR).
  
  This PR does the work to thread `network` through to `execute_exec_env()`, `process_exec_tool_call()`, and `UnifiedExecRuntime.run()` to ensure it is available whenever we span a process.

  Michael Bolin · 2026-02-09 03:32:17 +00:00
  383b45279e
• chore: reverse the codex-network-proxy -> codex-core dependency (#11121)
  Michael Bolin · 2026-02-08 17:03:24 -08:00
  ff74aaae21
• Added support for live updates to skills (#10478)

  Add a centralized FileWatcher in codex-core (using notify) that watches
  skill roots from the config layer stack (recursive)
  
  Send `SkillsChanged` events when relevant file system changes are
  detected
  
  On `SkillsChanged`:
  * Invalidate the skills cache immediately in ThreadManager
  * Emit EventMsg::SkillsUpdateAvailable to active sessions
  ~~* Broadcast a new app-server notification:
  SkillsListUpdatedNotification~~
  
  This change does not inject new items into the event stream. That means
  the agent will not know about new skills, so it won't be able to
  implicitly invoke new skills. It also won't know about changes to
  existing skills, so if it has already read the contents of a modified
  skill, it will not honor the new behavior.
  
  This change also does not detect modifications to AGENTS.md.
  
  I plan to address these limitations in a follow-on PR modeled after
  #9985. Injection of new skills and AGENTS was deemed to risky, hence the
  need to split the feature into two stages. The changes in this PR were
  designed to easily accommodate the second stage once we have some other
  foundational changes in place.
  
  Testing: In addition to automated tests, I did manual testing to confirm
  that newly-created skills, deleted skills, and renamed skills are
  reflected in the TUI skill picker menu. Also confirmed that
  modifications to behaviors for explicitly-invoked skills are honored.
  
  ---------
  
  Co-authored-by: Xin Lin <xl@openai.com>

  Eric Traut · 2026-02-04 15:25:03 -08:00
  7bcc552325
• feat: add APIs to list and download public remote skills (#10448)

  Add API to list / download from remote public skills

  xl-openai · 2026-02-03 14:09:37 -08:00
  f38d181795
• feat: replace custom mcp-types crate with equivalents from rmcp (#10349)

  We started working with MCP in Codex before
  https://crates.io/crates/rmcp was mature, so we had our own crate for
  MCP types that was generated from the MCP schema:
  
  
  https://github.com/openai/codex/blob/8b95d3e082376f4cb23e92641705a22afb28a9da/codex-rs/mcp-types/README.md
  
  Now that `rmcp` is more mature, it makes more sense to use their MCP
  types in Rust, as they handle details (like the `_meta` field) that our
  custom version ignored. Though one advantage that our custom types had
  is that our generated types implemented `JsonSchema` and `ts_rs::TS`,
  whereas the types in `rmcp` do not. As such, part of the work of this PR
  is leveraging the adapters between `rmcp` types and the serializable
  types that are API for us (app server and MCP) introduced in #10356.
  
  Note this PR results in a number of changes to
  `codex-rs/app-server-protocol/schema`, which merit special attention
  during review. We must ensure that these changes are still
  backwards-compatible, which is possible because we have:
  
  ```diff
  - export type CallToolResult = { content: Array<ContentBlock>, isError?: boolean, structuredContent?: JsonValue, };
  + export type CallToolResult = { content: Array<JsonValue>, structuredContent?: JsonValue, isError?: boolean, _meta?: JsonValue, };
  ```
  
  so `ContentBlock` has been replaced with the more general `JsonValue`.
  Note that `ContentBlock` was defined as:
  
  ```typescript
  export type ContentBlock = TextContent | ImageContent | AudioContent | ResourceLink | EmbeddedResource;
  ```
  
  so the deletion of those individual variants should not be a cause of
  great concern.
  
  Similarly, we have the following change in
  `codex-rs/app-server-protocol/schema/typescript/Tool.ts`:
  
  ```
  - export type Tool = { annotations?: ToolAnnotations, description?: string, inputSchema: ToolInputSchema, name: string, outputSchema?: ToolOutputSchema, title?: string, };
  + export type Tool = { name: string, title?: string, description?: string, inputSchema: JsonValue, outputSchema?: JsonValue, annotations?: JsonValue, icons?: Array<JsonValue>, _meta?: JsonValue, };
  ```
  
  so:
  
  - `annotations?: ToolAnnotations` ➡️ `JsonValue`
  - `inputSchema: ToolInputSchema` ➡️ `JsonValue`
  - `outputSchema?: ToolOutputSchema` ➡️ `JsonValue`
  
  and two new fields: `icons?: Array<JsonValue>, _meta?: JsonValue`
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/10349).
  * #10357
  * __->__ #10349
  * #10356

  Michael Bolin · 2026-02-02 17:41:55 -08:00
  66447d5d2c
• feat: Read personal skills from .agents/skills (#10437)

  - Issue: https://github.com/agentskills/agentskills/issues/15
  - Follow-up to https://github.com/openai/codex/pull/10317 (for team/repo
  skills)
  - This change now also loads personal/user skills from
  `$HOME/.agents/skills` (or `~/.agents/skills`) in addition to loading
  from `.agents/skills` inside of git repos.
  - The location of `.system` skills remains unchanged.
  - Keeping backwards compatibility with `~/.codex/skills` for now until
  we fully deprecate.
  
  With skills in both personal folders:
  <img width="831" height="421" alt="image"
  src="https://github.com/user-attachments/assets/ad8ac918-bfe6-4a2d-8a8e-d608c9d3d701"
  />
  
  We load from both places:
  <img width="607" height="236" alt="image"
  src="https://github.com/user-attachments/assets/480f4db0-ae64-4dc1-bdf5-c5de98c16f5c"
  />

  Gav Verma · 2026-02-02 16:49:23 -08:00
  e24058b7a8
• fix: System skills marker includes nested folders recursively (#10350)

  Updated system skills bundled with Codex were not correctly replacing
  the user's skills in their .system folder.
  
  - Fix `.codex-system-skills.marker` not updating by hashing embedded
  system skills recursively (nested dirs + file contents), so updates
  trigger a reinstall.
  - Added a build Cargo hook to rerun if there are changes in
  `src/skills/assets/samples/*`, ensuring embedded skill updates rebuild
  correctly under caching.
  - Add a small unit test to ensure nested entries are included in the
  fingerprint.

  Gav Verma · 2026-02-01 18:17:32 -08:00
  5fb46187b2
• Add websocket telemetry metrics and labels (#10316)

  Summary
  - expose websocket telemetry hooks through the responses client so
  request durations and event processing can be reported
  - record websocket request/event metrics and emit runtime telemetry
  events that the history UI now surfaces
  - improve tests to cover websocket telemetry reporting and guard runtime
  summary updates
  
  
  <img width="824" height="79" alt="Screenshot 2026-01-31 at 5 28 12 PM"
  src="https://github.com/user-attachments/assets/ea9a7965-d8b4-4e3c-a984-ef4fdc44c81d"
  />

  Anton Panasenko · 2026-01-31 19:16:44 -08:00
  101d359cd7
• Validate CODEX_HOME before resolving (#10249)

  Summary
  - require `CODEX_HOME` to point to an existing directory before
  canonicalizing and surface clear errors otherwise
  - share the same helper logic in both `core` and `rmcp-client` and add
  unit tests that cover missing, non-directory, valid, and default paths
  
  This addresses #9222

  Eric Traut · 2026-01-30 15:46:33 -08:00
  8d142fd63d
• feat: sqlite 1 (#10004)

  Add a `.sqlite` database to be used to store rollout metatdata (and
  later logs)
  This PR is phase 1:
  * Add the database and the required infrastructure
  * Add a backfill of the database
  * Persist the newly created rollout both in files and in the DB
  * When we need to get metadata or a rollout, consider the `JSONL` as the
  source of truth but compare the results with the DB and show any errors

  jif-oai · 2026-01-28 15:29:14 +01:00
  3878c3dc7c
• Add exec policy TOML representation (#10026)

  We'd like to represent these in `requirements.toml`. This just adds the
  representation and the tests, doesn't wire it up anywhere yet.

  gt-oai · 2026-01-28 12:00:10 +00:00
  71b8d937ed
• Another round of improvements for config error messages (#9746)

  In a [recent PR](https://github.com/openai/codex/pull/9182), I made some
  improvements to config error messages so errors didn't leave app server
  clients in a dead state. This is a follow-on PR to make these error
  messages more readable and actionable for both TUI and GUI users. For
  example, see #9668 where the user was understandably confused about the
  source of the problem and how to fix it.
  
  The improved error message:
  1. Clearly identifies the config file where the error was found (which
  is more important now that we support layered configs)
  2. Provides a line and column number of the error
  3. Displays the line where the error occurred and underlines it
  
  For example, if my `config.toml` includes the following:
  ```toml
  [features]
  collaboration_modes = "true"
  ```
  
  Here's the current CLI error message:
  ```
  Error loading config.toml: invalid type: string "true", expected a boolean in `features`
  ```
  
  And here's the improved message:
  ```
  Error loading config.toml:
  /Users/etraut/.codex/config.toml:43:23: invalid type: string "true", expected a boolean
     |
  43 | collaboration_modes = "true"
     |                       ^^^^^^
  ```
  
  The bulk of the new logic is contained within a new module
  `config_loader/diagnostics.rs` that is responsible for calculating the
  text range for a given toml path (which is more involved than I would
  have expected).
  
  In addition, this PR adds the file name and text range to the
  `ConfigWarningNotification` app server struct. This allows GUI clients
  to present the user with a better error message and an optional link to
  open the errant config file. This was a suggestion from @.bolinfest when
  he reviewed my previous PR.

  Eric Traut · 2026-01-23 20:11:09 -08:00
  713ae22c04
• chore(deps): bump arc-swap from 1.7.1 to 1.8.0 in /codex-rs (#9468)

  Bumps [arc-swap](https://github.com/vorner/arc-swap) from 1.7.1 to
  1.8.0.
  <details>
  <summary>Changelog</summary>
  <p><em>Sourced from <a
  href="https://github.com/vorner/arc-swap/blob/master/CHANGELOG.md">arc-swap's
  changelog</a>.</em></p>
  <blockquote>
  <h1>1.8.0</h1>
  <ul>
  <li>Support for Pin (<a
  href="https://redirect.github.com/vorner/arc-swap/issues/185">#185</a>,
  <a
  href="https://redirect.github.com/vorner/arc-swap/issues/183">#183</a>).</li>
  <li>Fix (hopefully) crash on ARM (<a
  href="https://redirect.github.com/vorner/arc-swap/issues/164">#164</a>).</li>
  <li>Fix Miri check (<a
  href="https://redirect.github.com/vorner/arc-swap/issues/186">#186</a>,
  <a
  href="https://redirect.github.com/vorner/arc-swap/issues/156">#156</a>).</li>
  <li>Fix support for Rust 1.31.0.</li>
  <li>Some minor clippy lints.</li>
  </ul>
  </blockquote>
  </details>
  <details>
  <summary>Commits</summary>
  <ul>
  <li><a
  href="https://github.com/vorner/arc-swap/commit/2540d266a837143948a0541a05d200fa1087a7db"><code>2540d26</code></a>
  Version bump to 1.8.0</li>
  <li><a
  href="https://github.com/vorner/arc-swap/commit/9981e3af2351d82fe6f77761ee1e4a8479ec1fc7"><code>9981e3a</code></a>
  Keep &quot;old&quot; Cargo.lock around</li>
  <li><a
  href="https://github.com/vorner/arc-swap/commit/57a8abbfc4100d918bcc4511eaa3c61740fe9c10"><code>57a8abb</code></a>
  Fix documentation links</li>
  <li><a
  href="https://github.com/vorner/arc-swap/commit/346c5b642b00acb30ea8756f8186599a30e1edbc"><code>346c5b6</code></a>
  Fix some clippy warnings</li>
  <li><a
  href="https://github.com/vorner/arc-swap/commit/0bd349a56bd448e0712a034f8892edfb6d4a41f2"><code>0bd349a</code></a>
  Fix support for Rust 1.31.0</li>
  <li><a
  href="https://github.com/vorner/arc-swap/commit/57aa5224c19124ad2fa26eae70fa7778dd2224ac"><code>57aa522</code></a>
  Merge pull request <a
  href="https://redirect.github.com/vorner/arc-swap/issues/185">#185</a>
  from SpriteOvO/pin</li>
  <li><a
  href="https://github.com/vorner/arc-swap/commit/4c0c4ab3218beeb0ae0b73d00e2a6c71b5b612f3"><code>4c0c4ab</code></a>
  Implement <code>RefCnt</code> for <code>Pin\&lt;Arc&gt;</code> and
  <code>Pin\&lt;Rc&gt;</code></li>
  <li><a
  href="https://github.com/vorner/arc-swap/commit/e596275acf37fceceb643a835e8b42563c42d919"><code>e596275</code></a>
  Avoid warnings about hidden lifetimes</li>
  <li><a
  href="https://github.com/vorner/arc-swap/commit/d849a2d17e02b66c58a67f95beff8f072e6a306c"><code>d849a2d</code></a>
  Use SeqCst in debt-lists</li>
  <li><a
  href="https://github.com/vorner/arc-swap/commit/1f9b221da9907d690ff10a119c7d0155e99d09cb"><code>1f9b221</code></a>
  Merge pull request <a
  href="https://redirect.github.com/vorner/arc-swap/issues/186">#186</a>
  from nbdd0121/prov</li>
  <li>Additional commits viewable in <a
  href="https://github.com/vorner/arc-swap/compare/v1.7.1...v1.8.0">compare
  view</a></li>
  </ul>
  </details>
  <br />
  
  
  [![Dependabot compatibility
  score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=arc-swap&package-manager=cargo&previous-version=1.7.1&new-version=1.8.0)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
  
  Dependabot will resolve any conflicts with this PR as long as you don't
  alter it yourself. You can also trigger a rebase manually by commenting
  `@dependabot rebase`.
  
  [//]: # (dependabot-automerge-start)
  [//]: # (dependabot-automerge-end)
  
  ---
  
  <details>
  <summary>Dependabot commands and options</summary>
  <br />
  
  You can trigger Dependabot actions by commenting on this PR:
  - `@dependabot rebase` will rebase this PR
  - `@dependabot recreate` will recreate this PR, overwriting any edits
  that have been made to it
  - `@dependabot merge` will merge this PR after your CI passes on it
  - `@dependabot squash and merge` will squash and merge this PR after
  your CI passes on it
  - `@dependabot cancel merge` will cancel a previously requested merge
  and block automerging
  - `@dependabot reopen` will reopen this PR if it is closed
  - `@dependabot close` will close this PR and stop Dependabot recreating
  it. You can achieve the same result by closing it manually
  - `@dependabot show <dependency name> ignore conditions` will show all
  of the ignore conditions of the specified dependency
  - `@dependabot ignore this major version` will close this PR and stop
  Dependabot creating any more for this major version (unless you reopen
  the PR or upgrade to it yourself)
  - `@dependabot ignore this minor version` will close this PR and stop
  Dependabot creating any more for this minor version (unless you reopen
  the PR or upgrade to it yourself)
  - `@dependabot ignore this dependency` will close this PR and stop
  Dependabot creating any more for this dependency (unless you reopen the
  PR or upgrade to it yourself)
  
  
  </details>
  
  Signed-off-by: dependabot[bot] <support@github.com>
  Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

  dependabot[bot] · 2026-01-18 22:25:23 -08:00
  78a359f7fa
• add generated jsonschema for config.toml (#8956)

  ### What
  Add JSON Schema generation for `config.toml`, with checked‑in
  `docs/config.schema.json`. We can move the schema elsewhere if preferred
  (and host it if there's demand).
  
  Add fixture test to prevent drift and `just write-config-schema` to
  regenerate on schema changes.
  
  Generate MCP config schema from `RawMcpServerConfig` instead of
  `McpServerConfig` because that is the runtime type used for
  deserialization.
  
  Populate feature flag values into generated schema so they can be
  autocompleted.
  
  ### Tests
  Added tests + regenerate script to prevent drift. Tested autocompletions
  using generated jsonschema locally with Even Better TOML.
  
  
  
  https://github.com/user-attachments/assets/5aa7cd39-520c-4a63-96fb-63798183d0bc

  sayan-oai · 2026-01-13 10:22:51 -08:00
  40e2405998
• Use markdown for migration screen (#8952)

  Next steps will be routing this to model info

  Ahmed Ibrahim · 2026-01-13 07:41:42 +00:00
  325ce985f1
• fix: leverage codex_utils_cargo_bin() in codex-rs/core/tests/suite (#8887)

  This eliminates our dependency on the `escargot` crate and better
  prepares us for Bazel builds: https://github.com/openai/codex/pull/8875.

  Michael Bolin · 2026-01-08 14:56:16 +00:00
  1e29774fce
• feat: metrics capabilities (#8318)

  Add metrics capabilities to Codex. The `README.md` is up to date.
  
  This will not be merged with the metrics before this PR of course:
  https://github.com/openai/codex/pull/8350

  jif-oai · 2026-01-08 11:47:36 +00:00
  634650dd25
• Add feature for optional request compression (#8767)

  Adds a new feature
  `enable_request_compression` that will compress using zstd requests to
  the codex-backend. Currently only enabled for codex-backend so only enabled for openai providers when using chatgpt::auth even when the feature is enabled
  
  Added a new info log line too for evaluating the compression ratio and
  overhead off compressing before requesting. You can enable with
  `RUST_LOG=$RUST_LOG,codex_client::transport=info`
  
  ```
  2026-01-06T00:09:48.272113Z  INFO codex_client::transport: Compressed request body with zstd pre_compression_bytes=28914 post_compression_bytes=11485 compression_duration_ms=0
  ```

  Channing Conger · 2026-01-07 13:21:40 -08:00
  21c6d40a44
• 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
• Add ExecPolicyManager (#8349)

  Move exec policy management into services to keep turn context
  immutable.

  pakrym-oai · 2025-12-22 09:59:32 -08:00
  96fdbdd434
• feat: introduce ExternalSandbox policy (#8290)

  ## Description
  
  Introduced `ExternalSandbox` policy to cover use case when sandbox
  defined by outside environment, effectively it translates to
  `SandboxMode#DangerFullAccess` for file system (since sandbox configured
  on container level) and configurable `network_access` (either Restricted
  or Enabled by outside environment).
  
  as example you can configure `ExternalSandbox` policy as part of
  `sendUserTurn` v1 app_server API:
  
  ```
   {
              "conversationId": <id>,
              "cwd": <cwd>,
              "approvalPolicy": "never",
              "sandboxPolicy": {
                    "type": ""external-sandbox",
                    "network_access": "enabled"/"restricted"
              },
              "model": <model>,
              "effort": <effort>,
              ....
          }
  ```

  Anton Panasenko · 2025-12-18 17:02:03 -08:00
  3429de21b3
• chore: migrate from Config::load_from_base_config_with_overrides to ConfigBuilder (#8276)

  https://github.com/openai/codex/pull/8235 introduced `ConfigBuilder` and
  this PR updates all call non-test call sites to use it instead of
  `Config::load_from_base_config_with_overrides()`.
  
  This is important because `load_from_base_config_with_overrides()` uses
  an empty `ConfigRequirements`, which is a reasonable default for testing
  so the tests are not influenced by the settings on the host. This method
  is now guarded by `#[cfg(test)]` so it cannot be used by business logic.
  
  Because `ConfigBuilder::build()` is `async`, many of the test methods
  had to be migrated to be `async`, as well. On the bright side, this made
  it possible to eliminate a bunch of `block_on_future()` stuff.

  Michael Bolin · 2025-12-18 16:12:52 -08:00
  3d4ced3ff5