6320 Commits

This Branch

This Branch

All Branches

• Using cached connector directory for discoverable tools list (#21497)

  ## Summary
  
  Startup tool construction currently depends on connector directory
  metadata for `tool_suggest` discoverables. On a cold directory cache,
  that can put slow connector-directory requests on the blocking path even
  though the tools array only needs directory data for install
  suggestions, not for the live connector MCP tools themselves.
  
  This PR keeps the discoverables path off that cold network fetch:
  - read connector directory metadata from cache only when building
  discoverable tools
  - persist connector directory metadata to
  `~/.codex/cache/codex_app_directory/<hash>.json` and use it to hydrate
  the in-memory cache on later runs before the normal refresh path updates
  it
  - use connector-directory-specific cache naming to distinguish this
  metadata cache from the separate Codex Apps tools-spec cache
  
  This reduces first-turn startup work without changing how live connector
  MCP tools are sourced. Longer term, directory-backed install suggestions
  should move to a search-based flow so they no longer need to be inlined
  into the tools prompt at all.
  
  ## Testing
  
  - `cargo test -p codex-connectors`
  - `cargo test -p codex-chatgpt`
  - `cargo test -p codex-core
  request_plugin_install_is_available_without_search_tool_after_discovery_attempts`
  - `cargo test -p codex-core
  tool_suggest_uses_connector_id_fallback_when_directory_cache_is_empty`

  Matthew Zeng · 2026-05-08 14:14:11 -07:00
  2f3a2d7a86
• Enable --deny-warnings for cargo shear (#21616)

  ## Summary
  
  In https://github.com/openai/codex/pull/21584, we disabled doctests for
  crates that lack any doctests. We can enforce that property via `cargo
  shear --deny-warnings`: crates that lack doctests will be flagged if
  doctests are enabled, and crates with doctests will be flagged if
  doctests are disabled.
  
  A few additional notes:
  
  - By adding `--deny-warnings`, `cargo shear` also flagged a number of
  modules that were not reachable at all. Some of those have been removed.
  - This PR removes a usage of `windows_modules!` (since `cargo shear` and
  `rustfmt` couldn't see through it) in favor of simple `#[cfg(target_os =
  "windows")]` macros. As a consequence, many of these files exhibit churn
  in this PR, since they weren't being formatted by `rustfmt` at all on
  main.
  - Again, to make the code more analyzable, this PR also removes some
  usages of `#[path = "cwd_junction.rs"]` in favor of a more standard
  module structure. The bin sidecar structure is still retained, but,
  e.g., `windows-sandbox-rs/src/bin/command_runner.rs‎` was moved to
  `windows-sandbox-rs/src/bin/command_runner/main.rs`, and so on.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Charlie Marsh · 2026-05-08 20:29:00 +00:00
  7c9731c9af
• [codex] Remove legacy after tool use hooks (#21805)

  ## Why
  
  The legacy `AfterToolUse` hook path was still wired through core tool
  dispatch even though the hooks registry never populated any handlers for
  it. The supported hook surface is `PostToolUse`, so the old
  infrastructure was dead code on the hot path.
  
  ## What changed
  
  - Removed the legacy `AfterToolUse` dispatch from `codex-core` tool
  execution.
  - Removed the unused legacy hook payload types and exports from
  `codex-hooks`.
  - Simplified legacy notify handling now that `HookEvent` only carries
  `AfterAgent`.
  
  ## Validation
  
  - `cargo test -p codex-hooks`
  - `cargo test -p codex-core registry`

  pakrym-oai · 2026-05-08 13:20:05 -07:00
  46e2250bcf
• [codex] Delete function-style apply_patch (#21651)

  ## Why
  
  `apply_patch` is now a freeform/custom tool. Keeping the old
  JSON/function-style registration and parsing path left another way for
  models and tests to invoke `apply_patch`, which made the tool surface
  harder to reason about.
  
  ## What changed
  
  - Removed the `ApplyPatchToolType::Function` variant, JSON `apply_patch`
  spec, and handler support for function payloads.
  - Kept `apply_patch_tool_type = freeform` as the supported model
  metadata path, including Bedrock catalog metadata.
  - Migrated `apply_patch` tests and SSE fixtures to custom/freeform tool
  calls.
  
  ## Verification
  
  - `cargo test -p codex-tools -p codex-protocol -p codex-model-provider`
  - `cargo test -p codex-core tools::handlers::apply_patch --lib`
  - `cargo test -p codex-core --test all
  apply_patch_tool_executes_and_emits_patch_events`
  - `cargo test -p codex-core --test all
  apply_patch_reports_parse_diagnostics`
  - `cargo test -p codex-exec test_apply_patch_tool`
  - `just fix -p codex-core`
  - `just fix -p codex-tools -p codex-protocol -p codex-model-provider -p
  codex-exec`

  pakrym-oai · 2026-05-08 13:00:57 -07:00
  e783341b70
• Revert "Publish Python runtime wheels on release" (#21810)

  Reverts openai/codex#21784

  Ahmed Ibrahim · 2026-05-08 22:37:10 +03:00
  cf941ede15
• [codex] request desktop attestation from app (#20619)

  ## Summary
  
  TL;DR: teaches `codex-rs` / app-server to request a desktop-provided
  attestation token and attach it as `x-oai-attestation` on the scoped
  ChatGPT Codex request paths.
  
  ![DeviceCheck attestation
  interface](https://raw.githubusercontent.com/openai/codex/dev/jm/devicecheck-diagram-assets/pr-assets/devicecheck-attestation-interface.png)
  
  ## Details
  
  This PR teaches the Codex app-server runtime how to request and attach
  an attestation token. It does not generate DeviceCheck tokens directly;
  instead, it relies on the connected desktop app to advertise that it can
  generate attestation and then asks that app for a fresh header value
  when needed.
  
  The flow is:
  
  1. The Codex desktop app connects to app-server.
  2. During `initialize`, the app can advertise that it supports
  `requestAttestation`.
  3. Before app-server calls selected ChatGPT Codex endpoints, it sends
  the internal server request `attestation/generate` to the app.
  4. app-server receives a pre-encoded header value back.
  5. app-server forwards that value as `x-oai-attestation` on the scoped
  outbound requests.
  
  The code in this repo is mostly protocol and runtime plumbing: it adds
  the app-server request/response shape, introduces an attestation
  provider in core, wires that provider into Responses / compaction /
  realtime setup paths, and covers the intended scoping with tests. The
  signed macOS DeviceCheck generation remains owned by the desktop app PR.
  
  ## Related PR
  
  - Codex desktop app implementation:
  https://github.com/openai/openai/pull/878649
  
  ## Validation
  
  <details>
  <summary>Tests run</summary>
  
  ```sh
  cargo test -p codex-app-server-protocol
  cargo test -p codex-core attestation --lib
  cargo test -p codex-app-server --lib attestation
  ```
  
  Also ran:
  
  ```sh
  just fix -p codex-core
  just fix -p codex-app-server
  just fix -p codex-app-server-protocol
  just fmt
  just write-app-server-schema
  ```
  
  </details>
  
  <details>
  <summary>E2E DeviceCheck validation</summary>
  
  First validated the signed desktop app boundary directly: launched a
  packaged signed `Codex.app`, sent `attestation/generate`, decoded the
  returned `v1.` attestation header, and validated the extracted
  DeviceCheck token with `personal/jm/verify_devicecheck_token.py` using
  bundle ID `com.openai.codex`. Apple returned `status_code: 200` and
  `is_ok: true`.
  
  Then ran the fuller app + app-server flow. The packaged `Codex.app`
  launched a current-branch app-server via `CODEX_CLI_PATH`, and a local
  MITM proxy intercepted outbound `chatgpt.com` traffic. The app-server
  requested `attestation/generate` from the real Electron app process, and
  the intercepted `/backend-api/codex/responses` traffic included
  `x-oai-attestation` on both routes:
  
  ```text
  GET  /backend-api/codex/responses  Upgrade: websocket  x-oai-attestation: present
  POST /backend-api/codex/responses  Upgrade: none       x-oai-attestation: present
  ```
  
  The captured header decoded to a DeviceCheck token that also validated
  with Apple for `com.openai.codex` (`status_code: 200`, `is_ok: true`,
  team `2DC432GLL2`).
  
  </details>
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Jiaming Zhang · 2026-05-08 12:36:02 -07:00
  5f4d0ec343
• Remove ToolName display helper (#21465)

  ## Why
  
  `ToolName::display()` made it too easy to flatten tool identity and
  accidentally compare rendered strings. Tool identity should stay
  structural until a legacy string boundary actually requires the
  flattened spelling.
  
  ## What
  
  - Removes `ToolName::display()` and relies on the existing `Display`
  impl for messages and errors.
  - Adds structural ordering for `ToolName` and uses it for
  sorting/deduping deferred tools.
  - Carries `ToolName` through tool/sandbox plumbing, flattening only at
  legacy boundaries such as hook payloads, telemetry tags, and Responses
  tool names.
  - Updates MCP normalization tests to assert `ToolName` structure instead
  of rendered strings.
  
  ## Testing
  
  - `cargo test -p codex-mcp test_normalize_tools`
  - `cargo test -p codex-core unavailable_tool`
  - `just fix -p codex-protocol`
  - `just fix -p codex-mcp`
  - `just fix -p codex-core`

  pakrym-oai · 2026-05-08 12:17:48 -07:00
  61142b6169
• Emit accepted line fingerprint analytics (#21601)

  ## Why
  
  Codex assisted-code attribution needs a client-side accepted-code source
  that does not upload raw code. This adds a hash-only analytics event
  derived from the turn diff so downstream attribution can compare
  accepted Codex lines against commit or PR diffs.
  
  ## What Changed
  
  - Parse accepted/effective added lines from the final turn diff and emit
  `codex_accepted_line_fingerprints` analytics.
  - Hash repo, path, and normalized line content before upload; raw code
  and raw diffs are not included in the event.
  - Chunk large fingerprint payloads and send accepted-line fingerprint
  events in isolated requests while preserving normal batching for other
  analytics events.
  - Canonicalize Git remote URLs before repo hashing so SSH/HTTPS GitHub
  remotes join to the same repo hash.
  - Add parser coverage for unified diff hunk lines that look like `+++`
  or `---` file headers.
  
  ## Verification
  
  - `cargo test -p codex-analytics`
  - `cargo test -p codex-git-utils canonicalize_git_remote_url`
  - `just fix -p codex-analytics`
  - `just bazel-lock-check`
  - `git diff --check`

  alexsong-oai · 2026-05-08 12:16:24 -07:00
  bbb6bf0a37
• Publish Python runtime wheels on release (#21784)

  ## Why
  
  Published Python SDK builds depend on an exact `openai-codex-cli-bin`
  runtime package, but the release workflow did not publish that runtime
  package to PyPI. That left the SDK packaging story incomplete: release
  artifacts could produce Codex binaries, but Python users still needed a
  matching wheel carrying the platform-specific runtime and helper
  executables.
  
  This PR is stacked on #21787 so release jobs can include helper binaries
  in runtime wheels: Linux wheels include `bwrap` for sandbox fallback,
  and Windows wheels include the signed sandbox/elevation helpers beside
  `codex.exe`.
  
  ## What changed
  
  - Builds platform-specific `openai-codex-cli-bin` wheels from signed
  release binaries on macOS, Linux, and Windows release runners.
  - Packages Linux `bwrap` into musllinux runtime wheels.
  - Packages Windows sandbox helper executables into Windows runtime
  wheels.
  - Uploads runtime wheels as GitHub release assets and publishes them to
  PyPI using trusted publishing from the `pypi` GitHub environment.
  - Keeps the new Python runtime publish job non-blocking so failures need
  follow-up but do not fail the Rust release workflow.
  - Pins the PyPA publish action to the `v1.13.0` commit SHA for
  reproducible release publishing.
  - Documents that runtime wheels are platform wheels published through
  PyPI trusted publishing.
  
  ## Testing
  
  - `ruby -e 'require "yaml"; ARGV.each { |f| YAML.load_file(f); puts "ok
  #{f}" }' .github/workflows/rust-release.yml
  .github/workflows/rust-release-windows.yml`
  - `git diff --check`
  
  CI is the real end-to-end verification for the release workflow path.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-05-08 22:00:58 +03:00
  9183503b97
• Support resource binaries in Python runtime staging (#21787)

  ## Why
  
  Some Codex runtime distributions need helper executables beside the main
  bundled binary. Linux sandbox fallback needs a packaged `bwrap` when no
  suitable system `bwrap` is available, and Windows sandbox/elevation
  needs helper executables discoverable beside `codex.exe`. The checked-in
  `openai-codex-cli-bin` template already packages everything under
  `codex_cli_bin/bin/**`, but the staging script only copied the main
  Codex binary into that directory.
  
  This PR adds the generic staging primitive needed by release workflows
  to build complete platform runtime wheels without baking
  platform-specific helper names into the package template.
  
  ## What changed
  
  - Added repeatable `stage-runtime --resource-binary` support so release
  workflows can copy extra executables beside the bundled Codex binary.
  - Kept resource selection in workflow code, where the platform target is
  known.
  - Added tests that verify resource binaries are copied into the staged
  runtime package, that the wheel include config covers them, and that the
  CLI forwards repeated `--resource-binary` values.
  
  ## Testing
  
  - `uv run ruff check scripts/update_sdk_artifacts.py
  tests/test_artifact_workflow_and_binaries.py`
  - `uv run --extra dev pytest
  tests/test_artifact_workflow_and_binaries.py::test_stage_runtime_release_copies_resource_binaries
  tests/test_artifact_workflow_and_binaries.py::test_runtime_resource_binaries_are_included_by_wheel_config
  tests/test_artifact_workflow_and_binaries.py::test_stage_runtime_stages_binary_without_type_generation`
  
  Full `tests/test_artifact_workflow_and_binaries.py` still has unrelated
  schema-normalization drift in the local checkout.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-05-08 22:00:44 +03:00
  8956a928a1
• Update models.json (#21776)

  Automated update of models.json.
  
  ---------
  
  Co-authored-by: aibrahim-oai <219906144+aibrahim-oai@users.noreply.github.com>
  Co-authored-by: Ahmed Ibrahim <aibrahim@openai.com>

  github-actions[bot] · 2026-05-08 21:37:23 +03:00
  772e034594
• Load configured environments from CODEX_HOME (#20667)

  ## Why
  
  The earlier PRs add stdio transport support and the config-backed
  environment provider, but the feature remains inert until normal Codex
  entrypoints construct `EnvironmentManager` with enough context to
  discover `CODEX_HOME/environments.toml`. This final stack PR activates
  the provider while preserving the legacy `CODEX_EXEC_SERVER_URL`
  fallback when no environments file exists.
  
  **Stack position:** this is PR 5 of 5. It is the product wiring PR that
  activates the configured environment provider added in PR 4.
  
  ## What Changed
  
  - Thread `codex_home` into `EnvironmentManagerArgs`.
  - Change `EnvironmentManager::new(...)` to load the provider from
  `CODEX_HOME`.
  - Preserve legacy behavior by falling back to
  `DefaultEnvironmentProvider::from_env()` when `environments.toml` is
  absent.
  - Make `environments.toml`-backed managers start new threads with all
  configured environments, default first, while keeping the legacy env-var
  path single-default.
  - Update the app-server, TUI, exec, MCP server, connector, prompt-debug,
  and thread-manager-sample callsites to pass `codex_home` and handle
  provider-loading errors.
  
  ## Self-Review Notes
  
  - The multi-environment startup path is intentionally tied to the
  `environments.toml` provider. Using `>1` configured environment as the
  only signal would also expand the legacy `CODEX_EXEC_SERVER_URL`
  provider because it keeps `local` addressable alongside `remote`.
  - The startup environment list is still derived inside
  `EnvironmentManager`; the provider only says whether its snapshot should
  start new threads with all configured environments.
  - The thread-manager sample was updated to pass the current
  `ThreadManager::new(...)` installation id argument so the stack compiles
  under Bazel.
  
  ## Stack
  
  - 1. https://github.com/openai/codex/pull/20663 - Add stdio exec-server
  listener
  - 2. https://github.com/openai/codex/pull/20664 - Add stdio exec-server
  client transport
  - 3. https://github.com/openai/codex/pull/20665 - Make environment
  providers own default selection
  - 4. https://github.com/openai/codex/pull/20666 - Add CODEX_HOME
  environments TOML provider
  - **5. This PR:** https://github.com/openai/codex/pull/20667 - Load
  configured environments from CODEX_HOME
  
  Split from original draft: https://github.com/openai/codex/pull/20508
  
  ## Validation
  
  - `just fmt`
  - `git diff --check`
  - `bazel build --config=remote --strategy=remote
  --remote_download_toplevel
  //codex-rs/thread-manager-sample:codex-thread-manager-sample`
  - `bazel test --config=remote --strategy=remote
  --remote_download_toplevel
  //codex-rs/exec-server:exec-server-unit-tests`
  - `bazel test --config=remote --strategy=remote
  --remote_download_toplevel --test_sharding_strategy=disabled
  --test_arg=default_thread_environment_selections_use_manager_default_id
  //codex-rs/core:core-unit-tests`
  - `bazel test --config=remote --strategy=remote
  --remote_download_toplevel --test_sharding_strategy=disabled
  --test_arg=start_thread_uses_all_default_environments_from_codex_home
  //codex-rs/core:core-unit-tests`
  
  ## Documentation
  
  This activates `CODEX_HOME/environments.toml`; user-facing documentation
  should be added before this stack is treated as a documented public
  workflow.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-05-08 11:17:56 -07:00
  5f2543b74e
• feat: Use installation ID in remote enrollments (#21662)

  * Pass installation ID for storage on enrollments server for
  deduping/grouping multiple appservers per installation
  * Pass installation ID in remoteControl/status/changed events

  David de Regt · 2026-05-08 17:54:01 +00:00
  872b8b15b3
• [codex] Address some more GHA hygiene issues (#21622)

  This does two things:
  
  - We use `persist-credentials: false` everywhere now. This is
  unfortunately not the default in GitHub Actions, but it prevents
  `actions/checkout` from dropping `secrets.GITHUB_TOKEN` onto disk.
  - We interpose (some) template expansions through environment variables.
  I've limited this to contexts that have non-fixed values; contexts that
  are fixed (like `*.result`) are not dangerous to expand directly inline
  (but maybe we should clean those up in the future for consistency
  anyways).
  
  This is a medium-risk change in terms of CI breakage: I did a scan for
  usage of `git push` and other commands that implicitly use the persisted
  credential, but couldn't find any. Even still, some implicit usages of
  the persisted credentials may be lurking. Please ping ww@ if any issues
  arise.

  William Woodruff · 2026-05-08 10:19:27 -07:00
  8bea5d231a
• Clarify docs folder guidance in AGENTS.md (#21772)

  ## Summary
  
  Codex keeps trying to add documentation to the `docs/` directory. With
  the exception of app server API documentation, the docs for Codex should
  not live in this repo. We don't want the local `docs/` folder to become
  a stale shadow of the official docs.
  
  This PR updates `AGENTS.md` to make that boundary explicit and scopes
  the existing API documentation guidance to app-server docs/examples. It
  also removes the extra `docs/config.md` sections that were recently
  added.

  Eric Traut · 2026-05-08 10:11:57 -07:00
  0a0d09ad21
• [codex] Generalize service tier slash commands (#21745)

  ## Why
  
  `/fast` was wired as a one-off slash command even though model metadata
  now exposes service tiers as catalog data. That meant adding another
  tier, such as a slower/cheaper tier, would require more hardcoded TUI
  plumbing instead of letting the model catalog drive the available
  commands.
  
  This change makes service-tier commands data-driven: each advertised
  `service_tiers` entry becomes a `/name` command using the catalog
  description, while the request path sends the tier `id` only when the
  selected model supports it.
  
  ## What Changed
  
  - Removed the hardcoded `/fast` slash-command variant and introduced
  dynamic service-tier command items in the composer and command popup.
  - Added toggle behavior for service-tier commands: invoking `/name`
  selects that tier, and invoking it again clears the selection.
  - Preserved the existing Fast-mode keybinding/status affordances by
  resolving the current model tier whose name is `fast`, while still
  sending the tier request value such as `priority`.
  - Persisted service-tier selections as raw request strings so non-fast
  tiers can round-trip through config.
  - Updated the Bedrock catalog entry to advertise fast support through
  `service_tiers` with `id: "priority"` and `name: "fast"`.
  - Added defensive filtering in core so unsupported selected service
  tiers are omitted from `/responses` requests.
  
  ## Validation
  
  - Added/updated coverage for dynamic service-tier slash command lookup,
  popup descriptions, composer dispatch, TUI fast toggling, and
  unsupported-tier omission in core request construction.
  - Local tests were not run per request.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-05-08 20:09:51 +03:00
  7c0e54bf59
• Use CARGO_NET_GIT_FETCH_WITH_CLI in rust-ci-full for more reliable git fetches (#21628)

  Cargo uses libgit2 by default. In uv, we gave up this entirely and
  always call out to the git CLI because it is much more reliable. This is
  a part of my attempt to reduce flakes in `rust-ci-full`.

  Zanie Blue · 2026-05-08 09:53:21 -07:00
  47f1d7b40b
• Fix rust-ci-full failures due to missing bwrap (#21604)

  Since https://github.com/openai/codex/pull/21255, `rust-ci-full` has
  been failing due to a missing `bwrap`.
  
  ```
  thread 'main' panicked at linux-sandbox/src/launcher.rs:43:13:
  bubblewrap is unavailable: no system bwrap was found on PATH and no bundled codex-resources/bwrap binary was found next to the Codex executable
  ```
  
  Since the happy path is now to use the system binary, let's ensure
  that's installed.
  
  
  https://github.com/openai/codex/pull/21604/commits/8d5182663158ee2d15965f39eed26ffa339ecb7d
  was necessary for the `bwrap` executable to be discoverable when the
  working directory is `/`.
  
  I ran `rust-ci-full` at
  https://github.com/openai/codex/actions/runs/25528074506
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Zanie Blue · 2026-05-08 09:52:19 -07:00
  05ffa0b1d0
• [sandboxing] Remove Darwin user cache write from Seatbelt network policy (#21443)

  ## Summary
  
  1. Removes the broad `DARWIN_USER_CACHE_DIR` write rule from the macOS
  Seatbelt network policy.
  2. Removes the now unused policy parameter plumbing for that cache path.
  3. Adds sandboxing coverage that keeps `com.apple.trustd.agent` for TLS
  while rejecting the cache write rule.
  
  ## Why
  
  This closes the exact cache poisoning boundary. The earlier `gh` TLS
  issue is now covered by trustd access, so the cache write is no longer
  needed.
  
  ## Validation
  
  1. Rust formatting passed.
  2. The sandboxing crate tests passed.
  3. Local macOS Seatbelt repro with patched policy passed. `gh api`
  returned `21442` without the cache write rule.

  evawong-oai · 2026-05-08 16:43:07 +00:00
  5733e00c79
• chore: thread tui (#21767)
  jif-oai · 2026-05-08 17:53:23 +02:00
  5b87bd2845
• codex-otel: validate provider span attributes consistently (#21749)

  Provider initialization installs process-global OTEL state, so invalid
  trace metadata needs to fail before setup begins.
  
  Use the same span attribute validator as config loading when traces are
  exported so provider startup enforces the config contract without
  duplicating validation logic.

  bbrown-oai · 2026-05-08 08:20:49 -07:00
  607b0dd1f0
• nit: comment (#21763)

  Because of an async discussion

  jif-oai · 2026-05-08 17:15:46 +02:00
  f9bbbafb68
• api: send hyphenated session and thread headers (#21757)

  ## Why
  Some consumers expect conventional hyphenated HTTP headers. Codex
  already sends the session and thread IDs on outbound Responses requests,
  but it only uses the underscore spellings today, which makes those IDs
  harder to consume in systems that normalize or reject underscore header
  names.
  
  Full context here:
  https://openai.slack.com/archives/C08KCGLSPSQ/p1778248578422369
  
  ## What changed
  - `build_session_headers` now emits both `session_id` and `session-id`
  when a session ID is present.
  - It does the same for `thread_id` and `thread-id`.
  - Added regression coverage in `codex-api/tests/clients.rs` and
  `core/tests/suite/client.rs` so both the lower-level client tests and
  the end-to-end request tests assert the two header spellings are
  present.
  
  ## Test plan
  - Added header assertions in `codex-api/tests/clients.rs`.
  - Added request-header assertions in `core/tests/suite/client.rs` for
  both the `/v1/responses` and `/api/codex/responses` request paths.

  jif-oai · 2026-05-08 17:11:19 +02:00
  bd8fc9adb9
• Show permissions and approval mode in the TUI status line (#21677)

  Fixes #21665.
  
  ## Why
  
  The TUI status line is the right place for compact, glanceable session
  state. The original request was motivated by the need to see the active
  permission posture without opening `/permissions` or `/status`,
  especially when switching between safer and more permissive modes during
  a session.
  
  This PR intentionally separates `permissions` from `approval-mode`
  instead of combining them into one status-line item. They answer related
  but different questions: `permissions` describes the active
  sandbox/profile shape, while `approval-mode` describes how command
  approvals are handled. Keeping them separate makes each item
  independently configurable and avoids long combined labels in an already
  space-constrained status line.
  
  The tradeoff is that users who want the full permission posture in the
  status line need to opt into both items. In exchange, users can show
  only the sandbox/profile label, only the approval behavior, or both, and
  named user-defined profiles remain concise. Non-standard permission
  shapes are rendered as `Custom permissions` rather than trying to
  squeeze detailed profile contents into the status line; `/status`
  remains the fuller explanatory surface.
  
  ## What changed
  
  - Added a configurable `permissions` status-line item.
  - Added a separate `approval-mode` status-line item, with `approval` as
  an alias.
  - Render standard permission states compactly as `Read Only`,
  `Workspace`, or `Full Access`.
  - Preserve user-defined permission profile names directly in the status
  line.
  - Render unnamed non-standard permission shapes as `Custom permissions`.
  - Refresh status surfaces when `/permissions` updates the permission
  profile, approval policy, or approval reviewer.
  - Updated status-line preview snapshot coverage for the new items.
  
  ## Verification
  
  - `cargo test -p codex-tui
  status_permissions_non_default_workspace_write_uses_workspace_label`
  - `cargo test -p codex-tui
  permissions_selection_emits_history_cell_when_selection_changes`
  - `cargo insta pending-snapshots --manifest-path tui/Cargo.toml`

  Eric Traut · 2026-05-08 08:03:11 -07:00
  e6312d44f0
• Display blended token count in status line (#21669)

  ## Why
  
  The configurable `/statusline` and terminal title can display session
  token usage. That display was using the raw total token count, which
  includes cached input tokens, so it significantly overstated the token
  usage compared with the blended token count shown elsewhere (in
  `/status` and tracked in goals). This inconsistency resulted in user
  confusion. We don't want to report cached tokens because we don't charge
  for them and they are somewhat of an implementation detail that users
  shouldn't care about.
  
  ## What changed
  
  - Use `TokenUsage::blended_total()` for the `used-tokens` status surface
  item so cached input is excluded.
  - Add a brief comment to `tokens_in_context_window()` clarifying that it
  returns raw `total_tokens`, whose meaning depends on whether the caller
  has last-turn or accumulated usage.

  Eric Traut · 2026-05-08 07:56:13 -07:00
  f86d95a242
• Update models.json (#19896)

  Automated update of models.json.
  
  ---------
  
  Co-authored-by: aibrahim-oai <219906144+aibrahim-oai@users.noreply.github.com>
  Co-authored-by: Ahmed Ibrahim <aibrahim@openai.com>

  github-actions[bot] · 2026-05-08 17:41:55 +03:00
  aadcae9f3c
• [codex] Enable apply_patch freeform by default (#21687)

  ## Summary
  - enable `apply_patch_freeform` by default in the feature registry
  
  ## Why
  - make the freeform `apply_patch` tool available by default when model
  metadata does not explicitly opt into another mode
  
  ## Validation
  - `just fmt`
  - did not run tests
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-05-08 13:15:00 +00:00
  cce059467a
• Allow string service tiers in config TOML (#21697)

  ## Why
  
  `service_tier` in `config.toml` and profile config was still modeled as
  an enum, which blocked newer or experimental service tier IDs even
  though the runtime paths already carry string IDs.
  
  This change makes the TOML-facing config accept string service tier IDs
  directly while keeping the legacy `fast` alias behavior by normalizing
  it to the request value `priority`.
  
  ## What Changed
  
  - change the TOML-facing `service_tier` fields in global and profile
  config to `Option<String>`
  - keep config-load normalization so legacy `fast` still resolves to
  `priority`
  - persist resolved service tier strings directly in config locks so
  arbitrary IDs round-trip cleanly
  - regenerate the config schema and add config coverage for arbitrary
  string IDs plus legacy `fast` normalization
  
  ## Verification
  
  - added config tests for arbitrary string service tiers and legacy
  `fast` normalization
  - ran `just write-config-schema`
  - CI
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-05-08 15:15:00 +03:00
  317213fd33
• [codex] make shutdown pending-touch test deterministic (#21550)

  ## What changed
  - rewrote `shutdown_flushes_pending_metadata_irrelevant_updated_at` to
  seed an existing pending `updated_at` touch directly in
  `RolloutWriterState`
  - kept the shutdown test focused on draining a pending touch, leaving
  the separate coalescing test to cover timing-based deferral
  
  ## Why
  The old test had to complete several async operations inside the 50 ms
  test-only coalescing window. When that sequence took longer, the second
  flush updated `threads.updated_at` immediately and the pre-shutdown
  equality assertion failed, even though shutdown behavior was correct.
  
  ## Validation
  - `cargo test -p codex-rollout
  shutdown_flushes_pending_metadata_irrelevant_updated_at`
  - `cargo test -p codex-rollout`
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-05-08 10:48:45 +02:00
  d9feaffffb
• Omit service_tier from remote /responses/compact requests under API auth (#21676)

  ## Summary
  
  API-key-auth remote compaction requests should not inherit
  `service_tier` from normal `/responses` turns. This path needs to match
  API auth expectations, while ChatGPT-auth remote compaction should keep
  reusing the shared request fields that still apply there.
  
  This change keeps the decision inline in
  `codex-rs/core/src/compact_remote.rs` only. Under API key auth, the
  classic remote `/responses/compact` path now omits `service_tier`; under
  ChatGPT auth, it keeps reusing the configured tier.
  `codex-rs/core/src/compact_remote_v2.rs` is unchanged. The remote
  compaction parity coverage and snapshots were updated to assert the
  API-key omission and preserve the ChatGPT-auth behavior.
  
  ## Testing
  
  - Updated remote compaction parity coverage in
  `codex-rs/core/tests/suite/compact_remote.rs` and the corresponding
  snapshots.

  Ahmed Ibrahim · 2026-05-08 11:15:14 +03:00
  71d80f9a14
• Remove exec research preview banner wording (#21683)

  ## Why
  
  `codex exec` still included the stale `research preview` label in its
  human-readable startup banner, which makes the CLI look older and less
  current than it is.
  
  Fixes #21444.
  
  ## What Changed
  
  Removed the hard-coded ` (research preview)` suffix from the `OpenAI
  Codex v<version>` startup banner in
  `codex-rs/exec/src/event_processor_with_human_output.rs`.
  
  ## Validation
  
  Local validation was not required for this one-line startup banner text
  cleanup.

  Eric Traut · 2026-05-08 00:30:44 -07:00
  d2e71db22a
• Fix feature request Contributing link (#21688)

  Fixes #20870.
  
  ## Summary
  
  The feature request template currently links users to the README
  `#contributing` anchor, but that anchor does not exist. This can confuse
  users who are trying to understand contribution expectations before
  filing a request.
  
  This updates `.github/ISSUE_TEMPLATE/5-feature-request.yml` to point
  `Contributing` at `docs/contributing.md`, matching the repository's
  existing contribution guidance.

  Eric Traut · 2026-05-08 00:23:40 -07:00
  c15ce42a12
• Fix issue template labels (#21686)

  Issue forms should only reference labels that exist in the repository so
  new reports receive the intended automatic labels.
  
  This updates the CLI issue form to stop applying the missing `needs
  triage` label, and changes the documentation issue form from `docs` to
  the existing `documentation` label.
  
  Fixes #21158

  Eric Traut · 2026-05-08 00:22:33 -07:00
  8b1d6875ed
• Fix duplicate CLI issue template description (#21685)

  Fixes #21270.
  
  The CLI bug report template defined `description` twice for the terminal
  emulator field. Because duplicate YAML keys are ambiguous and parsers
  generally keep the later value, the form could drop the multiplexer
  guidance.
  
  This combines that guidance with the terminal examples under a single
  block scalar in `.github/ISSUE_TEMPLATE/3-cli.yml`.

  Eric Traut · 2026-05-08 00:20:17 -07:00
  911841001d
• feat: Update plugin share settings with discoverability (#21637)

  Requires discoverability on plugin/share/updateTargets so the server can
  manage workspace link access consistently, including auto-adding the
  workspace principal for UNLISTED.
  
  Also rejects LISTED on share creation and blocks client-supplied
  workspace principals while preserving response parsing for LISTED.

  xl-openai · 2026-05-07 21:28:18 -07:00
  ae15343243
• feat: enable AWS login credentials for Bedrock auth (#21623)

  ## Summary
  
  Codex's Amazon Bedrock provider signs Mantle requests with SigV4 using
  credentials resolved by the AWS SDK. That worked for standard AWS
  profiles and environment credentials, but AWS CLI console-login profiles
  created by `aws login` require the SDK's `credentials-login` feature to
  resolve `login_session` credentials.
  
  This change enables that credential provider so Bedrock can use AWS
  console-login credentials through the existing provider-owned AWS auth
  path.
  
  While testing the console-login path, we also hit a Mantle-specific
  SigV4 regression from the new split between `session_id` and
  `thread_id`. Mantle does not preserve legacy OpenAI compatibility
  headers that use `snake_case` before SigV4 verification, so signing
  those headers can make the server reconstruct a different canonical
  request. The Bedrock auth path now removes that header class before
  signing, keeping preserved hyphenated Codex/AWS headers such as
  `x-codex-turn-metadata` signed normally.
  
  ## Changes
  
  - Enable `aws-config`'s `credentials-login` feature in
  `codex-rs/aws-auth`.
  - Add a compile-time regression test for
  `aws_config::login::LoginCredentialsProvider`.
  - Strip `snake_case` compatibility headers from Bedrock Mantle SigV4
  requests before signing.
  - Expand the Bedrock auth regression test to cover `session_id`,
  `thread_id`, and future headers of the same shape.
  - Refresh Cargo and Bazel lockfiles for the added `aws-sdk-signin`
  dependency.
  
  ## Tests
  - tested with `aws login` locally and verified that it works as
  intended.

  Celia Chen · 2026-05-08 04:07:59 +00:00
  9cbd4c0371
• Remove skills list extra roots (#21485)

  ## Summary
  - Remove `perCwdExtraUserRoots` / `SkillsListExtraRootsForCwd` from the
  `skills/list` app-server API.
  - Drop Rust app-server and `codex-core-skills` extra-root plumbing so
  skill scans are keyed by the normal cwd/user/plugin roots only.
  - Regenerate app-server schemas and update docs/tests that only existed
  for the removed extra-roots behavior.
  
  ## Validation
  - `just write-app-server-schema`
  - `just fmt`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-core-skills`
  - `just fix -p codex-app-server-protocol`
  - `just fix -p codex-core-skills`
  - `just fix -p codex-app-server`
  - `just fix -p codex-tui`
  
  ## Notes
  - `cargo test -p codex-app-server --test all skills_list` ran the edited
  skills-list cases, but the full filtered run ended on existing
  `skills_changed_notification_is_emitted_after_skill_change` timeout
  after a websocket `401`.
  - `cargo test -p codex-tui --lib` compiled the changed TUI callers, then
  failed two unrelated status permission tests because local
  `/etc/codex/requirements.toml` forbids `DangerFullAccess`.
  - Source-truth check found the OpenAI monorepo still has
  generated/app-server-kit mirror references to the removed field; those
  should be cleaned up when generated app-server types are synced or in a
  companion OpenAI cleanup.

  xli-oai · 2026-05-07 20:56:42 -07:00
  314229fd72
• [codex-analytics] plumb protocol-native review timing (#21434)

  ## Why
  
  We want terminal tool review analytics, but the reducer should not stamp
  review timing from its own wall clock.
  
  This PR plumbs review timing through the real protocol and app-server
  seams so downstream analytics can consume the emitter's timestamps
  directly. Guardian reviews keep their enriched `started_at` /
  `completed_at` analytics fields by deriving those legacy second-based
  values from the same protocol-native millisecond lifecycle timestamps,
  rather than sampling a separate analytics clock.
  
  ## What changed
  
  - add `started_at_ms` to user approval request payloads
  - add `started_at_ms` / `completed_at_ms` to guardian review
  notifications
  - preserve Guardian review `started_at` / `completed_at` enrichment from
  the protocol-native timing source
  - stamp typed `ServerResponse` analytics facts with app-server-observed
  `completed_at_ms`
  - thread the new timing fields through core, protocol, app-server, TUI,
  and analytics fixtures
  
  ## Verification
  
  - `cargo test -p codex-app-server outgoing_message --manifest-path
  codex-rs/Cargo.toml`
  - `cargo test -p codex-app-server-protocol guardian --manifest-path
  codex-rs/Cargo.toml`
  - `cargo test -p codex-tui guardian --manifest-path codex-rs/Cargo.toml`
  - `cargo test -p codex-analytics analytics_client_tests --manifest-path
  codex-rs/Cargo.toml`
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/21434).
  * #18748
  * __->__ #21434
  * #18747
  * #17090
  * #17089
  * #20514

  rhan-oai · 2026-05-07 20:31:41 -07:00
  99016ec732
• Revert "Use --locked in cargo build and lint invocations" (#21646)

  Reverts openai/codex#21602

  pakrym-oai · 2026-05-07 20:05:47 -07:00
  af16baa549
• Send response.processed after remote compaction v2 (#21642)

  ## Why
  
  Remote compaction v2 consumes a normal Responses stream, but that
  compaction-specific stream consumer dropped the `response.completed` id.
  As a result, the `responses_websocket_response_processed` lifecycle
  notification was emitted for normal turn sampling but not after a v2
  remote compaction response was fully processed.
  
  ## What changed
  
  - Return the completed response id alongside the v2 `context_compaction`
  output item.
  - After v2 compacted history is installed, send `response.processed`
  through the same websocket session when the feature is enabled.
  - Add websocket regression coverage for a remote compaction v2 request
  followed by `response.processed`.
  
  ## Verification
  
  - `cargo test -p codex-core --test all
  responses_websocket_sends_response_processed_after_remote_compaction_v2
  -- --nocapture`
  - `cargo test -p codex-core
  collect_context_compaction_output_accepts_additional_output_items --
  --nocapture`

  pakrym-oai · 2026-05-07 19:57:36 -07:00
  dfa1e864a2
• Add CODEX_HOME environments TOML provider (#20666)

  ## Why
  
  After stdio transports and provider-owned defaults exist, Codex needs a
  config-backed provider that can describe more than the single legacy
  `CODEX_EXEC_SERVER_URL` remote. This PR adds that provider without
  activating it in product entrypoints yet, keeping parser/validation
  review separate from runtime wiring.
  
  **Stack position:** this is PR 4 of 5. It builds on PR 3's
  provider/default model and adds the `environments.toml` provider used by
  PR 5.
  
  ## What Changed
  
  - Add `environment_toml.rs` as the TOML-specific home for parsing,
  validation, and provider construction.
  - Keep the TOML schema/provider structs private; the public constructor
  added here is `EnvironmentManager::from_codex_home(...)`.
  - Add `TomlEnvironmentProvider`, including validation for:
    - reserved ids such as `local` and `none`
    - duplicate ids
    - unknown explicit defaults
    - empty programs or URLs
    - exactly one of `url` or `program` per configured environment
  - Support websocket environments with `url = "ws://..."` / `wss://...`.
  - Support stdio-command environments with `program = "..."`.
  - Add helpers to load `environments.toml` from `CODEX_HOME`, but do not
  wire entrypoints to call them yet.
  - Add the `toml` dependency for parsing.
  
  ## Stack
  
  - 1. https://github.com/openai/codex/pull/20663 - Add stdio exec-server
  listener
  - 2. https://github.com/openai/codex/pull/20664 - Add stdio exec-server
  client transport
  - 3. https://github.com/openai/codex/pull/20665 - Make environment
  providers own default selection
  - **4. This PR:** https://github.com/openai/codex/pull/20666 - Add
  CODEX_HOME environments TOML provider
  - 5. https://github.com/openai/codex/pull/20667 - Load configured
  environments from CODEX_HOME
  
  Split from original draft: https://github.com/openai/codex/pull/20508
  
  ## Validation
  
  Not run locally; this was split out of the original draft stack.
  
  ## Documentation
  
  This introduces the config shape for `environments.toml`; user-facing
  documentation should be added before this stack is treated as a
  documented public workflow.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-05-08 01:37:47 +00:00
  07b695190f
• Route view_image through selected environments

  Route view_image through selected environments so image reads use the selected turn environment and cwd, with schema exposure limited to multi-environment toolsets.\n\nCo-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-05-08 01:29:03 +00:00
  1bfc3d9773
• Make environment providers own default selection (#20665)

  ## Why
  
  The next PR in this stack introduces configured environments, where the
  provider knows both which environments exist and which one should be
  selected by default. The existing manager derived the default internally
  by checking for the legacy `remote` and `local` ids, and it treated
  "remote" as equivalent to "has a websocket URL." That does not work
  cleanly for stdio-command remotes because they are remote environments
  without an `exec_server_url`.
  
  **Stack position:** this is PR 3 of 5. It is the environment-model
  bridge between PR 2's transport enum and PR 4's TOML provider.
  
  ## What Changed
  
  - Add `DefaultEnvironmentSelection` to the `EnvironmentProvider`
  contract:
    - `Derived` preserves the old `remote`-then-`local` fallback behavior.
  - `Environment(id)` lets a provider explicitly select a configured
  default.
  - `Disabled` lets a provider intentionally expose no default
  environment.
  - Move the legacy `CODEX_EXEC_SERVER_URL=none` default-disabling
  behavior into `DefaultEnvironmentProvider`.
  - Make `EnvironmentManager` validate explicit provider defaults and
  return an error if the selected id is missing.
  - Track `remote_transport` separately from `exec_server_url` so
  stdio-command environments are still recognized as remote.
  - Add `Environment::remote_stdio_shell_command(...)` for the TOML
  provider added in the next PR.
  
  ## Stack
  
  - 1. https://github.com/openai/codex/pull/20663 - Add stdio exec-server
  listener
  - 2. https://github.com/openai/codex/pull/20664 - Add stdio exec-server
  client transport
  - **3. This PR:** https://github.com/openai/codex/pull/20665 - Make
  environment providers own default selection
  - 4. https://github.com/openai/codex/pull/20666 - Add CODEX_HOME
  environments TOML provider
  - 5. https://github.com/openai/codex/pull/20667 - Load configured
  environments from CODEX_HOME
  
  Split from original draft: https://github.com/openai/codex/pull/20508
  
  ## Validation
  
  Not run locally; this was split out of the original draft stack.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-05-08 01:00:31 +00:00
  9669756b5f
• [codex] Remove remote thread store implementation (#21596)

  Remove the remote thread-store backend and checked-in protobuf
  artifacts. We've moved these into another crate that link against this
  one.
  
  Also remove the config settings for thread store backend selection,
  since we'll instead pass an instantiated thread store into the core-api
  crate's main entrypoint.

  Tom · 2026-05-08 00:02:46 +00:00
  79ad209ce6
• Add stdio exec-server client transport (#20664)

  ## Why
  
  Configured environments need to connect to exec-server instances that
  are not necessarily already listening on a websocket URL. A
  command-backed stdio transport lets Codex start an exec-server process,
  speak JSON-RPC over its stdio streams, and clean up that child process
  with the client lifetime.
  
  **Stack position:** this is PR 2 of 5. It builds on the server-side
  stdio listener from PR 1 and provides the client transport used by later
  environment/config PRs.
  
  ## What Changed
  
  - Add `ExecServerTransport` variants for websocket URLs and stdio shell
  commands.
  - Add stdio command connection support for `ExecServerClient`.
  - Move websocket/stdio transport setup into `client_transport.rs` so
  `client.rs` stays focused on shared JSON-RPC client, session, HTTP, and
  notification behavior.
  - Tie stdio child process cleanup to the JSON-RPC connection lifetime
  with a RAII lifetime guard.
  - Keep existing websocket environment behavior by adapting URL-backed
  remotes to `ExecServerTransport::WebSocketUrl`.
  
  ## Stack
  
  - 1. https://github.com/openai/codex/pull/20663 - Add stdio exec-server
  listener
  - **2. This PR:** https://github.com/openai/codex/pull/20664 - Add stdio
  exec-server client transport
  - 3. https://github.com/openai/codex/pull/20665 - Make environment
  providers own default selection
  - 4. https://github.com/openai/codex/pull/20666 - Add CODEX_HOME
  environments TOML provider
  - 5. https://github.com/openai/codex/pull/20667 - Load configured
  environments from CODEX_HOME
  
  Split from original draft: https://github.com/openai/codex/pull/20508
  
  ## Validation
  
  Not run locally; this was split out of the original draft stack and then
  refactored to separate transport setup from the base client.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-05-07 23:48:50 +00:00
  a3de5bde6e
• Use --locked in cargo build and lint invocations (#21602)

  This ensures CI fails if the committed lockfile is outdated

  Zanie Blue · 2026-05-07 23:14:18 +00:00
  79154e6952
• [codex] Apply a Dependabot cooldown of 7 days (#21599)

  This adds 7-day cooldowns to all of our Dependabot ecosystem blocks. Our
  Dependabot runs will continue at the same cadence as before, but the
  scheduled PRs will no suggest updates that are fewer than 7 days old
  themselves. This serves two purposes: to let dependencies "bake" for a
  bit in terms of stability before we adopt them, and to give third-party
  security services/tooling a chance to detect and revoke malware.
  
  This should have no functional changes/consequences besides how rapidly
  we get (non-security) updates. Dependabot security PRs can still be
  scheduled and will bypass the cooldown.

  William Woodruff · 2026-05-07 16:07:46 -07:00
  893038f77c
• codex-otel: add configurable trace metadata (#21556)

  Add Codex config for static trace span attributes and structured W3C
  tracestate field upserts. The config flows through OtelSettings so
  callers can attach trace metadata without touching every span call site.
  
  Apply span attributes with an SDK span processor so every exported
  trace span carries the configured metadata. Model tracestate as nested
  member fields so configured keys can be upserted while unrelated
  propagated state in the same member is preserved.
  
  Validate configured tracestate before installing provider-global state,
  including header-unsafe values the SDK does not reject by itself. This
  keeps Codex from propagating malformed trace context from config.
  
  Update the config schema, public docs, and OTLP loopback coverage for
  config parsing, span export, propagation, and invalid-header rejection.

  bbrown-oai · 2026-05-07 16:06:57 -07:00
  31b233c7c6
• feat(app-server, threadstore): Thread pagination APIs and ThreadStore contract (#21566)

  ## Why
  The goal of this PR is to align on app-server and `ThreadStore` API
  updates for paginating through large threads.
  
  
  #### app-server
  ##### `thread/turns/list`
  - Updates `thread/turns/list` to support `itemsView?: "notLoaded" |
  "summary" | "full" | null`, defaulting to `summary`.
  - Implements the current `thread/turns/list` behavior over the existing
  persisted rollout-history fallback:
    - `notLoaded` returns turn envelopes with empty `items`.
  - `summary` returns the first user message and final assistant message
  when available.
    - `full` preserves the existing full item behavior.
  
  Note that this method still uses the naive approach of loading the
  entire rollout file, and returns just the filtered slice of the data.
  Real pagination will come later by leveraging SQLite.
  
  ##### `thread/turns/items/list`
  - Adds the experimental `thread/turns/items/list` protocol, schema,
  dispatcher, and processor stub. The app-server currently returns
  JSON-RPC `-32601` with `thread/turns/items/list is not supported yet`.
  
  #### ThreadStore
  - Adds the experimental `thread/turns/items/list` protocol, schema,
  dispatcher, and processor stub. The app-server currently returns
  JSON-RPC `-32601` with `thread/turns/items/list is not supported yet`.
  - Adds `ThreadStore` contract types and stubbed methods for listing
  thread turns and listing items within a turn.
  - Adds a typed `StoredTurnStatus` and `StoredTurnError` to avoid baking
  app-server API enums or lossy string status values into the store-facing
  turn contract.
  - Adds a typed `StoredTurnStatus` and `StoredTurnError` to avoid baking
  app-server API enums or lossy string status values into the store-facing
  turn contract.
  
  This also sketches the storage abstraction we expect to need once turns
  are indexed/stored. In particular, `notLoaded` is useful only if
  ThreadStore can eventually list turn metadata without loading every
  persisted item for each turn.
  
  ## Validation
  
  - Added/updated protocol serialization coverage for the new request and
  response shapes.
  - Added app-server integration coverage for `thread/turns/list` default
  summary behavior and all three `itemsView` modes.
  - Added app-server integration coverage that `thread/turns/items/list`
  returns the expected unsupported JSON-RPC error when experimental APIs
  are enabled.
  - Added thread-store coverage that the default trait methods return
  `ThreadStoreError::Unsupported`.
  
  No developers.openai.com documentation update is needed for this
  internal experimental app-server API surface.

  Owen Lin · 2026-05-07 15:44:43 -07:00
  0d0835dd53
• Disable empty Cargo test targets (#21584)

  ## Summary
  
  `cargo test` has entails both running standard Rust tests and doctests.
  It turns out that the doctest discovery is fairly slow, and it's a cost
  you pay even for crates that don't include any doctests.
  
  This PR disables doctests with `doctest = false` for crates that lack
  any doctests.
  
  For the collection of crates below, this speeds up test execution by
  >4x.
  
  E.g., before this PR:
  
  ```
  Benchmark 1: cargo test     -p codex-utils-absolute-path     -p codex-utils-cache     -p codex-utils-cli     -p codex-utils-home-dir     -p codex-utils-output-truncation     -p codex-utils-path     -p codex-utils-string     -p codex-utils-template     -p codex-utils-elapsed     -p codex-utils-json-to-toml
    Time (mean ± σ):      1.849 s ±  4.455 s    [User: 0.752 s, System: 1.367 s]
    Range (min … max):    0.418 s … 14.529 s    10 runs
  ```
  
  And after:
  
  ```
  Benchmark 1: cargo test     -p codex-utils-absolute-path     -p codex-utils-cache     -p codex-utils-cli     -p codex-utils-home-dir     -p codex-utils-output-truncation     -p codex-utils-path     -p codex-utils-string     -p codex-utils-template     -p codex-utils-elapsed     -p codex-utils-json-to-toml
    Time (mean ± σ):     428.6 ms ±   6.9 ms    [User: 187.7 ms, System: 219.7 ms]
    Range (min … max):   418.0 ms … 436.8 ms    10 runs
  ```
  
  For a single crate, with >2x speedup, before:
  
  ```
  Benchmark 1: cargo test -p codex-utils-string
    Time (mean ± σ):     491.1 ms ±   9.0 ms    [User: 229.8 ms, System: 234.9 ms]
    Range (min … max):   480.9 ms … 512.0 ms    10 runs
  ```
  
  And after:
  
  ```
  Benchmark 1: cargo test -p codex-utils-string
    Time (mean ± σ):     213.9 ms ±   4.3 ms    [User: 112.8 ms, System: 84.0 ms]
    Range (min … max):   206.8 ms … 221.0 ms    13 runs
  ```
  
  Co-authored-by: Codex <noreply@openai.com>

  Charlie Marsh · 2026-05-07 15:44:17 -07:00
  54ef99a365