mirror of
https://github.com/openai/codex.git
synced 2026-10-23 11:04:49 +00:00
jif-oai
1824685a00
## Why Codex still models model-visible tools and executable behavior largely inside `codex-core`, which makes it harder to evolve the tool system toward a single reusable abstraction for built-ins, MCP-backed tools, dynamic tools, and later tools injected from outside core. This PR takes the next incremental step in that direction by moving the common execution-facing pieces out of core and separating them from core-only orchestration. The intent is to let shared tool abstractions improve in one place, while `codex-core` keeps the parts that are still inherently host-specific today, such as `ToolInvocation`, dispatch wiring, and hook integration. This PR is mostly moving things around. The only interesting piece is this abstraction: https://github.com/openai/codex/pull/22359/changes#diff-81af519002548ba51ed102bdaaf77e081d40a1e73a6e5f9b104bbbc96a6f1b3dR13 ## What changed - Added `codex_tools::ToolExecutor<Invocation>` as the shared execution trait for model-visible tools. - Moved the reusable execution support types from `codex-core` into `codex-tools`: - `FunctionCallError` - `ToolPayload` - `ToolOutput` - Refactored core tool implementations so that execution behavior lives on `ToolExecutor<ToolInvocation>`, while `ToolHandler` remains the core-local extension point for hook payloads, telemetry tags, diff consumers, and other orchestration concerns. - Kept the registry and dispatch flow behaviorally unchanged while making the shared/extracted boundary explicit across built-in, MCP, dynamic, extension-backed, shell, and multi-agent tool handlers. ## Verification - `cargo test -p codex-tools` - `just fix -p codex-tools` - `just fix -p codex-core` - `cargo test -p codex-core` progressed through the updated tool surfaces and then hit the existing unrelated multi-agent stack overflow in `tools::handlers::multi_agents::tests::tool_handlers_cascade_close_and_resume_and_keep_explicitly_closed_subtrees_closed`.
32 lines
859 B
Rust
32 lines
859 B
Rust
use std::future::Future;
|
|
|
|
use crate::FunctionCallError;
|
|
use crate::ToolName;
|
|
use crate::ToolOutput;
|
|
use crate::ToolSpec;
|
|
|
|
/// Shared runtime contract for model-visible tools.
|
|
///
|
|
/// Implementations keep the model-visible spec tied to the executable runtime.
|
|
/// Host crates can layer routing, hooks, telemetry, or other orchestration on
|
|
/// top without reopening the spec/runtime split.
|
|
pub trait ToolExecutor<Invocation>: Send + Sync {
|
|
type Output: ToolOutput + 'static;
|
|
|
|
/// The concrete tool name handled by this runtime instance.
|
|
fn tool_name(&self) -> ToolName;
|
|
|
|
fn spec(&self) -> Option<ToolSpec> {
|
|
None
|
|
}
|
|
|
|
fn supports_parallel_tool_calls(&self) -> bool {
|
|
false
|
|
}
|
|
|
|
fn handle(
|
|
&self,
|
|
invocation: Invocation,
|
|
) -> impl Future<Output = Result<Self::Output, FunctionCallError>> + Send;
|
|
}
|