35 Commits

• chore: rename assign_task for followup_task (#16571)
  jif-oai · 2026-04-02 16:51:17 +02:00
  7fc36249b5
• 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
• 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
• 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
• 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
• 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
• 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
• chore: interrupted as state (#16426)
  jif-oai · 2026-04-01 12:26:29 +02:00
  609ac0c7ab
• nit: update wait v2 desc (#16425)
  jif-oai · 2026-04-01 12:26:25 +02:00
  df5f79da36
• 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
• 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
• 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
• 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
• 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
• 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