2514 Commits

• fix(core) rm execute_exec_request sandbox_policy (#16422)

  ## Summary
  In #11871 we started consolidating on ExecRequest.sandbox_policy instead
  of passing in a separate policy object that theoretically could differ
  (but did not). This finishes the some parameter cleanup.
  
  This should be a simple noop, since all 3 callsites of this function
  already used a cloned object from the ExecRequest value.
  
  ## Testing
  - [x] Existing tests pass

  Dylan Hurd · 2026-04-01 11:03:48 -04:00
  d3b99ef110
• nit: deny field v2 (#16427)
  jif-oai · 2026-04-01 12:26:40 +02:00
  5bbfee69b6
• feat: tasks can't be assigned to root agent (#16424)
  jif-oai · 2026-04-01 12:18:50 +02:00
  0c776c433b
• Use message string in v2 assign_task (#16419)

  Fix assign task and clean everything
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-04-01 11:40:19 +02:00
  3152d1a557
• Use message string in v2 send_message (#16409)

  ## Summary
  - switch MultiAgentV2 send_message to accept a single message string
  instead of items
  - keep the old assign_task item parser in place for the next branch
  - update send_message schema/spec and focused handler tests
  
  ## Verification
  - cargo test -p codex-tools
  send_message_tool_requires_message_and_uses_submission_output
  - cargo test -p codex-core multi_agent_v2_send_message
  - just fix -p codex-tools
  - just fix -p codex-core
  - just argument-comment-lint
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-04-01 11:26:22 +02:00
  23d638a573
• Use message string in v2 spawn_agent (#16406)

  ## Summary
  - switch MultiAgentV2 spawn_agent to accept a single message string
  instead of items
  - update v2 spawn tool schema and focused handler/spec tests
  
  ## Verification
  - cargo test -p codex-tools
  spawn_agent_tool_v2_requires_task_name_and_lists_visible_models
  - cargo test -p codex-core multi_agent_v2_spawn
  - just fix -p codex-tools
  - just fix -p codex-core
  - just argument-comment-lint
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-04-01 11:26:12 +02:00
  d0474f2bc1
• ci: sync Bazel clippy lints and fix uncovered violations (#16351)

  ## Why
  
  Follow-up to #16345, the Bazel clippy rollout in #15955, and the cleanup
  pass in #16353.
  
  `cargo clippy` was enforcing the workspace deny-list from
  `codex-rs/Cargo.toml` because the member crates opt into `[lints]
  workspace = true`, but Bazel clippy was only using `rules_rust` plus
  `clippy.toml`. That left the Bazel lane vulnerable to drift:
  `clippy.toml` can tune lint behavior, but it cannot set
  allow/warn/deny/forbid levels.
  
  This PR now closes both sides of the follow-up. It keeps `.bazelrc` in
  sync with `[workspace.lints.clippy]`, and it fixes the real clippy
  violations that the newly-synced Windows Bazel lane surfaced once that
  deny-list started matching Cargo.
  
  ## What Changed
  
  - added `.github/scripts/verify_bazel_clippy_lints.py`, a Python check
  that parses `codex-rs/Cargo.toml` with `tomllib`, reads the Bazel
  `build:clippy` `clippy_flag` entries from `.bazelrc`, and reports
  missing, extra, or mismatched lint levels
  - ran that verifier from the lightweight `ci.yml` workflow so the sync
  check does not depend on a Rust toolchain being installed first
  - expanded the `.bazelrc` comment to explain the Cargo `workspace =
  true` linkage and why Bazel needs the deny-list duplicated explicitly
  - fixed the Windows-only `codex-windows-sandbox` violations that Bazel
  clippy reported after the sync, using the same style as #16353: inline
  `format!` args, method references instead of trivial closures, removed
  redundant clones, and replaced SID conversion `unwrap` and `expect`
  calls with proper errors
  - cleaned up the remaining cross-platform violations the Bazel lane
  exposed in `codex-backend-client` and `core_test_support`
  
  ## Testing
  
  Key new test introduced by this PR:
  
  `python3 .github/scripts/verify_bazel_clippy_lints.py`

  Michael Bolin · 2026-03-31 17:09:48 -07:00
  2e942ce830
• Refactor chatwidget tests into topical modules (#16361)

  Problem: `chatwidget/tests.rs` had grown into a single oversized test
  blob that was hard to maintain and exceeded the repo's blob size limit.
  
  Solution: split the chatwidget tests into topical modules with a thin
  root `tests.rs`, shared helper utilities, preserved snapshot naming, and
  hermetic test config so the refactor stays stable and passes the
  `codex-tui` test suite.

  Eric Traut · 2026-03-31 16:45:58 -06:00
  424e532a6b
• ci: verify codex-rs Cargo manifests inherit workspace settings (#16353)

  ## Why
  
  Bazel clippy now catches lints that `cargo clippy` can still miss when a
  crate under `codex-rs` forgets to opt into workspace lints. The concrete
  example here was `codex-rs/app-server/tests/common/Cargo.toml`: Bazel
  flagged a clippy violation in `models_cache.rs`, but Cargo did not
  because that crate inherited workspace package metadata without
  declaring `[lints] workspace = true`.
  
  We already mirror the workspace clippy deny list into Bazel after
  [#15955](https://github.com/openai/codex/pull/15955), so we also need a
  repo-side check that keeps every `codex-rs` manifest opted into the same
  workspace settings.
  
  ## What changed
  
  - add `.github/scripts/verify_cargo_workspace_manifests.py`, which
  parses every `codex-rs/**/Cargo.toml` with `tomllib` and verifies:
    - `version.workspace = true`
    - `edition.workspace = true`
    - `license.workspace = true`
    - `[lints] workspace = true`
  - top-level crate names follow the `codex-*` / `codex-utils-*`
  conventions, with explicit exceptions for `windows-sandbox-rs` and
  `utils/path-utils`
  - run that script in `.github/workflows/ci.yml`
  - update the current outlier manifests so the check is enforceable
  immediately
  - fix the newly exposed clippy violations in the affected crates
  (`app-server/tests/common`, `file-search`, `feedback`,
  `shell-escalation`, and `debug-client`)
  
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/16353).
  * #16351
  * __->__ #16353

  Michael Bolin · 2026-03-31 21:59:28 +00:00
  9a8730f31e
• Fix Windows external bearer refresh test (#16366)

  ## Why
  
  https://github.com/openai/codex/pull/16287 introduced a change to
  `codex-rs/login/src/auth/auth_tests.rs` that uses a PowerShell helper to
  read the next token from `tokens.txt` and rewrite the remainder back to
  disk. On Windows, `Get-Content` can return a scalar when the file has
  only one remaining line, so `$lines[0]` reads the first character
  instead of the full token. That breaks the external bearer refresh test
  once the token list is nearly exhausted.
  
  https://github.com/openai/codex/pull/16288 introduced similar changes to
  `codex-rs/core/src/models_manager/manager_tests.rs` and
  `codex-rs/core/tests/suite/client.rs`.
  
  These went unnoticed because the failures showed up when the test was
  run via Cargo on Windows, but not in our Bazel harness. Figuring out
  that Cargo-vs-Bazel delta will happen in a follow-up PR.
  
  ## Verification
  
  On my Windows machine, I verified `cargo test` passes when run in
  `codex-rs/login` and `codex-rs/core`. Once this PR is merged, I will
  keep an eye on
  https://github.com/openai/codex/actions/workflows/rust-ci-full.yml to
  verify it goes green.
  
  ## What changed
  
  - Wrap `Get-Content -Path tokens.txt` in `@(...)` so the script always
  gets array semantics before counting, indexing, and rewriting the
  remaining lines.

  Michael Bolin · 2026-03-31 14:44:54 -07:00
  04ec9ef8af
• [codex-analytics] thread events (#15690)

  - add event for thread initialization
  - thread/start, thread/fork, thread/resume
  - feature flagged behind `FeatureFlag::GeneralAnalytics`
  - does not yet support threads started by subagents
  
  PR stack:
  - --> [[telemetry] thread events
  #15690](https://github.com/openai/codex/pull/15690)
  - [[telemetry] subagent events
  #15915](https://github.com/openai/codex/pull/15915)
  - [[telemetry] turn events
  #15591](https://github.com/openai/codex/pull/15591)
  - [[telemetry] steer events
  #15697](https://github.com/openai/codex/pull/15697)
  - [[telemetry] queued prompt data
  #15804](https://github.com/openai/codex/pull/15804)
  
  
  Sample extracted logs in Codex-backend
  ```
  INFO     | 2026-03-29 16:39:37 | codex_backend.routers.analytics_events | analytics_events.track_analytics_events:398 | Tracked analytics event codex_thread_initialized thread_id=019d3bf7-9f5f-7f82-9877-6d48d1052531 product_surface=codex product_client_id=CODEX_CLI client_name=codex-tui client_version=0.0.0 rpc_transport=in_process experimental_api_enabled=True codex_rs_version=0.0.0 runtime_os=macos runtime_os_version=26.4.0 runtime_arch=aarch64 model=gpt-5.3-codex ephemeral=False thread_source=user initialization_mode=new subagent_source=None parent_thread_id=None created_at=1774827577 | 
  INFO     | 2026-03-29 16:45:46 | codex_backend.routers.analytics_events | analytics_events.track_analytics_events:398 | Tracked analytics event codex_thread_initialized thread_id=019d3b84-5731-79d0-9b3b-9c6efe5f5066 product_surface=codex product_client_id=CODEX_CLI client_name=codex-tui client_version=0.0.0 rpc_transport=in_process experimental_api_enabled=True codex_rs_version=0.0.0 runtime_os=macos runtime_os_version=26.4.0 runtime_arch=aarch64 model=gpt-5.3-codex ephemeral=False thread_source=user initialization_mode=resumed subagent_source=None parent_thread_id=None created_at=1774820022 | 
  INFO     | 2026-03-29 16:45:49 | codex_backend.routers.analytics_events | analytics_events.track_analytics_events:398 | Tracked analytics event codex_thread_initialized thread_id=019d3bfd-4cd6-7c12-a13e-48cef02e8c4d product_surface=codex product_client_id=CODEX_CLI client_name=codex-tui client_version=0.0.0 rpc_transport=in_process experimental_api_enabled=True codex_rs_version=0.0.0 runtime_os=macos runtime_os_version=26.4.0 runtime_arch=aarch64 model=gpt-5.3-codex ephemeral=False thread_source=user initialization_mode=forked subagent_source=None parent_thread_id=None created_at=1774827949 | 
  INFO     | 2026-03-29 17:20:29 | codex_backend.routers.analytics_events | analytics_events.track_analytics_events:398 | Tracked analytics event codex_thread_initialized thread_id=019d3c1d-0412-7ed2-ad24-c9c0881a36b0 product_surface=codex product_client_id=CODEX_SERVICE_EXEC client_name=codex_exec client_version=0.0.0 rpc_transport=in_process experimental_api_enabled=True codex_rs_version=0.0.0 runtime_os=macos runtime_os_version=26.4.0 runtime_arch=aarch64 model=gpt-5.3-codex ephemeral=False thread_source=user initialization_mode=new subagent_source=None parent_thread_id=None created_at=1774830027 | 
  ```
  
  Notes
  - `product_client_id` gets canonicalized in codex-backend
  - subagent threads are addressed in a following pr

  rhan-oai · 2026-03-31 12:16:44 -07:00
  e8de4ea953
• fix: fix clippy issue caught by cargo but not bazel (#16345)

  I noticed that
  https://github.com/openai/codex/actions/workflows/rust-ci-full.yml
  started failing on my own PR,
  https://github.com/openai/codex/pull/16288, even though CI was green
  when I merged it.
  
  Apparently, it introduced a lint violation that was [correctly!] caught
  by our Cargo-based clippy runner, but not our Bazel-based one.
  
  My next step is to figure out the reason for the delta between the two
  setups, but I wanted to get us green again quickly, first.

  Michael Bolin · 2026-03-31 16:01:06 +00:00
  03b2465591
• chore: drop interrupt from send_message (#16324)
  jif-oai · 2026-03-31 16:02:45 +02:00
  b09b58ce2d
• feat: restrict spawn_agent v2 to messages (#16325)
  jif-oai · 2026-03-31 14:52:55 +02:00
  285f4ea817
• fix: update fork boundaries computation (#16322)
  jif-oai · 2026-03-31 14:10:43 +02:00
  4c72e62d0b
• feat: fork pattern v2 (#15771)

  Adds this:
  ```
  properties.insert(
              "fork_turns".to_string(),
              JsonSchema::String {
                  description: Some(
                      "Optional MultiAgentV2 fork mode. Use `none`, `all`, or a positive integer string such as `3` to fork only the most recent turns."
                          .to_string(),
                  ),
              },
          );
          ```
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-03-31 13:06:08 +02:00
  1fc8aa0e16
• nit: update aborted line (#16318)
  jif-oai · 2026-03-31 13:06:00 +02:00
  2b8d29ac0d
• chore: clean wait v2 (#16317)
  jif-oai · 2026-03-31 12:18:10 +02:00
  ec21e1fd01
• fix: ma2 (#16238)
  jif-oai · 2026-03-31 11:22:38 +02:00
  25fbd7e40e
• fix: one shot end of turn (#16308)

  Fix the death of the end of turn watcher

  jif-oai · 2026-03-31 11:11:33 +02:00
  873e466549
• core: support dynamic auth tokens for model providers (#16288)

  ## Summary
  
  Fixes #15189.
  
  Custom model providers that set `requires_openai_auth = false` could
  only use static credentials via `env_key` or
  `experimental_bearer_token`. That is not enough for providers that mint
  short-lived bearer tokens, because Codex had no way to run a command to
  obtain a bearer token, cache it briefly in memory, and retry with a
  refreshed token after a `401`.
  
  This PR adds that provider config and wires it through the existing auth
  design: request paths still go through `AuthManager.auth()` and
  `UnauthorizedRecovery`, with `core` only choosing when to use a
  provider-backed bearer-only `AuthManager`.
  
  ## Scope
  
  To keep this PR reviewable, `/models` only uses provider auth for the
  initial request in this change. It does **not** add a dedicated `401`
  retry path for `/models`; that can be follow-up work if we still need it
  after landing the main provider-token support.
  
  ## Example Usage
  
  ```toml
  model_provider = "corp-openai"
  
  [model_providers.corp-openai]
  name = "Corp OpenAI"
  base_url = "https://gateway.example.com/openai"
  requires_openai_auth = false
  
  [model_providers.corp-openai.auth]
  command = "gcloud"
  args = ["auth", "print-access-token"]
  timeout_ms = 5000
  refresh_interval_ms = 300000
  ```
  
  The command contract is intentionally small:
  
  - write the bearer token to `stdout`
  - exit `0`
  - any leading or trailing whitespace is trimmed before the token is used
  
  ## What Changed
  
  - add `model_providers.<id>.auth` to the config model and generated
  schema
  - validate that command-backed provider auth is mutually exclusive with
  `env_key`, `experimental_bearer_token`, and `requires_openai_auth`
  - build a bearer-only `AuthManager` for `ModelClient` and
  `ModelsManager` when a provider configures `auth`
  - let normal Responses requests and realtime websocket connects use the
  provider-backed bearer source through the same `AuthManager.auth()` path
  - allow `/models` online refresh for command-auth providers and attach
  the provider token to the initial `/models` request
  - keep `auth.cwd` available as an advanced escape hatch and include it
  in the generated config schema
  
  ## Testing
  
  - `cargo test -p codex-core provider_auth_command`
  - `cargo test -p codex-core
  refresh_available_models_uses_provider_auth_token`
  - `cargo test -p codex-core
  test_deserialize_provider_auth_config_defaults`
  
  ## Docs
  
  - `developers.openai.com/codex` should document the new
  `[model_providers.<id>.auth]` block and the token-command contract

  Michael Bolin · 2026-03-31 01:37:27 -07:00
  20f43c1e05
• fix: close Bazel argument-comment-lint CI gaps (#16253)

  ## Why
  
  The Bazel-backed `argument-comment-lint` CI path had two gaps:
  
  - Bazel wildcard target expansion skipped inline unit-test crates from
  `src/` modules because the generated `*-unit-tests-bin` `rust_test`
  targets are tagged `manual`.
  - `argument-comment-mismatch` was still only a warning in the Bazel and
  packaged-wrapper entrypoints, so a typoed `/*param_name*/` comment could
  still pass CI even when the lint detected it.
  
  That left CI blind to real linux-sandbox examples, including the missing
  `/*local_port*/` comment in
  `codex-rs/linux-sandbox/src/proxy_routing.rs` and typoed argument
  comments in `codex-rs/linux-sandbox/src/landlock.rs`.
  
  ## What Changed
  
  - Added `tools/argument-comment-lint/list-bazel-targets.sh` so Bazel
  lint runs cover `//codex-rs/...` plus the manual `rust_test`
  `*-unit-tests-bin` targets.
  - Updated `just argument-comment-lint`, `rust-ci.yml`, and
  `rust-ci-full.yml` to use that helper.
  - Promoted both `argument-comment-mismatch` and
  `uncommented-anonymous-literal-argument` to errors in every strict
  entrypoint:
    - `tools/argument-comment-lint/lint_aspect.bzl`
    - `tools/argument-comment-lint/src/bin/argument-comment-lint.rs`
    - `tools/argument-comment-lint/wrapper_common.py`
  - Added wrapper/bin coverage for the stricter lint flags and documented
  the behavior in `tools/argument-comment-lint/README.md`.
  - Fixed the now-covered callsites in
  `codex-rs/linux-sandbox/src/proxy_routing.rs`,
  `codex-rs/linux-sandbox/src/landlock.rs`, and
  `codex-rs/core/src/shell_snapshot_tests.rs`.
  
  This keeps the Bazel target expansion narrow while making the Bazel and
  prebuilt-linter paths enforce the same strict lint set.
  
  ## Verification
  
  - `python3 -m unittest discover -s tools/argument-comment-lint -p
  'test_*.py'`
  - `cargo +nightly-2025-09-18 test --manifest-path
  tools/argument-comment-lint/Cargo.toml`
  - `just argument-comment-lint`

  Michael Bolin · 2026-03-30 11:59:50 -07:00
  9313c49e4c
• codex-tools: extract discoverable tool models (#16254)

  ## Why
  
  `#16193` moved the pure `tool_search` and `tool_suggest` spec builders
  into `codex-tools`, but `codex-core` still owned the shared
  discoverable-tool model that those builders and the `tool_suggest`
  runtime both depend on. This change continues the migration by moving
  that reusable model boundary out of `codex-core` as well, so the
  discovery/suggestion stack uses one shared set of types and
  `core/src/tools` no longer needs its own `discoverable.rs` module.
  
  ## What changed
  
  - Moved `DiscoverableTool`, `DiscoverablePluginInfo`, and
  `filter_tool_suggest_discoverable_tools_for_client()` into
  `codex-rs/tools/src/tool_discovery.rs` alongside the extracted
  discovery/suggestion spec builders.
  - Added `codex-app-server-protocol` as a `codex-tools` dependency so the
  shared discoverable-tool model can own the connector-side `AppInfo`
  variant directly.
  - Updated `core/src/tools/handlers/tool_suggest.rs`,
  `core/src/tools/spec.rs`, `core/src/tools/router.rs`,
  `core/src/connectors.rs`, and `core/src/codex.rs` to consume the shared
  `codex-tools` model instead of the old core-local declarations.
  - Changed `core/src/plugins/discoverable.rs` to return
  `DiscoverablePluginInfo` directly, moved the pure client-filter coverage
  into `tool_discovery_tests.rs`, and deleted the old
  `core/src/tools/discoverable.rs` module.
  - Updated `codex-rs/tools/README.md` so the crate boundary documents
  that `codex-tools` now owns the discoverable-tool models in addition to
  the discovery/suggestion spec builders.
  
  ## Test plan
  
  - `cargo test -p codex-tools`
  - `CARGO_TARGET_DIR=/tmp/codex-core-discoverable-model cargo test -p
  codex-core --lib tools::handlers::tool_suggest::`
  - `CARGO_TARGET_DIR=/tmp/codex-core-discoverable-model cargo test -p
  codex-core --lib tools::spec::`
  - `CARGO_TARGET_DIR=/tmp/codex-core-discoverable-model cargo test -p
  codex-core --lib plugins::discoverable::`
  - `just bazel-lock-check`
  - `just argument-comment-lint`
  
  ## References
  
  - #16193
  - #16154
  - #15923
  - #15928
  - #15944
  - #15953
  - #16031
  - #16047
  - #16129
  - #16132
  - #16138
  - #16141

  Michael Bolin · 2026-03-30 10:48:49 -07:00
  258ba436f1
• codex-tools: extract discovery tool specs (#16193)

  ## Why
  
  `core/src/tools/spec.rs` still owned the pure `tool_search` and
  `tool_suggest` spec builders even though that logic no longer needed
  `codex-core` runtime state. This change continues the `codex-tools`
  migration by moving the reusable discovery and suggestion spec
  construction out of `codex-core` so `spec.rs` is left with the
  core-owned policy decisions about when these tools are exposed and what
  metadata is available.
  
  ## What changed
  
  - Added `codex-rs/tools/src/tool_discovery.rs` with the shared
  `tool_search` and `tool_suggest` spec builders, plus focused unit tests
  in `tool_discovery_tests.rs`.
  - Moved the shared `DiscoverableToolAction` and `DiscoverableToolType`
  declarations into `codex-tools` so the `tool_suggest` handler and the
  extracted spec builders use the same wire-model enums.
  - Updated `core/src/tools/spec.rs` to translate `ToolInfo` and
  `DiscoverableTool` values into neutral `codex-tools` inputs and delegate
  the actual spec building there.
  - Removed the old template-based description rendering helpers from
  `core/src/tools/spec.rs` and deleted the now-dead helper methods in
  `core/src/tools/discoverable.rs`.
  - Updated `codex-rs/tools/README.md` to document that discovery and
  suggestion models/spec builders now live in `codex-tools`.
  
  ## Test plan
  
  - `cargo test -p codex-tools`
  - `CARGO_TARGET_DIR=/tmp/codex-core-discovery-specs cargo test -p
  codex-core --lib tools::spec::`
  - `CARGO_TARGET_DIR=/tmp/codex-core-discovery-specs cargo test -p
  codex-core --lib tools::handlers::tool_suggest::`
  - `just argument-comment-lint`
  
  ## References
  
  - #16154
  - #15923
  - #15928
  - #15944
  - #15953
  - #16031
  - #16047
  - #16129
  - #16132
  - #16138
  - #16141

  Michael Bolin · 2026-03-30 08:15:12 -07:00
  716f7b0428
• fix: ma1 (#16237)
  jif-oai · 2026-03-30 15:42:17 +02:00
  c74190a622
• feat: add mailbox concept for wait (#16010)

  Add a mailbox we can use for inter-agent communication
  `wait` is now based on it and don't take target anymore

  jif-oai · 2026-03-30 11:47:20 +02:00
  213756c9ab
• codex-tools: extract utility tool specs (#16154)

  ## Why
  
  The previous `codex-tools` migration steps moved the shared schema
  models, local-host specs, collaboration specs, and related adapters out
  of `codex-core`, but `core/src/tools/spec.rs` still contained a grab bag
  of pure utility tool builders. Those specs do not need session state or
  handler logic; they only describe wire shapes for tools that
  `codex-core` already knows how to execute.
  
  Moving that remaining low-coupling layer into `codex-tools` keeps the
  migration moving in meaningful chunks and trims another large block of
  passive tool-spec construction out of `codex-core` without touching the
  runtime-coupled handlers.
  
  ## What changed
  
  - extended `codex-tools` to own the pure spec builders for:
    - code-mode `exec` / `wait`
    - `js_repl` / `js_repl_reset`
  - MCP resource tools `list_mcp_resources`,
  `list_mcp_resource_templates`, and `read_mcp_resource`
    - utility tools `list_dir` and `test_sync_tool`
  - split those builders across small module files with sibling
  `*_tests.rs` coverage, keeping `src/lib.rs` exports-only
  - rewired `core/src/tools/spec.rs` to call the extracted builders and
  deleted the duplicated core-local implementations
  - moved the direct JS REPL grammar seam test out of
  `core/src/tools/spec_tests.rs` so it now lives with the extracted
  implementation in `codex-tools`
  - updated `codex-rs/tools/README.md` so the documented crate boundary
  matches the new utility-spec surface
  
  ## Test plan
  
  - `CARGO_TARGET_DIR=/tmp/codex-tools-utility-specs cargo test -p
  codex-tools`
  - `CARGO_TARGET_DIR=/tmp/codex-core-utility-specs cargo test -p
  codex-core --lib tools::spec::`
  - `just fix -p codex-tools -p codex-core`
  - `just argument-comment-lint`
  
  ## References
  
  - #15923
  - #15928
  - #15944
  - #15953
  - #16031
  - #16047
  - #16129
  - #16132
  - #16138
  - #16141

  Michael Bolin · 2026-03-29 14:34:36 -07:00
  af568afdd5
• codex-tools: extract collaboration tool specs (#16141)

  ## Why
  
  The recent `codex-tools` migration steps have moved shared tool models
  and low-coupling spec helpers out of `codex-core`, but
  `core/src/tools/spec.rs` still owned a large block of pure
  collaboration-tool spec construction. Those builders do not need session
  state or runtime behavior; they only need a small amount of core-owned
  configuration injected at the seam.
  
  Moving that cohesive slice into `codex-tools` makes the crate boundary
  more honest and removes a substantial amount of passive tool-spec logic
  from `codex-core` without trying to move the runtime-coupled multi-agent
  handlers at the same time.
  
  ## What changed
  
  - added `agent_tool.rs`, `request_user_input_tool.rs`, and
  `agent_job_tool.rs` to `codex-tools`, with sibling `*_tests.rs` coverage
  and an exports-only `lib.rs`
  - moved the pure `ToolSpec` builders for:
  - collaboration tools such as `spawn_agent`, `send_input`,
  `send_message`, `assign_task`, `resume_agent`, `wait_agent`,
  `list_agents`, and `close_agent`
    - `request_user_input`
    - agent-job specs `spawn_agents_on_csv` and `report_agent_job_result`
  - rewired `core/src/tools/spec.rs` to call the extracted builders while
  still supplying the core-owned inputs, such as spawn-agent role
  descriptions and wait timeout bounds
  - updated the `core/src/tools/spec.rs` seam tests to build expected
  collaboration specs through `codex-tools`
  - updated `codex-rs/tools/README.md` so the crate documentation reflects
  the broader collaboration-tool boundary
  
  ## Test plan
  
  - `CARGO_TARGET_DIR=/tmp/codex-tools-collab-specs cargo test -p
  codex-tools`
  - `CARGO_TARGET_DIR=/tmp/codex-core-collab-specs cargo test -p
  codex-core --lib tools::spec::`
  - `just fix -p codex-tools -p codex-core`
  - `just argument-comment-lint`
  
  ## References
  
  - #15923
  - #15928
  - #15944
  - #15953
  - #16031
  - #16047
  - #16129
  - #16132
  - #16138

  Michael Bolin · 2026-03-28 20:39:47 -07:00
  7880414a27
• [mcp] Increase MCP startup timeout. (#16080)

  - [x] Increase MCP startup timeout to 30s, as the current 10s causes a
  lot of local MCPs to timeout.

  Matthew Zeng · 2026-03-28 19:58:00 -07:00
  3807807f91
• Remove TUI voice transcription feature (#16114)

  Removes the partially-completed TUI composer voice transcription flow,
  including its feature flag, app events, and hold-to-talk state machine.

  Eric Traut · 2026-03-29 00:20:25 +00:00
  3bbc1ce003
• codex-tools: extract local host tool specs (#16138)

  ## Why
  
  `core/src/tools/spec.rs` still bundled a set of pure local-host tool
  builders with the orchestration that actually decides when those tools
  are exposed and which handlers back them. That made `codex-core`
  responsible for JSON/tool-shape construction that does not depend on
  session state, and it kept the `codex-tools` migration from taking a
  meaningfully larger bite out of `spec.rs`.
  
  This PR moves that reusable spec-building layer into `codex-tools` while
  leaving feature gating, handler registration, and runtime-coupled
  descriptions in `codex-core`.
  
  ## What changed
  
  - added `codex-rs/tools/src/local_tool.rs` for the pure builders for
  `exec_command`, `write_stdin`, `shell`, `shell_command`, and
  `request_permissions`
  - added `codex-rs/tools/src/view_image.rs` for the `view_image` tool
  spec and output schema so the extracted modules stay right-sized
  - rewired `codex-rs/core/src/tools/spec.rs` to call those extracted
  builders instead of constructing these specs inline
  - kept the `request_permissions` description source in `codex-core`,
  with `codex-tools` taking the description as input so the crate boundary
  does not grow a dependency on handler/runtime code
  - moved the direct constructor coverage for this slice from
  `codex-rs/core/src/tools/spec_tests.rs` into
  `codex-rs/tools/src/local_tool_tests.rs` and
  `codex-rs/tools/src/view_image_tests.rs`
  - updated `codex-rs/tools/README.md` to reflect that `codex-tools` now
  owns this local-host spec layer
  
  ## Test plan
  
  - `CARGO_TARGET_DIR=/tmp/codex-tools-local-host cargo test -p
  codex-tools`
  - `CARGO_TARGET_DIR=/tmp/codex-core-local-tools cargo test -p codex-core
  --lib tools::spec::`
  - `just argument-comment-lint`
  
  ## References
  
  - #15923
  - #15928
  - #15944
  - #15953
  - #16031
  - #16047
  - #16129
  - #16132

  Michael Bolin · 2026-03-28 16:33:58 -07:00
  4e119a3b38
• codex-tools: extract code mode tool spec adapters (#16132)

  ## Why
  
  The longer-term `codex-tools` migration is to move pure tool-definition
  and tool-spec plumbing out of `codex-core` while leaving session- and
  runtime-coupled orchestration behind.
  
  The remaining code-mode adapter layer in
  `core/src/tools/code_mode_description.rs` was a good next extraction
  seam because it only transformed `ToolSpec` values for code mode and
  already delegated the low-level description rendering to
  `codex-code-mode`.
  
  ## What Changed
  
  - added `codex-rs/tools/src/code_mode.rs` with
  `augment_tool_spec_for_code_mode()` and
  `tool_spec_to_code_mode_tool_definition()`
  - added focused unit coverage in `codex-rs/tools/src/code_mode_tests.rs`
  - rewired `core/src/tools/spec.rs` and `core/src/tools/code_mode/mod.rs`
  to use the extracted adapters from `codex-tools`
  - removed the old `core/src/tools/code_mode_description.rs` shim and its
  test file from `codex-core`
  - added the `codex-code-mode` dependency to `codex-tools`, updated
  `Cargo.lock`, and refreshed the `codex-tools` README to reflect the
  expanded boundary
  
  ## Test Plan
  
  - `cargo test -p codex-tools`
  - `CARGO_TARGET_DIR=/tmp/codex-core-code-mode-adapters cargo test -p
  codex-core --lib tools::spec::`
  - `CARGO_TARGET_DIR=/tmp/codex-core-code-mode-adapters cargo test -p
  codex-core --lib tools::code_mode::`
  - `just bazel-lock-update`
  - `just bazel-lock-check`
  - `just argument-comment-lint`
  
  ## References
  
  - #15923
  - #15928
  - #15944
  - #15953
  - #16031
  - #16047
  - #16129

  Michael Bolin · 2026-03-28 15:32:35 -07:00
  2238c16a91
• core: fix stale curated plugin cache refresh races (#16126)

  ## Why
  
  The `plugin/list` force-sync path can race app-server startup's curated
  plugin cache refresh.
  
  Startup was capturing the configured curated plugin IDs from the initial
  config snapshot. If `plugin/list` with `forceRemoteSync` removed curated
  plugin entries from `config.toml` while that background refresh was
  still in flight, the startup task could recreate cache directories for
  plugins that had just been uninstalled.
  
  That leaves the `plugin/list` response logically correct but the on-disk
  cache stale, which matches the flaky Ubuntu arm failure seen in
  `codex-app-server::all
  suite::v2::plugin_list::plugin_list_force_remote_sync_reconciles_curated_plugin_state`
  while validating [#16047](https://github.com/openai/codex/pull/16047).
  
  ## What
  
  - change `codex-rs/core/src/plugins/manager.rs` so startup curated-repo
  refresh rereads the current user `config.toml` before deciding which
  curated plugin cache entries to refresh
  - factor the configured-plugin parsing so the same logic can be reused
  from either the config layer stack or the persisted user config value
  - add a regression test that verifies curated plugin IDs are read from
  the latest user config state before cache refresh runs
  
  ## Testing
  
  - `cargo test -p codex-core
  configured_curated_plugin_ids_from_codex_home_reads_latest_user_config
  -- --nocapture`
  - `cargo test -p codex-app-server
  suite::v2::plugin_list::plugin_list_force_remote_sync_reconciles_curated_plugin_state
  -- --nocapture`
  - `just argument-comment-lint`

  Michael Bolin · 2026-03-28 15:00:39 -07:00
  c25c0d6e9e
• codex-tools: extract configured tool specs (#16129)

  ## Why
  
  This continues the `codex-tools` migration by moving another passive
  tool-spec layer out of `codex-core`.
  
  After `ToolSpec` moved into `codex-tools`, `codex-core` still owned
  `ConfiguredToolSpec` and `create_tools_json_for_responses_api()`. Both
  are data-model and serialization helpers rather than runtime
  orchestration, so keeping them in `core/src/tools/registry.rs` and
  `core/src/tools/spec.rs` left passive tool-definition code coupled to
  `codex-core` longer than necessary.
  
  ## What changed
  
  - moved `ConfiguredToolSpec` into `codex-rs/tools/src/tool_spec.rs`
  - moved `create_tools_json_for_responses_api()` into
  `codex-rs/tools/src/tool_spec.rs`
  - re-exported the new surface from `codex-rs/tools/src/lib.rs`, which
  remains exports-only
  - updated `core/src/client.rs`, `core/src/tools/registry.rs`, and
  `core/src/tools/router.rs` to consume the extracted types and serializer
  from `codex-tools`
  - moved the tool-list serialization test into
  `codex-rs/tools/src/tool_spec_tests.rs`
  - added focused unit coverage for `ConfiguredToolSpec::name()`
  - simplified `core/src/tools/spec_tests.rs` to use the extracted
  `ConfiguredToolSpec::name()` directly and removed the now-redundant
  local `tool_name()` helper
  - updated `codex-rs/tools/README.md` so the crate boundary reflects the
  newly extracted tool-spec wrapper and serialization helper
  
  ## Test plan
  
  - `cargo test -p codex-tools`
  - `CARGO_TARGET_DIR=/tmp/codex-core-configured-spec cargo test -p
  codex-core --lib tools::spec::`
  - `CARGO_TARGET_DIR=/tmp/codex-core-configured-spec cargo test -p
  codex-core --lib client::`
  - `just fix -p codex-tools -p codex-core`
  - `just argument-comment-lint`
  
  ## References
  
  - #15923
  - #15928
  - #15944
  - #15953
  - #16031
  - #16047

  Michael Bolin · 2026-03-28 14:24:14 -07:00
  4e27a87ec6
• codex-tools: extract tool spec models (#16047)

  ## Why
  
  This continues the `codex-tools` migration by moving another passive
  tool-definition layer out of `codex-core`.
  
  After `ResponsesApiTool` and the lower-level schema adapters moved into
  `codex-tools`, `core/src/client_common.rs` was still owning `ToolSpec`
  and the web-search request wire types even though they are serialized
  data models rather than runtime orchestration. Keeping those types in
  `codex-core` makes the crate boundary look smaller than it really is and
  leaves non-runtime tool-shape code coupled to core.
  
  ## What changed
  
  - moved `ToolSpec`, `ResponsesApiWebSearchFilters`, and
  `ResponsesApiWebSearchUserLocation` into
  `codex-rs/tools/src/tool_spec.rs`
  - added focused unit tests in `codex-rs/tools/src/tool_spec_tests.rs`
  for:
    - `ToolSpec::name()`
    - web-search config conversions
    - `ToolSpec` serialization for `web_search` and `tool_search`
  - kept `codex-rs/tools/src/lib.rs` exports-only by re-exporting the new
  module from `lib.rs`
  - reduced `core/src/client_common.rs` to a compatibility shim that
  re-exports the extracted tool-spec types for current core call sites
  - updated `core/src/tools/spec_tests.rs` to consume the extracted
  web-search types directly from `codex-tools`
  - updated `codex-rs/tools/README.md` so the crate contract reflects that
  `codex-tools` now owns the passive tool-spec request models in addition
  to the lower-level Responses API structs
  
  ## Test plan
  
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core --lib tools::spec::`
  - `cargo test -p codex-core --lib client_common::`
  - `just fix -p codex-tools -p codex-core`
  - `just argument-comment-lint`
  
  ## References
  
  - #15923
  - #15928
  - #15944
  - #15953
  - #16031

  Michael Bolin · 2026-03-28 13:37:00 -07:00
  bc53d42fd9
• Remove remaining custom prompt support (#16115)

  ## Summary
  - remove protocol and core support for discovering and listing custom
  prompts
  - simplify the TUI slash-command flow and command popup to built-in
  commands only
  - delete obsolete custom prompt tests, helpers, and docs references
  - clean up downstream event handling for the removed protocol events

  Eric Traut · 2026-03-28 13:49:37 -06:00
  48144a7fa4
• chore: clean up argument-comment lint and roll out all-target CI on macOS (#16054)

  ## Why
  
  `argument-comment-lint` was green in CI even though the repo still had
  many uncommented literal arguments. The main gap was target coverage:
  the repo wrapper did not force Cargo to inspect test-only call sites, so
  examples like the `latest_session_lookup_params(true, ...)` tests in
  `codex-rs/tui_app_server/src/lib.rs` never entered the blocking CI path.
  
  This change cleans up the existing backlog, makes the default repo lint
  path cover all Cargo targets, and starts rolling that stricter CI
  enforcement out on the platform where it is currently validated.
  
  ## What changed
  
  - mechanically fixed existing `argument-comment-lint` violations across
  the `codex-rs` workspace, including tests, examples, and benches
  - updated `tools/argument-comment-lint/run-prebuilt-linter.sh` and
  `tools/argument-comment-lint/run.sh` so non-`--fix` runs default to
  `--all-targets` unless the caller explicitly narrows the target set
  - fixed both wrappers so forwarded cargo arguments after `--` are
  preserved with a single separator
  - documented the new default behavior in
  `tools/argument-comment-lint/README.md`
  - updated `rust-ci` so the macOS lint lane keeps the plain wrapper
  invocation and therefore enforces `--all-targets`, while Linux and
  Windows temporarily pass `-- --lib --bins`
  
  That temporary CI split keeps the stricter all-targets check where it is
  already cleaned up, while leaving room to finish the remaining Linux-
  and Windows-specific target-gated cleanup before enabling
  `--all-targets` on those runners. The Linux and Windows failures on the
  intermediate revision were caused by the wrapper forwarding bug, not by
  additional lint findings in those lanes.
  
  ## Validation
  
  - `bash -n tools/argument-comment-lint/run.sh`
  - `bash -n tools/argument-comment-lint/run-prebuilt-linter.sh`
  - shell-level wrapper forwarding check for `-- --lib --bins`
  - shell-level wrapper forwarding check for `-- --tests`
  - `just argument-comment-lint`
  - `cargo test` in `tools/argument-comment-lint`
  - `cargo test -p codex-terminal-detection`
  
  ## Follow-up
  
  - Clean up remaining Linux-only target-gated callsites, then switch the
  Linux lint lane back to the plain wrapper invocation.
  - Clean up remaining Windows-only target-gated callsites, then switch
  the Windows lint lane back to the plain wrapper invocation.

  Michael Bolin · 2026-03-27 19:00:44 -07:00
  61dfe0b86c
• Remove the legacy TUI split (#15922)

  This is the part 1 of 2 PRs that will delete the `tui` /
  `tui_app_server` split. This part simply deletes the existing `tui`
  directory and marks the `tui_app_server` feature flag as removed. I left
  the `tui_app_server` feature flag in place for now so its presence
  doesn't result in an error. It is simply ignored.
  
  Part 2 will rename the `tui_app_server` directory `tui`. I did this as
  two parts to reduce visible code churn.

  Eric Traut · 2026-03-27 22:56:44 +00:00
  d65deec617
• don't include redundant write roots in apply_patch (#16030)

  apply_patch sometimes provides additional parent dir as a writable root
  when it is already writable. This is mostly a no-op on Mac/Linux but
  causes actual ACL churn on Windows that is best avoided. We are also
  seeing some actual failures with these ACLs in the wild, which I haven't
  fully tracked down, but it's safe/best to avoid doing it altogether.

  iceweasel-oai · 2026-03-27 15:41:51 -07:00
  307e427a9b
• [mcp] Bypass read-only tool checks. (#16044)

  - [x] Auto / unspecified approval mode: read-only tools now skip before
  guardian routing.
  - [x] Approve / always-allow mode: read-only tools still skip, now via
  the shared early return.
  - [x] Prompt mode: read-only tools no longer skip; they continue to
  approval.

  Matthew Zeng · 2026-03-27 15:22:04 -07:00
  5b71e5104f
• codex-tools: extract responses API tool models (#16031)

  ## Why
  
  The previous extraction steps moved shared tool-schema parsing into
  `codex-tools`, but `codex-core` still owned the generic Responses API
  tool models and the last adapter layer that turned parsed tool
  definitions into `ResponsesApiTool` values.
  
  That left `core/src/tools/spec.rs` and `core/src/client_common.rs`
  holding a chunk of tool-shaping code that does not need session state,
  runtime plumbing, or any other `codex-core`-specific dependency. As a
  result, `codex-tools` owned the parsed tool definition, but `codex-core`
  still owned the generic wire model that those definitions are converted
  into.
  
  This change moves that boundary one step further. `codex-tools` now owns
  the reusable Responses/tool wire structs and the shared conversion
  helpers for dynamic tools, MCP tools, and deferred MCP aliases.
  `codex-core` continues to own `ToolSpec` orchestration and the remaining
  web-search-specific request shapes.
  
  ## What changed
  
  - added `tools/src/responses_api.rs` to own `ResponsesApiTool`,
  `FreeformTool`, `ToolSearchOutputTool`, namespace output types, and the
  shared `ToolDefinition -> ResponsesApiTool` adapter helpers
  - added `tools/src/responses_api_tests.rs` for deferred-loading
  behavior, adapter coverage, and namespace serialization coverage
  - rewired `core/src/tools/spec.rs` to use the extracted dynamic/MCP
  adapter helpers instead of defining those conversions locally
  - rewired `core/src/tools/handlers/tool_search.rs` to use the extracted
  deferred MCP adapter and namespace output types directly
  - slimmed `core/src/client_common.rs` so it now keeps `ToolSpec` and the
  web-search-specific wire types, while reusing the extracted tool models
  from `codex-tools`
  - moved the extracted seam tests out of `core` and updated
  `codex-rs/tools/README.md` plus `tools/src/lib.rs` to reflect the
  expanded `codex-tools` boundary
  
  ## Test plan
  
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core --lib tools::spec::`
  - `cargo test -p codex-core --lib tools::handlers::tool_search::`
  - `just fix -p codex-tools -p codex-core`
  - `just argument-comment-lint`
  
  ## References
  
  - [#15923](https://github.com/openai/codex/pull/15923) `codex-tools:
  extract shared tool schema parsing`
  - [#15928](https://github.com/openai/codex/pull/15928) `codex-tools:
  extract MCP schema adapters`
  - [#15944](https://github.com/openai/codex/pull/15944) `codex-tools:
  extract dynamic tool adapters`
  - [#15953](https://github.com/openai/codex/pull/15953) `codex-tools:
  introduce named tool definitions`

  Michael Bolin · 2026-03-27 14:26:54 -07:00
  16d4ea9ca8
• Add usage-based business plan types (#15934)

  ## Summary
  - add `self_serve_business_usage_based` and `enterprise_cbp_usage_based`
  to the public/internal plan enums and regenerate the app-server + Python
  SDK artifacts
  - map both plans through JWT login and backend rate-limit payloads, then
  bucket them with the existing Team/Business entitlement behavior in
  cloud requirements, usage-limit copy, tooltips, and status display
  - keep the earlier display-label remap commit on this branch so the new
  Team-like and Business-like plans render consistently in the UI
  
  ## Testing
  - `just write-app-server-schema`
  - `uv run --project sdk/python python
  sdk/python/scripts/update_sdk_artifacts.py generate-types`
  - `just fix -p codex-protocol -p codex-login -p codex-core -p
  codex-backend-client -p codex-cloud-requirements -p codex-tui -p
  codex-tui-app-server -p codex-backend-openapi-models`
  - `just fmt`
  - `just argument-comment-lint`
  - `cargo test -p codex-protocol
  usage_based_plan_types_use_expected_wire_names`
  - `cargo test -p codex-login usage_based`
  - `cargo test -p codex-backend-client usage_based`
  - `cargo test -p codex-cloud-requirements usage_based`
  - `cargo test -p codex-core usage_limit_reached_error_formats_`
  - `cargo test -p codex-tui plan_type_display_name_remaps_display_labels`
  - `cargo test -p codex-tui remapped`
  - `cargo test -p codex-tui-app-server
  plan_type_display_name_remaps_display_labels`
  - `cargo test -p codex-tui-app-server remapped`
  - `cargo test -p codex-tui-app-server
  preserves_usage_based_plan_type_wire_name`
  
  ## Notes
  - a broader multi-crate `cargo test` run still hits unrelated existing
  guardian-approval config failures in
  `codex-rs/core/src/config/config_tests.rs`

  bwanner-oai · 2026-03-27 14:25:13 -07:00
  82e8031338
• plugins: Clean up stale curated plugin sync temp dirs and add sync metrics (#16035)

  1. Keep curated plugin staging directories under TempDir ownership until
  activation succeeds, so failed git/HTTP sync attempts do not leak
  plugins-clone-*.
  2. Best-effort clean up stale plugins-clone-* directories before
  creating a new staged repo, using a conservative age threshold.
  3. Emit OTEL counters for curated plugin startup sync transport attempts
  and final outcome across git and HTTP paths.

  xl-openai · 2026-03-27 14:21:18 -07:00
  81abb44f68
• Normalize /mcp tool grouping for hyphenated server names (#15946)

  Fix display for servers with special characters.

  pakrym-oai · 2026-03-27 14:58:29 -06:00
  8002594ee3
• fix: fix Windows CI regression introduced in #15999 (#16027)

  #15999 introduced a Windows-only `\r\n` mismatch in review-exit template
  handling. This PR normalizes those template newlines and separates that
  fix from [#16014](https://github.com/openai/codex/pull/16014) so it can
  be reviewed independently.

  Michael Bolin · 2026-03-27 12:06:07 -07:00
  15fbf9d4f5
• codex-tools: introduce named tool definitions (#15953)

  ## Why
  
  This continues the `codex-tools` migration by moving one more piece of
  generic tool-definition bookkeeping out of `codex-core`.
  
  The earlier extraction steps moved shared schema parsing into
  `codex-tools`, but `core/src/tools/spec.rs` still had to supply tool
  names separately and perform ad hoc rewrites for deferred MCP aliases.
  That meant the crate boundary was still awkward: the parsed shape coming
  back from `codex-tools` was missing part of the definition that
  `codex-core` ultimately needs to assemble a `ResponsesApiTool`.
  
  This change introduces a named `ToolDefinition` in `codex-tools` so both
  MCP tools and dynamic tools cross the crate boundary in the same
  reusable model. `codex-core` still owns the final `ResponsesApiTool`
  assembly, but less of the generic tool-definition shaping logic stays
  behind in `core`.
  
  ## What changed
  
  - replaced `ParsedToolDefinition` with a named `ToolDefinition` in
  `codex-rs/tools/src/tool_definition.rs`
  - added `codex-rs/tools/src/tool_definition_tests.rs` for `renamed()`
  and `into_deferred()`
  - updated `parse_dynamic_tool()` and `parse_mcp_tool()` to return
  `ToolDefinition`
  - simplified `codex-rs/core/src/tools/spec.rs` so it adapts
  `ToolDefinition` into `ResponsesApiTool` instead of rewriting names and
  deferred fields inline
  - updated parser tests and `codex-rs/tools/README.md` to reflect the
  named tool-definition model
  
  ## Test plan
  
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core --lib tools::spec::`

  Michael Bolin · 2026-03-27 12:02:55 -07:00
  caee620a53
• codex-tools: extract dynamic tool adapters (#15944)

  ## Why
  
  `codex-tools` already owned the shared JSON schema parser and the MCP
  tool schema adapter, but `core/src/tools/spec.rs` still parsed dynamic
  tools directly.
  
  That left the tool-schema boundary split in two different ways:
  
  - MCP tools flowed through `codex-tools`, while dynamic tools were still
  parsed in `codex-core`
  - the extracted dynamic-tool path initially introduced a
  dynamic-specific parsed shape even though `codex-tools` already had very
  similar MCP adapter output
  
  This change finishes that extraction boundary in one step. `codex-core`
  still owns `ResponsesApiTool` assembly, but both MCP tools and dynamic
  tools now enter that layer through `codex-tools` using the same parsed
  tool-definition shape.
  
  ## What changed
  
  - added `tools/src/dynamic_tool.rs` and sibling
  `tools/src/dynamic_tool_tests.rs`
  - introduced `parse_dynamic_tool()` in `codex-tools` and switched
  `core/src/tools/spec.rs` to use it for dynamic tools
  - added `tools/src/parsed_tool_definition.rs` so both MCP and dynamic
  adapters return the same `ParsedToolDefinition`
  - updated `core/src/tools/spec.rs` to build `ResponsesApiTool` through a
  shared local adapter helper instead of separate MCP and dynamic assembly
  paths
  - expanded `core/src/tools/spec_tests.rs` so the dynamic-tool adapter
  test asserts the full converted `ResponsesApiTool`, including
  `defer_loading`
  - updated `codex-rs/tools/README.md` to reflect the shared parsed
  tool-definition boundary
  
  ## Test plan
  
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core --lib tools::spec::`
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/15944).
  * #15953
  * __->__ #15944

  Michael Bolin · 2026-03-27 09:12:36 -07:00
  617475e54b
• fix(sandbox): fix bwrap lookup for multi-entry PATH (#15973)

  ## Summary
  - split the joined `PATH` before running system `bwrap` lookup
  - keep the existing workspace-local `bwrap` skip behavior intact
  - add regression tests that exercise real multi-entry search paths
  
  ## Why
  The PATH-based lookup added in #15791 still wrapped the raw `PATH`
  environment value as a single `PathBuf` before passing it through
  `join_paths()`. On Unix, a normal multi-entry `PATH` contains `:`, so
  that wrapper path is invalid as one path element and the lookup returns
  `None`.
  
  That made Codex behave as if no system `bwrap` was installed even when
  `bwrap` was available on `PATH`, which is what users in #15340 were
  still hitting on `0.117.0-alpha.25`.
  
  ## Impact
  System `bwrap` discovery now works with normal multi-entry `PATH` values
  instead of silently falling back to the vendored binary.
  
  Fixes #15340.
  
  ## Validation
  - `just fmt`
  - `cargo test -p codex-sandboxing`
  - `cargo test -p codex-linux-sandbox`
  - `just fix -p codex-sandboxing`
  - `just argument-comment-lint`

  viyatb-oai · 2026-03-27 08:41:06 -07:00
  ec089fd22a
• feat: spawn v2 as inter agent communication (#15985)

  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-03-27 15:45:19 +01:00
  426f28ca99
• Use codex-utils-template for review exit XML (#15999)
  jif-oai · 2026-03-27 15:30:28 +01:00
  2b71717ccf