4 Commits

• register all mcp tools with namespace (#17404)

  stacked on #17402.
  
  MCP tools returned by `tool_search` (deferred tools) get registered in
  our `ToolRegistry` with a different format than directly available
  tools. this leads to two different ways of accessing MCP tools from our
  tool catalog, only one of which works for each. fix this by registering
  all MCP tools with the namespace format, since this info is already
  available.
  
  also, direct MCP tools are registered to responsesapi without a
  namespace, while deferred MCP tools have a namespace. this means we can
  receive MCP `FunctionCall`s in both formats from namespaces. fix this by
  always registering MCP tools with namespace, regardless of deferral
  status.
  
  make code mode track `ToolName` provenance of tools so it can map the
  literal JS function name string to the correct `ToolName` for
  invocation, rather than supporting both in core.
  
  this lets us unify to a single canonical `ToolName` representation for
  each MCP tool and force everywhere to use that one, without supporting
  fallbacks.

  sayan-oai · 2026-04-15 21:02:59 +08:00
  0df7e9a820
• Support anyOf and enum in JsonSchema (#16875)

  This brings us into better alignment with the JSON schema subset that is
  supported in
  <https://developers.openai.com/api/docs/guides/structured-outputs#supported-schemas>,
  and also allows us to render richer function signatures in code mode
  (e.g., anyOf{null, OtherObjectType})

  Vivian Fang · 2026-04-08 01:07:55 -07:00
  ea516f9a40
• 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