8 Commits

• [code mode] defer mcp tools from exec description (#17287)

  ## Summary
  - hide deferred MCP/app nested tool descriptions from the `exec` prompt
  in code mode
  - add short guidance that omitted nested tools are still available
  through `ALL_TOOLS`
  - cover the code_mode_only path with an integration test that discovers
  and calls a deferred app tool
  
  ## Motivation
  `code_mode_only` exposes only top-level `exec`/`wait`, but the `exec`
  description could still include a large nested-tool reference. This
  keeps deferred nested tools callable while avoiding that prompt bloat.
  
  ## Tests
  - `just fmt`
  - `just fix -p codex-code-mode`
  - `just fix -p codex-tools`
  - `cargo test -p codex-code-mode
  exec_description_mentions_deferred_nested_tools_when_available`
  - `cargo test -p codex-tools
  create_code_mode_tool_matches_expected_spec`
  - `cargo test -p codex-core
  code_mode_only_guides_all_tools_search_and_calls_deferred_app_tools`

  sayan-oai · 2026-04-17 00:01:14 +08:00
  9c6d038622
• 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
• Add output_schema to code mode render (#17210)

  This updates code-mode tool rendering so MCP tools can surface
  structured output types from their `outputSchema`.
  
  What changed:
  - Detect MCP tool-call result wrappers from the output schema shape
  instead of relying on tool-name parsing or provenance flags.
  - Render shared TypeScript aliases once for MCP tool results
  (`CallToolResult`, `ContentBlock`, etc.) so multiple MCP tool
  declarations stay compact.
  - Type `structuredContent` from the tool definition's `outputSchema`
  instead of rendering it as `unknown`.
  - Update the shared MCP aliases to match the MCP draft `CallToolResult`
  schema more closely.
  
  Example:
  - Before: `declare const tools: { mcp__rmcp__echo(args: { env_var?:
  string; message: string; }): Promise<{ _meta?: unknown; content:
  Array<unknown>; isError?: boolean; structuredContent?: unknown; }>; };`
  - After: `declare const tools: { mcp__rmcp__echo(args: { env_var?:
  string; message: string; }): Promise<CallToolResult<{ echo: string; env:
  string | null; }>>; };`

  Vivian Fang · 2026-04-10 11:41:44 +00:00
  7bbe3b6011
• Render namespace description for tools (#16879)
  Vivian Fang · 2026-04-08 02:39:40 -07:00
  d47b755aa2
• 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
• 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
• 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 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