Skip to content

[codex] Move tool specs onto handlers#21461

Open
pakrym-oai wants to merge 9 commits intomainfrom
pakrym/handler-owned-specs
Open

[codex] Move tool specs onto handlers#21461
pakrym-oai wants to merge 9 commits intomainfrom
pakrym/handler-owned-specs

Conversation

@pakrym-oai
Copy link
Copy Markdown
Collaborator

Why

This is the next stacked step after deleting the tool-handler kind indirection. Specs should come from the registered handlers themselves so registry construction has a single source of truth for handler behavior and exposed tool definitions.

What changed

  • Added ToolHandler::spec() plus handler-provided parallel/code-mode metadata, and made ToolRegistryBuilder::register_handler automatically collect specs from registered handlers.
  • Moved builtin tool spec construction into the corresponding handlers and their adjacent _spec modules, including shell, unified exec, apply patch, view image, request plugin install, tool search, MCP resource, goals, planning, permissions, agent jobs, and multi-agent tools.
  • Reworked configurable handlers to receive their tool-building options through constructors, with non-optional handler options where the handler is always spec-backed. Shell fallback handlers keep an explicit no-spec mode because they are also registered as hidden dispatch aliases.
  • Kept CodeModeExecuteHandler on the explicit configured wrapper so the code-mode exec spec can still be built from the nested registry.

Verification

  • cargo check -p codex-core
  • cargo test -p codex-core tools::spec_plan::tests
  • cargo test -p codex-core tools::spec::tests
  • cargo test -p codex-core tools::handlers::multi_agents_spec::tests
  • RUST_MIN_STACK=16777216 cargo test -p codex-core tools::handlers::multi_agents::tests
  • cargo test -p codex-core tools::handlers::apply_patch::tests
  • cargo test -p codex-core tools::handlers::unified_exec::tests
  • just fix -p codex-core
  • git diff --check

@pakrym-oai pakrym-oai marked this pull request as ready for review May 7, 2026 02:31
@pakrym-oai pakrym-oai requested a review from a team as a code owner May 7, 2026 02:31
Base automatically changed from pakrym/delete-tool-handler-kind to main May 7, 2026 03:36
…specs

# Conflicts:
#	codex-rs/core/src/tools/registry.rs
#	codex-rs/core/src/tools/spec.rs
#	codex-rs/core/src/tools/spec_plan.rs
#	codex-rs/core/src/tools/spec_plan_tests.rs
/// The concrete tool name handled by this handler instance.
fn tool_name(&self) -> ToolName;

fn spec(&self) -> Option<ToolSpec> {
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ofc I guess there won't be a default anymore in your final version

where
H: ToolHandler + 'static,
{
if let Some(spec) = handler.spec() {
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there is something strange here.. if the name of the tool is a duplicate, the earlier spec wins but with the latest handler. I know this is temp but can we get this straight?

@jif-oai
Copy link
Copy Markdown
Collaborator

jif-oai commented May 7, 2026

I focus on the registry as the rest seems mechanical and Codex didn't find anything

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants