mirror of https://github.com/openai/codex.git synced 2026-04-27 16:15:09 +00:00

Files

Michael Bolin 4e119a3b38 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

2026-03-28 16:33:58 -07:00

3.2 KiB

Raw Blame History

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 and Responses API tool primitives that no longer need to live in core/src/tools/spec.rs or core/src/client_common.rs:

JsonSchema
AdditionalProperties
ToolDefinition
ToolSpec
ConfiguredToolSpec
ResponsesApiTool
FreeformTool
FreeformToolFormat
ToolSearchOutputTool
ResponsesApiWebSearchFilters
ResponsesApiWebSearchUserLocation
ResponsesApiNamespace
ResponsesApiNamespaceTool
code-mode ToolSpec adapters
local host tool spec builders for shell/exec/request-permissions/view-image
parse_tool_input_schema()
parse_dynamic_tool()
parse_mcp_tool()
create_tools_json_for_responses_api()
mcp_call_tool_result_output_schema()
tool_definition_to_responses_api_tool()
dynamic_tool_to_responses_api_tool()
mcp_tool_to_responses_api_tool()
mcp_tool_to_deferred_responses_api_tool()
augment_tool_spec_for_code_mode()
tool_spec_to_code_mode_tool_definition()

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-core orchestration 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-tools directly.
Leave compatibility-sensitive adapters in codex-core while 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.rs should remain exports-only.
Business logic should live in named module files such as foo.rs.
Unit tests for foo.rs should live in a sibling foo_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.

3.2 KiB Raw Blame History

codex-tools

Vision

Migration approach

Crate conventions

3.2 KiB

Raw Blame History