caee620a53
## 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::`
2.5 KiB
codex-tools
codex-tools is intended to become the home for tool-related code that is
shared across multiple crates and does not need to stay coupled to
codex-core.
Today this crate is intentionally small. It currently owns the shared tool
schema primitives that no longer need to live in core/src/tools/spec.rs:
JsonSchemaAdditionalPropertiesToolDefinitionparse_tool_input_schema()parse_dynamic_tool()parse_mcp_tool()mcp_call_tool_result_output_schema()
That extraction is the first step in a longer migration. The goal is not to
move all of core/src/tools into this crate in one shot. Instead, the plan is
to peel off reusable pieces in reviewable increments while keeping
compatibility-sensitive orchestration in codex-core until the surrounding
boundaries are ready.
Vision
Over time, this crate should hold tool-facing primitives that are shared by multiple consumers, for example:
- schema and spec data models
- tool input/output parsing helpers
- tool metadata and compatibility shims that do not depend on
codex-core - other narrowly scoped utility code that multiple crates need
The corresponding non-goals are just as important:
- do not move
codex-coreorchestration here prematurely - do not pull
Session/TurnContext/ approval flow / runtime execution logic into this crate unless those dependencies have first been split into stable shared interfaces - do not turn this crate into a grab-bag for unrelated helper code
Migration approach
The expected migration shape is:
- Move low-coupling tool primitives here.
- Switch non-core consumers to depend on
codex-toolsdirectly. - Leave compatibility-sensitive adapters in
codex-corewhile downstream call sites are updated. - Only extract higher-level tool infrastructure after the crate boundaries are clear and independently testable.
That means it is normal for codex-core to temporarily re-export types or
helpers from codex-tools during the transition.
Crate conventions
This crate should start with stricter structure than core/src/tools so it
stays easy to grow:
src/lib.rsshould remain exports-only.- Business logic should live in named module files such as
foo.rs. - Unit tests for
foo.rsshould live in a siblingfoo_tests.rs. - The implementation file should wire tests with:
#[cfg(test)]
#[path = "foo_tests.rs"]
mod tests;
If this crate starts accumulating code that needs runtime state from
codex-core, that is a sign to revisit the extraction boundary before adding
more here.