532 Commits

• Move tool registry plan tests into codex-tools (#16521)

  ## Why
  
  #16513 moved pure tool-registry planning into `codex-tools`, but much of
  the corresponding spec/feature-gating coverage still lived in
  `codex-core`. That leaves the tests for planner behavior in the crate
  that no longer owns that logic and makes the next extraction steps
  harder to review.
  
  ## What
  
  Move the planner-only `spec_tests.rs` coverage into
  `codex-rs/tools/src/tool_registry_plan_tests.rs` and wire it up from
  `codex-rs/tools/src/tool_registry_plan.rs` using the crate-local `#[path
  = "tool_registry_plan_tests.rs"] mod tests;` pattern.
  
  The `codex-core` test file now keeps the core-side integration checks:
  router-visible model tool lists, namespaced handler alias registration,
  shell adapter behavior, and MCP schema edge cases that still exercise
  the `core` binding layer.
  
  ## Verification
  
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core tools::spec::tests`

  Michael Bolin · 2026-04-02 00:26:51 -07:00
  5131e0de45
• Extract tool registry planning into codex-tools (#16513)

  ## Why
  This is a larger step in the `codex-core` -> `codex-tools` migration
  called out in `AGENTS.md`.
  
  `codex-rs/core/src/tools/spec.rs` had become mostly pure tool-spec
  assembly plus handler registration. That made it hard to move more of
  the tool-definition layer into `codex-tools`, because the runtime
  binding and the crate-independent planning logic were still interleaved
  in one function.
  
  Splitting those concerns gives `codex-tools` ownership of the
  declarative registry plan while keeping `codex-core` responsible for
  instantiating concrete handlers.
  
  ## What Changed
  - Add a `codex-tools` registry-plan layer in
  `codex-rs/tools/src/tool_registry_plan.rs` and
  `codex-rs/tools/src/tool_registry_plan_types.rs`.
  - Move feature-gated tool-spec assembly, MCP/dynamic tool conversion,
  tool-search aliases, and code-mode nested-plan expansion into
  `codex-tools`.
  - Keep `codex-rs/core/src/tools/spec.rs` as the core-side adapter that
  maps each planned handler kind to concrete runtime handler instances.
  - Update `spec_tests.rs` to import the moved `codex_tools` symbols
  directly instead of relying on top-level `spec.rs` re-exports.
  
  This is intended to be a straight refactor with no behavior change and
  no new test surface.
  
  ## Verification
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core tools::spec::tests`
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/16513).
  * #16521
  * __->__ #16513

  Michael Bolin · 2026-04-02 00:18:18 -07:00
  828b837235
