mirror of https://github.com/pchuan98/codex.git synced 2026-07-01 00:31:56 +08:00

Files

T

Michael Bolin e6f5451a2c 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`

e6f5451a2c · 2026-04-01 14:06:04 -07:00

History

src

Extract tool spec helpers into codex-tools (#16471 )

2026-04-01 14:06:04 -07:00

BUILD.bazel

Extract tool spec helpers into codex-tools (#16471 )

2026-04-01 14:06:04 -07:00

Cargo.toml

Extract tool config into codex-tools (#16379 )

2026-04-01 13:21:50 -07:00

README.md

codex-tools: extract discoverable tool models (#16254 )

2026-03-30 10:48:49 -07:00

README.md

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 and exec / wait spec builders
JS REPL spec builders
MCP resource, list_dir, and test_sync_tool spec builders
local host tool spec builders for shell/exec/request-permissions/view-image
collaboration and agent-job ToolSpec builders for spawn/send/wait/close, request_user_input, and CSV fanout/reporting
discoverable-tool models, client filtering, and ToolSpec builders for tool_search and tool_suggest
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.