• core: remove cross-crate re-exports from lib.rs (#16512)

  ## Why
  
  `codex-core` was re-exporting APIs owned by sibling `codex-*` crates,
  which made downstream crates depend on `codex-core` as a proxy module
  instead of the actual owner crate.
  
  Removing those forwards makes crate boundaries explicit and lets leaf
  crates drop unnecessary `codex-core` dependencies. In this PR, this
  reduces the dependency on `codex-core` to `codex-login` in the following
  files:
  
  ```
  codex-rs/backend-client/Cargo.toml
  codex-rs/mcp-server/tests/common/Cargo.toml
  ```
  
  ## What
  
  - Remove `codex-rs/core/src/lib.rs` re-exports for symbols owned by
  `codex-login`, `codex-mcp`, `codex-rollout`, `codex-analytics`,
  `codex-protocol`, `codex-shell-command`, `codex-sandboxing`,
  `codex-tools`, and `codex-utils-path`.
  - Delete the `default_client` forwarding shim in `codex-rs/core`.
  - Update in-crate and downstream callsites to import directly from the
  owning `codex-*` crate.
  - Add direct Cargo dependencies where callsites now target the owner
  crate, and remove `codex-core` from `codex-rs/backend-client`.

  Michael Bolin · 2026-04-01 23:06:24 -07:00
  aa2403e2eb
• Extract code-mode nested tool collection into codex-tools (#16509)

  ## Why
  This is another small step in the `codex-core` -> `codex-tools`
  migration described in `AGENTS.md`.
  
  `core/src/tools/spec.rs` and `core/src/tools/code_mode/mod.rs` were both
  hand-rolling the same pure transformation: convert visible `ToolSpec`s
  into code-mode nested tool definitions, then sort and deduplicate by
  tool name. That logic does not depend on core runtime state or handlers,
  so keeping it in `codex-core` makes `spec.rs` harder to peel out later
  than it needs to be.
  
  ## What Changed
  - Add `collect_code_mode_tool_definitions()` to
  `codex-rs/tools/src/code_mode.rs`.
  - Reuse that helper from `codex-rs/core/src/tools/spec.rs` when
  assembling the `exec` tool description.
  - Reuse the same helper from `codex-rs/core/src/tools/code_mode/mod.rs`
  when exposing nested tool metadata to the code-mode runtime.
  
  This is intended to be a straight refactor with no behavior change and
  no new test surface.
  
  ## Verification
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core tools::spec::tests`
  - `cargo test -p codex-core code_mode_only_`

  Michael Bolin · 2026-04-01 22:17:55 -07:00
  9f71d57a65
• core: use codex-mcp APIs directly (#16510)

  ## Why
  
  `codex-mcp` already owns the shared MCP API surface, including `auth`,
  `McpConfig`, `CODEX_APPS_MCP_SERVER_NAME`, and tool-name helpers in
  [`codex-rs/codex-mcp/src/mcp/mod.rs`](https://github.com/openai/codex/blob/f61e85dbfb5373cde6827d232ac8ea447c237e81/codex-rs/codex-mcp/src/mcp/mod.rs#L1-L35).
  Re-exporting that surface from `codex_core::mcp` gives downstream crates
  two import paths for the same API and hides the real crate dependency.
  
  This PR keeps `codex_core::mcp` focused on the local `McpManager`
  wrapper in
  [`codex-rs/core/src/mcp.rs`](https://github.com/openai/codex/blob/f61e85dbfb5373cde6827d232ac8ea447c237e81/codex-rs/core/src/mcp.rs#L13-L40)
  and makes consumers import shared MCP APIs from `codex_mcp` directly.
  
  ## What
  
  - Remove the `codex_mcp::mcp` re-export surface from `core/src/mcp.rs`.
  - Update `codex-core` internals plus `codex-app-server`, `codex-cli`,
  and `codex-tui` test code to import MCP APIs from `codex_mcp::mcp`
  directly.
  - Add explicit `codex-mcp` dependencies where those crates now use that
  API surface, and refresh `Cargo.lock`.
  
  ## Verification
  
  - `just bazel-lock-check`
  - `cargo test -p codex-core -p codex-cli -p codex-tui`
    - `codex-cli` passed.
  - `codex-core` still fails five unrelated config tests in
  `core/src/config/config_tests.rs` (`approvals_reviewer_*` and
  `smart_approvals_alias_*`).
  - A broader `cargo test -p codex-core -p codex-app-server -p codex-cli
  -p codex-tui` run previously hung in `codex-app-server` test
  `in_process_start_uses_requested_session_source_for_thread_start`.

  Michael Bolin · 2026-04-01 21:55:22 -07:00
  cc97982bbb
• Extract request_user_input normalization into codex-tools (#16503)

  ## Why
  This is another incremental step in the `codex-core` -> `codex-tools`
  migration called out in `AGENTS.md`: keep pure tool-definition and
  wire-shaping logic out of `codex-core` so the core crate can stay
  focused on runtime orchestration.
  
  `request_user_input` already had its spec and mode-availability helpers
  in `codex-tools` after #16471. The remaining argument validation and
  normalization still lived in the core runtime handler, which left that
  tool split across the two crates.
  
  ## What Changed
  - Export `REQUEST_USER_INPUT_TOOL_NAME` and
  `normalize_request_user_input_args()` from
  `codex-rs/tools/src/request_user_input_tool.rs`.
  - Use that `codex-tools` surface from `codex-rs/core/src/tools/spec.rs`
  and `codex-rs/core/src/tools/handlers/request_user_input.rs`.
  - Keep the core handler responsible for payload parsing, session
  dispatch, cancellation handling, and response serialization.
  
  This is intended to be a straight refactor with no behavior change.
  
  ## Verification
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core request_user_input`

  Michael Bolin · 2026-04-01 21:18:45 -07:00
  1b5a16f05e
• core: use codex-tools config types directly (#16504)

  ## Why
  
  `codex-rs/tools/src/lib.rs` already defines the [canonical `codex_tools`
  export
  surface](https://github.com/openai/codex/blob/bf081b9e286e620d25c1d61cf0f38f74a0f982ce/codex-rs/tools/src/lib.rs#L83-L88)
  for `ToolsConfig`, `ToolsConfigParams`, and the shell backend config
  types. Re-exporting those same types from `core/src/tools/spec.rs` gives
  `codex-core` two import paths for one API and blurs which crate owns
  those config definitions.
  
  This PR removes that duplicate path so `codex-core` callsites depend on
  `codex_tools` directly.
  
  ## What
  
  - Remove the five `codex_tools` re-exports from
  `core/src/tools/spec.rs`.
  - Update `codex-core` production and test callsites to import
  `ShellCommandBackendConfig`, `ToolsConfig`, `ToolsConfigParams`,
  `UnifiedExecShellMode`, and `ZshForkConfig` from `codex_tools`.
  
  ## Verification
  
  - Ran `cargo test -p codex-core`.
  - The package run is currently red in five unrelated config tests in
  `core/src/config/config_tests.rs` (`approvals_reviewer_*` and
  `smart_approvals_alias_*`), while the tool/spec and shell tests touched
  by this import cleanup passed.

  Michael Bolin · 2026-04-01 21:16:44 -07:00
  7c1c633f3f
• Extract tool-suggest wire helpers into codex-tools (#16499)

  ## Why
  
  This is another straight-refactor step in the `codex-tools` migration.
  
  `core/src/tools/handlers/tool_suggest.rs` still owned request/response
  payload structs, elicitation metadata shaping, and connector-completion
  predicates that do not depend on `codex-core` session/runtime internals.
  Per the `AGENTS.md` guidance to keep shrinking `codex-core`, this moves
  that pure wire-format logic into `codex-rs/tools` so the core handler
  keeps only session orchestration, plugin/config refresh, and MCP cache
  updates.
  
  ## What changed
  
  - Added `codex-rs/tools/src/tool_suggest.rs` and exported its API from
  `codex-rs/tools/src/lib.rs`.
  - Moved `ToolSuggestArgs`, `ToolSuggestResult`, `ToolSuggestMeta`,
  `build_tool_suggestion_elicitation_request()`,
  `all_suggested_connectors_picked_up()`, and
  `verified_connector_suggestion_completed()` into `codex-tools`.
  - Rewired `core/src/tools/handlers/tool_suggest.rs` to consume those
  exports directly.
  - Ported the existing pure helper tests from
  `core/src/tools/handlers/tool_suggest_tests.rs` to
  `tools/src/tool_suggest_tests.rs` without adding new behavior coverage.
  
  ## Validation
  
  ```shell
  cargo test -p codex-tools
  cargo test -p codex-core tools::handlers::tool_suggest::tests
  just argument-comment-lint
  ```

  Michael Bolin · 2026-04-01 20:49:15 -07:00
  d1068e057a
• Extract tool-search output helpers into codex-tools (#16497)

  ## Why
  
  This is the next straight-refactor step in the `codex-tools` migration
  that follows #16493.
  
  `codex-rs/core` still owned a chunk of pure tool-discovery metadata and
  response shaping even though the corresponding `tool_search` /
  `tool_suggest` specs already live in `codex-rs/tools`. Per the guidance
  in `AGENTS.md`, this moves that crate-agnostic logic out of `codex-core`
  so the handler crate keeps only the BM25 ranking/orchestration and
  runtime glue.
  
  ## What changed
  
  - Moved the canonical `tool_search` / `tool_suggest` tool names and the
  `tool_search` default limit into `codex-rs/tools/src/tool_discovery.rs`.
  - Added `ToolSearchResultSource` and
  `collect_tool_search_output_tools()` in `codex-tools` so namespace
  grouping and deferred Responses API tool serialization happen outside
  `codex-core`.
  - Rewired `ToolSearchHandler`, `ToolSuggestHandler`, and
  `core/src/tools/spec.rs` to consume those exports directly from
  `codex-tools`.
  - Ported the existing `tool_search` serializer tests from
  `core/src/tools/handlers/tool_search_tests.rs` to
  `tools/src/tool_discovery_tests.rs` without adding new behavior
  coverage.
  
  ## Validation
  
  ```shell
  cargo test -p codex-tools
  cargo test -p codex-core tools::spec::tests
  just argument-comment-lint
  ```

  Michael Bolin · 2026-04-01 20:16:21 -07:00
  0b856a4757
• Extract built-in tool spec constructors into codex-tools (#16493)

  ## Why
  
  `core/src/tools/spec.rs` still had a few built-in tool specs assembled
  inline even though those definitions are pure metadata and already live
  conceptually in `codex-tools`. Keeping that construction in `codex-core`
  makes `spec.rs` do more than registry orchestration and slows the
  migration toward a right-sized `codex-tools` crate.
  
  This continues the extraction stack from #16379, #16471, #16477, #16481,
  and #16482.
  
  ## What Changed
  
  - added `create_local_shell_tool()`, `create_web_search_tool(...)`, and
  `create_image_generation_tool(...)` to `codex-rs/tools/src/tool_spec.rs`
  - exported those helpers from `codex-rs/tools/src/lib.rs`
  - switched `codex-rs/core/src/tools/spec.rs` to call those helpers
  instead of constructing `ToolSpec::LocalShell`, `ToolSpec::WebSearch`,
  and `ToolSpec::ImageGeneration` inline
  - removed the remaining core-local web-search content-type constant and
  made the affected spec test assert the literal expected values directly
  
  This is intended to be a straight refactor: tool behavior and wire shape
  should not change.
  
  ## Testing
  
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core tools::spec::tests`

  Michael Bolin · 2026-04-01 19:31:24 -07:00
  5a2f3a8102
• Remove client_common tool re-exports (#16482)

  ## Why
  
  `codex-rs/core/src/client_common.rs` still had a `tools` re-export
  module that forwarded `codex_tools` types back into `codex-core`. After
  the earlier extraction work in #16379, #16471, #16477, and #16481, that
  extra layer no longer adds value.
  
  Removing it keeps dependencies explicit: the `codex-core` modules that
  actually use `ToolSpec` and related types now depend on `codex_tools`
  directly instead of reaching through `client_common`.
  
  ## What Changed
  
  - removed the `client_common::tools` re-export module from
  `core/src/client_common.rs`
  - updated the remaining `codex-core` consumers to import `codex_tools`
  directly
  - adjusted the affected test code to reference
  `codex_tools::ResponsesApiTool` directly as well
  
  This is a mechanical cleanup only. It does not change tool behavior or
  runtime logic.
  
  ## Testing
  
  - `cargo test -p codex-core client_common::tests`
  - `cargo test -p codex-core tools::router::tests`
  - `cargo test -p codex-core tools::context::tests`
  - `cargo test -p codex-core tools::spec::tests`

  Michael Bolin · 2026-04-01 19:15:15 -07:00
  d4464125c5
• Extract update_plan tool spec into codex-tools (#16481)

  ## Why
  
  `codex-rs/core/src/tools/handlers/plan.rs` still owned both the
  `update_plan` runtime handler and the static tool definition. The tool
  definition is pure metadata, so keeping it in `codex-core` works against
  the ongoing effort to move tool-spec code into `codex-tools` and keep
  `codex-core` focused on orchestration and execution paths.
  
  This continues the extraction work from #16379, #16471, and #16477.
  
  ## What Changed
  
  - added `codex-rs/tools/src/plan_tool.rs` with
  `create_update_plan_tool()`
  - re-exported that constructor from `codex-rs/tools/src/lib.rs`
  - updated `codex-rs/core/src/tools/spec.rs` and
  `codex-rs/core/src/tools/spec_tests.rs` to use the `codex-tools` export
  instead of a core-local static
  - removed the old `PLAN_TOOL` definition from
  `codex-rs/core/src/tools/handlers/plan.rs`; the `PlanHandler` runtime
  logic still stays in `codex-core`
  - tightened two `codex-core` aliases to `#[cfg(test)]` now that
  production code no longer needs them
  
  ## Testing
  
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core tools::spec::tests`
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/16481).
  * #16482
  * __->__ #16481

  Michael Bolin · 2026-04-01 15:51:52 -07:00
  6cf832fc63
• fix(guardian): make GuardianAssessmentEvent.action strongly typed (#16448)

  ## Description
  
  Previously the `action` field on `EventMsg::GuardianAssessment`, which
  describes what Guardian is reviewing, was typed as an arbitrary JSON
  blob. This PR cleans it up and defines a sum type representing all the
  various actions that Guardian can review.
  
  This is a breaking change (on purpose), which is fine because:
  - the Codex app / VSCE does not actually use `action` at the moment
  - the TUI code that consumes `action` is updated in this PR as well
  - rollout files that serialized old `EventMsg::GuardianAssessment` will
  just silently drop these guardian events
  - the contract is defined as unstable, so other clients have a fair
  warning :)
  
  This will make things much easier for followup Guardian work.
  
  ## Why
  
  The old guardian review payloads worked, but they pushed too much shape
  knowledge into downstream consumers. The TUI had custom JSON parsing
  logic for commands, patches, network requests, and MCP calls, and the
  app-server protocol was effectively just passing through an opaque blob.
  
  Typing this at the protocol boundary makes the contract clearer.

  Owen Lin · 2026-04-01 15:42:18 -07:00
  30f6786d62
• Extract tool discovery helpers into codex-tools (#16477)

  ## Why
  
  Follow-up to #16379 and #16471.
  
  `codex-rs/core/src/tools/spec.rs` still owned the pure discovery-shaping
  helpers that turn app metadata and discoverable tool metadata into the
  inputs used by `tool_search` and `tool_suggest`. Those helpers do not
  need `codex-core` runtime state, so keeping them in `codex-core`
  continued to blur the crate boundary this migration is trying to
  tighten.
  
  This change keeps pushing spec-only logic behind the `codex-tools` API
  so `codex-core` can focus on wiring runtime handlers to the resulting
  tool definitions.
  
  ## What Changed
  
  - Added `collect_tool_search_app_infos` and
  `collect_tool_suggest_entries` to
  `codex-rs/tools/src/tool_discovery.rs`.
  - Added a small `ToolSearchAppSource` adapter type in `codex-tools` so
  `codex-core` can pass app metadata into that shared helper logic without
  exposing `ToolInfo` across the crate boundary.
  - Re-exported the new discovery helpers from
  `codex-rs/tools/src/lib.rs`, which remains exports-only.
  - Updated `codex-rs/core/src/tools/spec.rs` to use those `codex-tools`
  helpers instead of maintaining local `tool_search_app_infos` and
  `tool_suggest_entries` functions.
  - Removed the now-redundant helper implementations from `codex-core`.
  
  ## Testing
  
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core tools::spec::tests`

  Michael Bolin · 2026-04-01 14:41:20 -07:00
  1b711a5501
• Extract tool spec helpers into codex-tools (#16471)

  ## Why
  
  Follow-up to #16379.
  
  `codex-rs/core/src/tools/spec.rs` and the corresponding handlers still
  owned several pure tool-definition helpers even though they do not need
  `codex-core` runtime state. Keeping that spec-only logic in `codex-core`
  keeps the crate boundary blurry and works against the guidance in
  `AGENTS.md` to keep shared tooling out of `codex-core` when possible.
  
  This change takes another step toward a dedicated `codex-tools` crate by
  moving more metadata and schema-building code behind the `codex-tools`
  API while leaving the actual tool execution paths in `codex-core`.
  
  ## What Changed
  
  - Added `codex-rs/tools/src/apply_patch_tool.rs` to own
  `ApplyPatchToolArgs`, the freeform/json `apply_patch` tool specs, and
  the moved `tool_apply_patch.lark` grammar.
  - Updated `codex-rs/tools/BUILD.bazel` so Bazel exposes the moved
  grammar file to `codex-tools`.
  - Moved the `request_user_input` availability and description helpers
  into `codex-rs/tools/src/request_user_input_tool.rs`, with the related
  unit tests moved alongside that business logic.
  - Moved `request_permissions_tool_description()` into
  `codex-rs/tools/src/local_tool.rs`.
  - Rewired `codex-rs/core/src/tools/spec.rs`,
  `codex-rs/core/src/tools/handlers/apply_patch.rs`, and
  `codex-rs/core/src/tools/handlers/request_user_input.rs` to consume the
  new `codex-tools` exports instead of local helper code.
  - Removed the now-redundant helper implementations and tests from
  `codex-core`, plus a couple of stale `client_common` re-exports that
  became unused after the move.
  
  ## Testing
  
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core tools::spec::tests`
  - `cargo test -p codex-core tools::handlers::apply_patch::tests`

  Michael Bolin · 2026-04-01 14:06:04 -07:00
  e6f5451a2c
• Extract tool config into codex-tools (#16379)

  ## Why
  
  `codex-core` already owns too much of the tool stack, and `AGENTS.md`
  explicitly pushes us to move shared code out of `codex-core` instead of
  letting it keep growing. This PR takes the next incremental step in
  moving `core/src/tools` toward `codex-rs/tools` by extracting
  low-coupling tool configuration and image-detail gating logic into
  `codex-tools`.
  
  That gives later extraction work a cleaner boundary to build on without
  trying to move the entire tools subtree in one shot.
  
  ## What changed
  
  - moved `ToolsConfig`, `ToolsConfigParams`, shell backend config, and
  unified-exec session selection from `core/src/tools/spec.rs` into
  `codex-tools`
  - moved original image-detail gating and normalization into
  `codex-tools`
  - updated `codex-core` to consume the new `codex-tools` exports and pass
  a rendered agent-type description instead of raw role config
  - kept `codex-rs/tools/src/lib.rs` exports-only, with extracted unit
  tests living in sibling `*_tests.rs` modules
  
  ## Testing
  
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core --lib tools::spec::`

  Michael Bolin · 2026-04-01 13:21:50 -07:00
  a99d4845e3
• 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
• 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
• 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
• chore: clean wait v2 (#16317)
  jif-oai · 2026-03-31 12:18:10 +02:00
  ec21e1fd01
• 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
• 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
• 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
• 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
• 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
• 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
• 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
• 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 search tool descriptions (#15996)
  jif-oai · 2026-03-27 15:08:24 +01:00
  f044ca64df
• feat: spawn v2 make task name as mandatory (#15986)
  jif-oai · 2026-03-27 11:30:22 +01:00
  6a0c4709ca
• codex-tools: extract MCP schema adapters (#15928)

  ## Why
  
  `codex-tools` already owns the shared tool input schema model and parser
  from the first extraction step, but `core/src/tools/spec.rs` still owned
  the MCP-specific adapter that normalizes `rmcp::model::Tool` schemas and
  wraps `structuredContent` into the call result output schema.
  
  Keeping that adapter in `codex-core` means the reusable MCP schema path
  is still split across crates, and the unit tests for that logic stay
  anchored in `codex-core` even though the runtime orchestration does not
  need to move yet.
  
  This change takes the next small step by moving the reusable MCP schema
  adapter into `codex-tools` while leaving `ResponsesApiTool` assembly in
  `codex-core`.
  
  ## What changed
  
  - added `tools/src/mcp_tool.rs` and sibling
  `tools/src/mcp_tool_tests.rs`
  - introduced `ParsedMcpTool`, `parse_mcp_tool()`, and
  `mcp_call_tool_result_output_schema()` in `codex-tools`
  - updated `core/src/tools/spec.rs` to consume parsed MCP tool parts from
  `codex-tools`
  - removed the now-redundant MCP schema unit tests from
  `core/src/tools/spec_tests.rs`
  - expanded `codex-rs/tools/README.md` to describe this second migration
  step
  
  ## Test plan
  
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core --lib tools::spec::`

  Michael Bolin · 2026-03-26 19:57:26 -07:00
  be5afc65d3
• permissions: remove macOS seatbelt extension profiles (#15918)

  ## Why
  
  `PermissionProfile` should only describe the per-command permissions we
  still want to grant dynamically. Keeping
  `MacOsSeatbeltProfileExtensions` in that surface forced extra macOS-only
  approval, protocol, schema, and TUI branches for a capability we no
  longer want to expose.
  
  ## What changed
  
  - Removed the macOS-specific permission-profile types from
  `codex-protocol`, the app-server v2 API, and the generated
  schema/TypeScript artifacts.
  - Deleted the core and sandboxing plumbing that threaded
  `MacOsSeatbeltProfileExtensions` through execution requests and seatbelt
  construction.
  - Simplified macOS seatbelt generation so it always includes the fixed
  read-only preferences allowlist instead of carrying a configurable
  profile extension.
  - Removed the macOS additional-permissions UI/docs/test coverage and
  deleted the obsolete macOS permission modules.
  - Tightened `request_permissions` intersection handling so explicitly
  empty requested read lists are preserved only when that field was
  actually granted, avoiding zero-grant responses being stored as active
  permissions.

  Michael Bolin · 2026-03-26 17:12:45 -07:00
  e6e2999209
• codex-tools: extract shared tool schema parsing (#15923)

  ## Why
  
  `parse_tool_input_schema` and the supporting `JsonSchema` model were
  living in `core/src/tools/spec.rs`, but they already serve callers
  outside `codex-core`.
  
  Keeping that shared schema parsing logic inside `codex-core` makes the
  crate boundary harder to reason about and works against the guidance in
  `AGENTS.md` to avoid growing `codex-core` when reusable code can live
  elsewhere.
  
  This change takes the first extraction step by moving the schema parsing
  primitive into its own crate while keeping the rest of the tool-spec
  assembly in `codex-core`.
  
  ## What changed
  
  - added a new `codex-tools` crate under `codex-rs/tools`
  - moved the shared tool input schema model and sanitizer/parser into
  `tools/src/json_schema.rs`
  - kept `tools/src/lib.rs` exports-only, with the module-level unit tests
  split into `json_schema_tests.rs`
  - updated `codex-core` to use `codex-tools::JsonSchema` and re-export
  `parse_tool_input_schema`
  - updated `codex-app-server` dynamic tool validation to depend on
  `codex-tools` directly instead of reaching through `codex-core`
  - wired the new crate into the Cargo workspace and Bazel build graph

  Michael Bolin · 2026-03-27 00:03:35 +00:00
  44d28f500f
• chore: remove skill metadata from command approval payloads (#15906)

  ## Why
  
  This is effectively a follow-up to
  [#15812](https://github.com/openai/codex/pull/15812). That change
  removed the special skill-script exec path, but `skill_metadata` was
  still being threaded through command-approval payloads even though the
  approval flow no longer uses it to render prompts or resolve decisions.
  
  Keeping it around added extra protocol, schema, and client surface area
  without changing behavior.
  
  Removing it keeps the command-approval contract smaller and avoids
  carrying a dead field through app-server, TUI, and MCP boundaries.
  
  ## What changed
  
  - removed `ExecApprovalRequestSkillMetadata` and the corresponding
  `skillMetadata` field from core approval events and the v2 app-server
  protocol
  - removed the generated JSON and TypeScript schema output for that field
  - updated app-server, MCP server, TUI, and TUI app-server approval
  plumbing to stop forwarding the field
  - cleaned up tests that previously constructed or asserted
  `skillMetadata`
  
  ## Testing
  
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-protocol`
  - `cargo test -p codex-app-server-test-client`
  - `cargo test -p codex-mcp-server`
  - `just argument-comment-lint`

  Michael Bolin · 2026-03-26 15:32:03 -07:00
  5906c6a658
• sandboxing: use OsString for SandboxCommand.program (#15897)

  ## Why
  
  `SandboxCommand.program` represents an executable path, but keeping it
  as `String` forced path-backed callers to run `to_string_lossy()` before
  the sandbox layer ever touched the command. That loses fidelity earlier
  than necessary and adds avoidable conversions in runtimes that already
  have a `PathBuf`.
  
  ## What changed
  
  - Changed `SandboxCommand.program` to `OsString`.
  - Updated `SandboxManager::transform` to keep the program and argv in
  `OsString` form until the `SandboxExecRequest` conversion boundary.
  - Switched the path-backed `apply_patch` and `js_repl` runtimes to pass
  `into_os_string()` instead of `to_string_lossy()`.
  - Updated the remaining string-backed builders and tests to match the
  new type while preserving the existing Linux helper `arg0` behavior.
  
  ## Verification
  
  - `cargo test -p codex-sandboxing`
  - `just argument-comment-lint -p codex-core -p codex-sandboxing`
  - `cargo test -p codex-core` currently fails in unrelated existing
  config tests: `config::tests::approvals_reviewer_*` and
  `config::tests::smart_approvals_alias_*`

  Michael Bolin · 2026-03-26 20:38:33 +00:00
  dfb36573cd