57 Commits

• Route standalone image generation through host finalization md (#25176)

  ## Why
  
  Standalone image-generation extensions emitted turn items through the
  low-level event path, bypassing host-owned finalization such as image
  persistence and contributor processing. At the same time, the
  generated-image save-path hint must remain visible to the model through
  the extension tool's `FunctionCallOutput`, rather than the legacy
  built-in developer-message path.
  
  ## What changed
  
  - Extended `ExtensionTurnItem` to support image-generation items while
  keeping the extension-facing emitter API limited to `emit_started` and
  `emit_completed`.
  - Routed extension completion through core `finalize_turn_item`, so
  standalone image-generation items receive host-owned processing and
  persisted `saved_path` values before publication.
  - Kept legacy built-in image generation on its existing
  developer-message hint path, while standalone image generation returns
  its deterministic saved-path hint in `FunctionCallOutput`.
  - Shared the image artifact path and output-hint formatting used by core
  and the image-generation extension.
  - Passed thread identity through extension tool calls so standalone
  image generation can construct the same intended artifact path as core.
  - Added an app-server integration test covering real standalone image
  generation, saved artifact publication, model-visible output hint
  wiring, and absence of the legacy developer-message hint.
  
  ## Validation
  
  - `just fmt`
  - `just test -p codex-image-generation-extension`
  - `just test -p codex-web-search-extension`
  - `just test -p codex-goal-extension`
  - `just test -p codex-memories-extension`
  - Targeted `codex-core` tests for image save history, extension
  completion finalization, and contributor execution
  - `just test -p codex-app-server
  standalone_image_generation_returns_saved_path_hint_to_model`
  - `just fix -p codex-core`
  - `just fix -p codex-image-generation-extension`
  - `just bazel-lock-update`
  - `just bazel-lock-check`

  Won Park · 2026-06-02 12:00:04 -07:00
  57f337a8e9
• Move tool search metadata onto ToolExecutor (#25684)

  Deferred tools need to be searchable even when they are not implemented
  inside `codex-core`. Extension-provided tools can be registered for
  later discovery, but the search metadata path was still owned by
  core-specific runtime hooks, which meant the shared `ToolExecutor`
  abstraction could not describe how a deferred extension tool should
  appear in `tool_search`.
  
  ## Changes
  
  - Move `ToolSearchEntry` and `ToolSearchInfo` into `codex-tools` and
  re-export them from the shared tools crate.
  - Add a default `ToolExecutor::search_info` implementation that derives
  loadable tool-search metadata from function and namespace specs.
  - Forward search metadata through extension adapters and exposure
  overrides while keeping custom search text/source metadata for dynamic,
  MCP, and multi-agent tools.
  - Remove the old core-local `tool_search_entry` module now that search
  metadata lives with the shared executor APIs.
  
  ## Testing
  
  - Added `deferred_extension_tools_are_discoverable_with_tool_search`
  coverage in `core/src/tools/spec_plan_tests.rs`.

  jif-oai · 2026-06-02 00:24:41 +02:00
  8d720feb69
• feat: gate unified exec zsh fork composition (#24979)

  ## Why
  
  `shell_zsh_fork` and unified exec need to remain independently
  controllable for enterprise rollouts, but we also need a third mode that
  composes them. That composed mode is intended to preserve unified exec
  command lifecycle support while letting the zsh fork provide more
  accurate `execv(2)` interception.
  
  Enabling `unified_exec_zsh_fork` by itself is intentionally not
  sufficient. It is a composition gate, not a dependency-enabling
  shortcut:
  
  - `unified_exec` selects the PTY-backed unified exec tool.
  - `shell_zsh_fork` opts into the zsh fork backend.
  - `unified_exec_zsh_fork` only allows those two already-enabled modes to
  be composed so local zsh unified exec commands can launch through the
  zsh fork.
  
  This separation is deliberate. Enterprises and staged rollouts must be
  able to enable or disable unified exec and zsh-fork independently. If
  `unified_exec_zsh_fork` implied either dependency, then enabling one
  under-development composition flag would silently activate a shell
  backend that the configured feature set left disabled.
  
  This PR introduces only the configuration and planning gate for that
  composition. Existing `shell_zsh_fork` behavior continues to use the
  standalone shell tool unless the new composition feature is explicitly
  enabled alongside both dependencies.
  
  ## What Changed
  
  - Added the under-development feature flag `unified_exec_zsh_fork`.
  - Added `UnifiedExecFeatureMode` so the three input feature flags
  collapse into `Disabled`, `Direct`, or `ZshFork` mode before tool
  planning.
  - Updated tool selection so zsh-fork composition requires
  `unified_exec`, `shell_zsh_fork`, and `unified_exec_zsh_fork`.
  - Kept the existing standalone zsh-fork shell tool behavior when only
  `shell_zsh_fork` is enabled.
  - Updated config schema output for the new feature flag.
  
  ## Verification
  
  - Added feature and tool-config coverage for the new gate.
  - Added planner coverage proving `shell_zsh_fork` remains standalone
  until composition is explicitly enabled.
  - Ran focused tests for `codex-features`, `codex-tools`, and the
  affected `codex-core` planner case.
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/24979).
  * #24982
  * #24981
  * #24980
  * __->__ #24979

  Michael Bolin · 2026-06-01 13:01:36 -07:00
  d6748f741a
• Route extension image generation through the native image completion pipeline (#24972)

  ## Why
  
  The standalone `image_gen.imagegen` extension should behave like native
  image generation for artifact persistence and UI completion, while
  returning its save-location guidance as part of the tool result instead
  of injecting a developer message.
  
  ## What Changed
  
  - Added an image-generation completion hook for extension tools so core
  can persist generated images and emit the existing `ImageGeneration`
  lifecycle events.
  - Reused core image artifact persistence for extension output and
  removed extension-local save-path/file-writing logic.
  - Split shared image persistence from built-in finalization so native
  image generation keeps its existing developer-message instruction
  behavior.
  - Returned the generated image save-location instruction through the
  extension `FunctionCallOutput`, alongside the generated image input for
  model follow-up.
  - Preserved the existing image-generation event shape for current UI and
  replay compatibility.
  - Avoided cloning the full generated-image base64 payload when emitting
  the in-progress image item.
  - Removed dependencies no longer needed after moving persistence out of
  the extension crate.
  
  ## Fast Follow
  - Adjust the existing Extension API and add a general `TurnItem`
  finalization path for re-usability of code
  
  ## Validation
  
  - Ran `just fmt`.
  - Ran `just bazel-lock-update`.
  - Ran `just bazel-lock-check`.
  - Ran `just test -p codex-tools -p codex-extension-api -p
  codex-image-generation-extension`.
  - Ran `just test -p codex-core
  image_generation_publication_is_finalized_by_core`.
  - Ran `just test -p codex-core
  handle_output_item_done_records_image_save_history_message`.
  - Ran `just fix -p codex-tools -p codex-extension-api -p codex-core -p
  codex-image-generation-extension`.

  Won Park · 2026-05-29 17:33:13 +00:00
  10b0399034
• extension-api: add TurnItemEmitter to tool calls (#24813)

  ## Why
  Extension-contributed tools need to emit visible turn items through
  Codex's normal event and persistence pipeline.
  
  ## What
  - Add `TurnItemEmitter` to extension `ToolCall`s and route the core
  implementation through `Session::emit_turn_item_*`.
  - Hold weak session and turn references so retained tool calls cannot
  keep host state alive.
  - Provide a no-op emitter for extension test callers.
  
  ## Test Plan
  - `just test -p codex-core -E
  'test(passes_turn_fields_and_scoped_turn_item_emitter_to_extension_call)'`
  
  ---------
  
  Co-authored-by: jif-oai <jif@openai.com>

  sayan-oai · 2026-05-28 09:13:43 -07:00
  2066874415
• fix: dont compact standalone websearch schema (#24660)

  add new `parse_tool_input_schema_without_compaction` to bypass the
  existing compaction/trimming of client-provided tool schemas that are
  over 4k bytes.
  
  we want this for standalone web search to keep field guidance/metadata
  on certain fields; this keeps us closer to parity with existing hosted
  tool schema (which didnt go through this 4k byte filter).

  sayan-oai · 2026-05-27 01:05:19 +00:00
  9fe55d68e6
• standalone websearch extension (#23823)

  ## Summary
  
  Add the extension-backed standalone `web.run` tool so Codex can call the
  standalone search endpoint through the `codex-api` search client and
  return its encrypted output to Responses.
  
  - gate the new tool behind `standalone_web_search`
  - install the extension in the app-server thread registry and hide
  hosted `web_search` when standalone search is enabled for OpenAI
  providers so the two paths stay mutually exclusive
  - build search context from persisted history using a small tail
  heuristic: previous user message, assistant text between the last two
  user turns capped at about 1k tokens, and current user message
  
  ## Test Plan
  
  - `cargo test -p codex-web-search-extension`
  - `cargo test -p codex-api`
  - `cargo test -p codex-core
  hosted_tools_follow_provider_auth_model_and_config_gates`

  sayan-oai · 2026-05-26 11:12:24 -07:00
  a22706dfae
• Expose conversation history to extension tools (#23963)

  ## Why
  
  Extension tools that need conversation context should be able to read it
  from the live tool invocation instead of reaching into thread
  persistence themselves.
  
  ## What changed
  
  - Add a `ConversationHistory` snapshot to extension `ToolCall`s and
  populate it from the current raw in-memory response history.
  - Expose all history items at this boundary so each extension can filter
  and bound the subset it needs before consuming or forwarding it.
  - Cover the adapter and registry dispatch paths and update existing
  extension tests that construct `ToolCall` literals.
  
  ## Test plan
  
  - `cargo test -p codex-tools`
  - `cargo test -p codex-extension-api`
  - `cargo test -p codex-goal-extension`
  - `cargo test -p codex-memories-extension`
  - `cargo test -p codex-core passes_turn_fields_to_extension_call`
  - `cargo test -p codex-core
  extension_tool_executors_are_model_visible_and_dispatchable`

  sayan-oai · 2026-05-22 01:11:47 +00:00
  7e802b22f1
• Split plugin install discovery into list and request tools (#23372)

  ## Summary
  - Add `list_available_plugins_to_install` as the inventory step for
  plugin and connector install suggestions.
  - Slim `request_plugin_install` so it only handles the actual
  elicitation, instead of carrying the full discoverable list in its
  prompt.
  - Emit send-time telemetry when an install elicitation is dispatched,
  including requested tool identity in the event payload.
  - Emit install-result telemetry through `SessionTelemetry`, including
  tool type, user response action, and completion status.
  - Update registration and tests to cover the new two-step flow while
  keeping the existing `tool_suggest` feature gate unchanged.
  
  ## Testing
  - `just fmt`
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core request_plugin_install`
  - `cargo test -p codex-core list_available_plugins_to_install`
  - `cargo test -p codex-core
  install_suggestion_tools_can_be_registered_without_search_tool`
  - `cargo test -p codex-otel
  manager_records_plugin_install_suggestion_metric`
  - `cargo test -p codex-otel
  manager_records_plugin_install_elicitation_sent_metric`
  - `just fix -p codex-core`
  - `just fix -p codex-tools`
  - `just fix -p codex-otel`
  - `cargo check -p codex-core`

  Matthew Zeng · 2026-05-19 14:45:37 -07:00
  8335b56c33
• Remove ToolsConfig from tool planning (#22835)

  ## Why
  
  `codex-tools` is meant to hold reusable tool primitives, but
  `ToolsConfig` had become a second copy of core runtime decisions instead
  of a small shared contract. It carried provider capabilities, auth/model
  gates, permission and environment state, web/search/image feature gates,
  multi-agent settings, and goal availability from core into `codex-tools`
  ([definition](https://github.com/openai/codex/blob/22dd9ad3929253ed24d7ee4f10f238e95ab25f37/codex-rs/tools/src/tool_config.rs#L97),
  [stored on each
  `TurnContext`](https://github.com/openai/codex/blob/22dd9ad3929253ed24d7ee4f10f238e95ab25f37/codex-rs/core/src/session/turn_context.rs#L87)).
  Every session/context variant then had to build and mutate that snapshot
  before assembling tools.
  
  This PR removes that master object instead of renaming it. Tool planning
  now reads the live `TurnContext`, where `codex-core` already owns those
  decisions, while `codex-tools` keeps only reusable primitives and a
  generic `ToolSetBuilder`/`ToolSet` accumulator.
  
  ## What Changed
  
  - Removed `ToolsConfig` / `ToolsConfigParams` from `codex-tools`; the
  crate keeps the shared helpers that still belong there, including
  request-user-input mode selection, shell backend/type resolution,
  `UnifiedExecShellMode`, and `ToolEnvironmentMode`.
  - Replaced config-snapshot planning with `ToolRouter::from_turn_context`
  and a `spec_plan` pipeline over `CoreToolPlanContext`, deriving provider
  capabilities, auth gates, model support, feature gates, environment
  count, goal support, multi-agent options, web search, and image
  generation from the authoritative turn state.
  - Added generic `codex_tools::ToolSetBuilder` / `ToolSet`, plus the
  small core adapter needed to accumulate `CoreToolRuntime` values and
  hosted model specs.
  - Added the `tool_family::shell` registration module and moved
  shell/unified-exec/memory accounting call sites to read the narrow
  per-turn fields directly.
  - Narrowed `TurnContext` to the remaining explicit per-turn fields
  needed by planning: `available_models`, `unified_exec_shell_mode`, and
  `goal_tools_supported`.
  - Reworked MCP exposure and tool-search setup so deferred/direct MCP
  behavior is driven by the current turn rather than a precomputed config
  snapshot.
  - Replaced the large expected-spec fixture tests with focused
  behavior-level coverage for shell tools, environments, goal and
  agent-job gates, MCP direct/deferred exposure, tool search,
  request-plugin-install, code mode, multi-agent mode, hosted tools, and
  extension executor dispatch.
  
  ## Verification
  
  - `cargo check -p codex-tools`
  - `cargo check -p codex-core --lib`
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core spec_plan --lib`
  - `cargo test -p codex-core router --lib`

  jif-oai · 2026-05-19 11:24:09 +02:00
  05e171094d
• Introduce tool exposure for deferred registration (#22489)

  ## Why
  
  Deferred tools were tracked with separate side-channel filtering after
  tool specs had already been assembled. That made the registry
  responsible for executing tools while the router/spec planner separately
  decided whether those same tools should be exposed to the model up
  front.
  
  This PR makes exposure part of the tool handler contract so direct
  versus deferred availability travels with the executable tool
  registration.
  
  Next step will be to simplify registration
  
  ## What Changed
  
  - Adds `ToolExposure` to `codex-tools` and exposes it through
  `ToolExecutor`, defaulting tools to `Direct`.
  - Teaches dynamic tools and MCP handlers to mark deferred tools as
  `Deferred` at construction time.
  - Renames the registry object-safe wrapper from `AnyToolHandler` to
  `RegisteredTool` and uses `ToolExposure` when deciding whether to
  include a handler's spec in the initial model-visible tool list.
  - Refactors tool spec planning to derive direct specs and deferred
  search entries from registered handlers, removing the router's
  special-case deferred dynamic tool filtering.
  
  ## Verification
  
  - Not run.

  jif-oai · 2026-05-13 18:16:51 +02:00
  fdda59c00b
• Refactor extension tools onto shared ToolExecutor (#22369)

  ## Why
  
  Extension tools were split across two public runtime contracts:
  `codex-tool-api` exposed `ToolBundle` plus its own call/spec/error
  types, while core native tools used `codex_tools::ToolExecutor`. That
  made contributed tool specs and execution behavior easy to drift apart
  and added another crate boundary for what should be one executable-tool
  seam.
  
  This PR makes `ToolExecutor` the single runtime contract and keeps
  extension-specific pinning in `codex-extension-api`.
  
  ## Remaining todo
  
  https://github.com/openai/codex/pull/22369/changes#diff-b935ea8245c3ce568a30cff660175fa6390b66b872ae409e1e2e965738250741R5
  Either generic `Invocation` or sub-extract the `ToolCall` and clean
  `ToolInvocation`
  
  ## What changed
  
  - Removed the `codex-tool-api` workspace crate and its dependencies from
  core and `codex-extension-api`.
  - Made `codex_tools::ToolExecutor` object-safe with `async_trait` so
  extension contributors can return a dyn executor.
  - Added the extension-facing aliases under
  `ext/extension-api/src/contributors/tools.rs`, including
  `ExtensionToolExecutor = dyn ToolExecutor<ToolCall, Output =
  ExtensionToolOutput>`.
  - Changed `ToolContributor::tools` to return extension executors
  directly instead of `ToolBundle`s.
  - Updated core’s extension tool handler/registry/router path to adapt
  those extension executors into the existing native `ToolInvocation`
  runtime path.
  - Added focused coverage for extension tools being registered,
  model-visible, dispatchable, and not replacing built-in tools.
  
  ## Verification
  
  - `cargo test -p codex-tools`
  - `cargo test -p codex-extension-api`

  jif-oai · 2026-05-13 12:12:06 +02:00
  9c5dfa7b1a
• feat: extract shared tool executor interface (#22359)

  ## 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`.

  jif-oai · 2026-05-13 11:31:27 +02:00
  1824685a00
• Encapsulate tool search entries in handlers (#22261)

  ## Why
  
  This builds on the handler-owned spec refactor by moving deferred
  tool-search metadata to the same handlers that already own tool specs.
  The registry builder no longer needs a separate prebuilt
  `tool_search_entries` path; it can collect searchable entries from
  deferred handlers directly.
  
  ## What changed
  
  - Added `search_info()` to tool handlers and implemented it for MCP and
  dynamic handlers.
  - Reused handler `spec()` output when constructing tool-search entries,
  adapting it into the deferred `LoadableToolSpec` shape expected by
  `tool_search`.
  - Simplified `build_tool_registry_builder(...)` so `tool_search`
  registration is based on deferred handlers with search info.
  - Removed the old standalone search-entry builders and now-unused
  `codex-tools` discovery helper exports.
  
  ## Verification
  
  - `cargo test -p codex-core tools::handlers::tool_search::tests:: --
  --nocapture`
  - `cargo test -p codex-core tools::spec_plan::tests::search_tool --
  --nocapture`
  - `cargo test -p codex-core tools::spec::tests:: -- --nocapture`
  - `cargo test -p codex-core tools::spec_plan::tests:: -- --nocapture`
  - `cargo test -p codex-tools`
  - `just fix -p codex-core`
  - `just fix -p codex-tools`

  pakrym-oai · 2026-05-12 20:48:02 -07:00
  104fc14956
• [codex] Make handlers own parallel tool support (#22254)

  ## Why
  
  `ToolRouter::tool_supports_parallel()` was still consulting configured
  specs when a handler lookup missed, even though parallel schedulability
  is really a property of the executable handler. Keeping that metadata on
  `ConfiguredToolSpec` duplicated state between the model-visible spec
  layer and the runtime handler layer.
  
  This change makes handlers the sole source of truth for parallel tool
  support and removes the extra spec wrapper that only existed to carry
  duplicated metadata.
  
  ## What changed
  
  - removed `ConfiguredToolSpec` and store plain `ToolSpec` values in the
  registry/router builder path
  - changed `ToolRouter::tool_supports_parallel()` to consult only the
  handler registry and fall back to `false`
  - simplified spec collection and test helpers to operate directly on
  `ToolSpec`
  - updated router/spec tests to cover handler-owned parallel behavior and
  the no-handler fallback
  
  ## Validation
  
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core mcp_parallel_support_uses_handler_data`
  - `cargo test -p codex-core
  deferred_responses_api_tool_serializes_with_defer_loading`
  - `cargo test -p codex-core
  tools_without_handlers_do_not_support_parallel`
  - `cargo test -p codex-core
  request_plugin_install_can_be_registered_without_search_tool`
  
  ## Docs
  
  No documentation updates needed.

  pakrym-oai · 2026-05-11 22:26:33 -07:00
  c9e46ed639
• [codex] Move tool specs into core handlers (#21416)

  ## Why
  
  This is the first mechanical slice of moving tool spec ownership toward
  the handlers. `codex-tools` should keep shared primitives and conversion
  helpers, while builtin tool specs and registration planning live in
  `codex-core` with the handlers that own those tools.
  
  Keeping this PR to relocation and import updates isolates the copy/move
  review from the later logic change that wires specs through registered
  handlers.
  
  ## What changed
  
  - Moved builtin tool spec constructors from `codex-rs/tools/src` into
  `codex-rs/core/src/tools/handlers/*_spec.rs` or nearby core tool
  modules.
  - Moved the registry planning code into
  `codex-rs/core/src/tools/spec_plan.rs` and its associated types/tests
  into core.
  - Kept shared primitives in `codex-tools`, including `ToolSpec`,
  schema/types, discovery/config primitives, dynamic/MCP conversion
  helpers, and code-mode collection helpers.
  - Updated handlers that referenced moved argument types or tool-name
  constants to use the core spec modules.
  - Moved spec tests next to the moved spec modules.
  
  ## Verification
  
  - `cargo check -p codex-tools`
  - `cargo check -p codex-core`
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core _spec::tests`
  - `cargo test -p codex-core tools::spec_plan::tests`
  - `just fix -p codex-tools`
  - `just fix -p codex-core`
  
  Note: I also tried the broader `cargo test -p codex-core tools::`; it
  reached the moved spec-plan/spec tests successfully, then aborted with a
  stack overflow in
  `tools::handlers::multi_agents::tests::tool_handlers_cascade_close_and_resume_and_keep_explicitly_closed_subtrees_closed`,
  which is outside this spec relocation.

  pakrym-oai · 2026-05-06 15:40:50 -07:00
  9417cf9696
• tools: remove unused experimental list_dir tool (#21170)

  ## Why
  `list_dir` still carries a full spec/handler/test path, but nothing in
  the current model catalog advertises it via
  `experimental_supported_tools`. That leaves us maintaining an
  environment-backed tool surface that is effectively unused.
  
  ## What changed
  - delete the `list_dir` handler and its tests from `codex-core`
  - remove the `list_dir` spec builder, handler kind, and registry wiring
  from `codex-tools`
  - clean up the remaining internal README and registry tests so they no
  longer mention the removed tool

  jif-oai · 2026-05-05 13:11:07 +02:00
  70807730f5
• Prepare selected environment plumbing (#20669)

  ## Why
  This is a prep PR in the multi-environment process-tool stack. It
  separates ownership/config cleanup from the behavior change that teaches
  process tools to route by selected environment, so the follow-up PR can
  focus on model-facing `environment_id` behavior.
  
  ## Stack
  1. https://github.com/openai/codex/pull/20646 - `EnvironmentContext`
  rendering for selected environments
  2. https://github.com/openai/codex/pull/20669 - selected-environment
  ownership and tool config prep (this PR)
  3. https://github.com/openai/codex/pull/20647 - process-tool
  `environment_id` routing
  
  ## What Changed
  - keep the resolved turn environment list wrapped in
  `ResolvedTurnEnvironments` through `TurnContext` instead of unwrapping
  it back to a raw `Vec`
  - add `TurnContext::resolve_path_against` so cwd-relative path
  resolution has one shared helper
  - replace the old tool config boolean with `ToolEnvironmentMode::{None,
  Single, Multiple}`
  
  ## Testing
  - Tests not run locally; this prep refactor is covered by GitHub CI for
  the stack.
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-05-04 17:55:49 +00:00
  905987c08f
• [tool_suggest] More prompt polishes. (#20566)

  Tool suggest still misfires when model needs tool_search, updating the
  prompts to further disambiguate it:
  
  - [x] rename it from `tool_suggest` to `request_plugin_install`
  - [x] rephrase "suggestion" to "install" in the tool descriptions.
  - [x] disambiguate "the tool" vs "the plugin/connector". 
  
  Tested with the Codex App and verified it still works.

  Matthew Zeng · 2026-05-02 04:22:12 +00:00
  f88701f5c8
• Reduce the surface of collaboration modes (#20149)

  Collaboration modes were slightly invasive both into ThreadManager
  construction and ModelProvider

  pakrym-oai · 2026-04-29 17:22:41 -07:00
  fedcefe9da
• Support disabling tool suggest for specific tools. (#20072)

  ## Summary
  - Add `disable_tool_suggest` to app and plugin config, schema, and
  TypeScript output
  - Exclude disabled connectors and plugins from tool suggestion discovery
  - Persist "never show again" tool-suggestion choices back into
  `config.toml`
  - Update config docs and add coverage for connector and plugin
  suppression
  
  ## Testing
  - Added and updated unit tests for config persistence and tool-suggest
  filtering
  - Not run (not requested)

  Matthew Zeng · 2026-04-29 00:19:34 +00:00
  ebdf3a878c
• Add goal model tools (3 / 5) (#18075)

  Adds the model-facing goal tools on top of the app-server API from PR 2.
  
  ## Why
  
  Once goals are persisted and exposed to clients, the model needs a
  small, constrained tool surface for goal workflows. The tool contract
  should let the model inspect goals, create them only when explicitly
  requested, and mark them complete without giving it broad control over
  user/runtime-owned state.
  
  ## What changed
  
  - Added `get_goal`, `create_goal`, and `update_goal` tool specs behind
  the `goals` feature flag.
  - Added core goal tool handlers that validate objectives and token
  budgets before mutating persisted state.
  - Constrained `create_goal` to create only when no goal exists, with
  optional `token_budget` only when a budget is explicitly provided.
  - Tightened the `create_goal` instructions so the model does not infer
  goals from ordinary task requests.
  - Constrained `update_goal` to expose only goal completion; pause,
  resume, clear, and budget-limited transitions remain user- or
  runtime-controlled.
  - Registered the goal tools in the tool registry and kept them out of
  review contexts where they should not appear.
  
  ## Verification
  
  - Added tool-registry coverage for feature gating and tool availability.
  - Added core session tests for create/get/update behavior, duplicate
  goal rejection, budget validation, and completion-only updates.

  Eric Traut · 2026-04-24 20:54:40 -07:00
  32ace07ac5
• Remove js_repl feature (#19410)
  Curtis 'Fjord' Hawthorne · 2026-04-24 17:49:29 -07:00
  8a559e7938
• [tool search] support namespaced deferred dynamic tools (#18413)

  Deferred dynamic tools need to round-trip a namespace so a tool returned
  by `tool_search` can be called through the same registry key that core
  uses for dispatch.
  
  This change adds namespace support for dynamic tool specs/calls,
  persists it through app-server thread state, and routes dynamic tool
  calls by full `ToolName` while still sending the app the leaf tool name.
  Deferred dynamic tools must provide a namespace; non-deferred dynamic
  tools may remain top-level.
  
  It also introduces `LoadableToolSpec` as the shared
  function-or-namespace Responses shape used by both `tool_search` output
  and dynamic tool registration, so dynamic tools use the same wrapping
  logic in both paths.
  
  Validation:
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core tool_search`
  
  ---------
  
  Co-authored-by: Sayan Sisodiya <sayan@openai.com>

  pash-openai · 2026-04-21 14:13:08 +08:00
  dc1a8f2190
• enable tool search over dynamic tools (#18263)

  ## Summary
  
  - Normalize deferred MCP and dynamic tools into `ToolSearchEntry` values
  before constructing `ToolSearchHandler`.
  - Move the tool-search entry adapter out of `tools/handlers` and into
  `tools/tool_search_entry.rs` so the handlers directory stays focused on
  handlers.
  - Keep `ToolSearchHandler` operating over one generic entry list for
  BM25 search, namespace grouping, and per-bucket default limits.
  
  ## Why
  
  Follow-up cleanup for #17849. The dynamic tool-search support made the
  handler juggle source-specific MCP and dynamic tool lists, index
  arithmetic, output conversion, and namespace emission. This keeps source
  adaptation outside the handler so the search loop itself is smaller and
  source-agnostic.
  
  ## Validation
  
  - `just fmt`
  - `cargo test -p codex-core tools::handlers::tool_search::tests`
  - `git diff --check`
  - `cargo test -p codex-core` currently fails in unrelated
  `plugins::manager::tests::list_marketplaces_ignores_installed_roots_missing_from_config`;
  rerunning that single test fails the same way at
  `core/src/plugins/manager_tests.rs:1692`.
  
  ---------
  
  Co-authored-by: pash <pash@openai.com>

  sayan-oai · 2026-04-18 02:07:59 +08:00
  6991be7ead
• Support original-detail metadata on MCP image outputs (#17714)

  ## Summary
  - honor `_meta["codex/imageDetail"] == "original"` on MCP image content
  and map it to `detail: "original"` where supported
  - strip that detail back out when the active model does not support
  original-detail image inputs
  - update code-mode `image(...)` to accept individual MCP image blocks
  - teach `js_repl` / `codex.emitImage(...)` to preserve the same hint
  from raw MCP image outputs
  - document the new `_meta` contract and add generic RMCP-backed coverage
  across protocol, core, code-mode, and js_repl paths

  Curtis 'Fjord' Hawthorne · 2026-04-15 14:43:33 -07:00
  9e2fc31854
• Fix empty tool descriptions (#17946)

  ## Summary
  - Ensure direct namespaced MCP tool groups are emitted with a non-empty
  namespace description even when namespace metadata is missing or blank.
  - Add regression coverage for missing MCP namespace descriptions.
  
  ## Cause
  Latest `main` can serialize a direct namespaced MCP tool group with an
  empty top-level `description`. The namespace description path used
  `unwrap_or_default()` when `tool_namespaces` did not include metadata
  for that namespace, so the outbound Responses API payload could contain
  a tool like `{"type":"namespace","description":""}`. The Responses API
  rejects that because namespace tool descriptions must be a non-empty
  string.
  
  ## Fix
  - Add a fallback namespace description: `Tools in the <namespace>
  namespace.`
  - Preserve provided namespace descriptions after trimming, but treat
  blank descriptions as missing.
  
  ### Issue I am seeing
  This is what I am seeing on the local build.
  <img width="1593" height="488" alt="Screenshot 2026-04-15 at 10 55 55
  AM"
  src="https://github.com/user-attachments/assets/bab668ba-bf17-4c71-be4e-b102202fce57"
  />
  
  ---------
  
  Co-authored-by: Sayan Sisodiya <sayan@openai.com>

  Shijie Rao · 2026-04-15 18:14:43 +00:00
  78ce61c78e
• register all mcp tools with namespace (#17404)

  stacked on #17402.
  
  MCP tools returned by `tool_search` (deferred tools) get registered in
  our `ToolRegistry` with a different format than directly available
  tools. this leads to two different ways of accessing MCP tools from our
  tool catalog, only one of which works for each. fix this by registering
  all MCP tools with the namespace format, since this info is already
  available.
  
  also, direct MCP tools are registered to responsesapi without a
  namespace, while deferred MCP tools have a namespace. this means we can
  receive MCP `FunctionCall`s in both formats from namespaces. fix this by
  always registering MCP tools with namespace, regardless of deferral
  status.
  
  make code mode track `ToolName` provenance of tools so it can map the
  literal JS function name string to the correct `ToolName` for
  invocation, rather than supporting both in core.
  
  this lets us unify to a single canonical `ToolName` representation for
  each MCP tool and force everywhere to use that one, without supporting
  fallbacks.

  sayan-oai · 2026-04-15 21:02:59 +08:00
  0df7e9a820
• chore: refactor name and namespace to single type (#17402)

  avoid passing them both around, unify on a type. this now also keys
  `ToolRegistry`.
  
  tests pass

  sayan-oai · 2026-04-11 23:06:22 +00:00
  1325bcd3f6
• Add output_schema to code mode render (#17210)

  This updates code-mode tool rendering so MCP tools can surface
  structured output types from their `outputSchema`.
  
  What changed:
  - Detect MCP tool-call result wrappers from the output schema shape
  instead of relying on tool-name parsing or provenance flags.
  - Render shared TypeScript aliases once for MCP tool results
  (`CallToolResult`, `ContentBlock`, etc.) so multiple MCP tool
  declarations stay compact.
  - Type `structuredContent` from the tool definition's `outputSchema`
  instead of rendering it as `unknown`.
  - Update the shared MCP aliases to match the MCP draft `CallToolResult`
  schema more closely.
  
  Example:
  - Before: `declare const tools: { mcp__rmcp__echo(args: { env_var?:
  string; message: string; }): Promise<{ _meta?: unknown; content:
  Array<unknown>; isError?: boolean; structuredContent?: unknown; }>; };`
  - After: `declare const tools: { mcp__rmcp__echo(args: { env_var?:
  string; message: string; }): Promise<CallToolResult<{ echo: string; env:
  string | null; }>>; };`

  Vivian Fang · 2026-04-10 11:41:44 +00:00
  7bbe3b6011
• [mcp] Expand tool search to custom MCPs. (#16944)

  - [x] Expand tool search to custom MCPs.
  - [x] Rename several variables/fields to be more generic.
  
  Updated tool & server name lifecycles:
  
  **Raw Identity**
  
  ToolInfo.server_name is raw MCP server name.
  ToolInfo.tool.name is raw MCP tool name.
  MCP calls route back to raw via parse_tool_name() returning
  (tool.server_name, tool.tool.name).
  mcpServerStatus/list now groups by raw server and keys tools by
  Tool.name: mod.rs:599
  App-server just forwards that grouped raw snapshot:
  codex_message_processor.rs:5245
  
  **Callable Names**
  
  On list-tools, we create provisional callable_namespace / callable_name:
  mcp_connection_manager.rs:1556
  For non-app MCP, provisional callable name starts as raw tool name.
  For codex-apps, provisional callable name is sanitized and strips
  connector name/id prefix; namespace includes connector name.
  Then qualify_tools() sanitizes callable namespace + name to ASCII alnum
  / _ only: mcp_tool_names.rs:128
  Note: this is stricter than Responses API. Hyphen is currently replaced
  with _ for code-mode compatibility.
  
  **Collision Handling**
  
  We do initially collapse example-server and example_server to the same
  base.
  Then qualify_tools() detects distinct raw namespace identities behind
  the same sanitized namespace and appends a hash to the callable
  namespace: mcp_tool_names.rs:137
  Same idea for tool-name collisions: hash suffix goes on callable tool
  name.
  Final list_all_tools() map key is callable_namespace + callable_name:
  mcp_connection_manager.rs:769
  
  **Direct Model Tools**
  
  Direct MCP tool declarations use the full qualified sanitized key as the
  Responses function name.
  The raw rmcp Tool is converted but renamed for model exposure.
  
  **Tool Search / Deferred**
  
  Tool search result namespace = final ToolInfo.callable_namespace:
  tool_search.rs:85
  Tool search result nested name = final ToolInfo.callable_name:
  tool_search.rs:86
  Deferred tool handler is registered as "{namespace}:{name}":
  tool_registry_plan.rs:248
  When a function call comes back, core recombines namespace + name, looks
  up the full qualified key, and gets the raw server/tool for MCP
  execution: codex.rs:4353
  
  **Separate Legacy Snapshot**
  
  collect_mcp_snapshot_from_manager_with_detail() still returns a map
  keyed by qualified callable name.
  mcpServerStatus/list no longer uses that; it uses
  McpServerStatusSnapshot, which is raw-inventory shaped.

  Matthew Zeng · 2026-04-09 13:34:52 -07:00
  d7f99b0fa6
• Render namespace description for tools (#16879)
  Vivian Fang · 2026-04-08 02:39:40 -07:00
  d47b755aa2
• Support anyOf and enum in JsonSchema (#16875)

  This brings us into better alignment with the JSON schema subset that is
  supported in
  <https://developers.openai.com/api/docs/guides/structured-outputs#supported-schemas>,
  and also allows us to render richer function signatures in code mode
  (e.g., anyOf{null, OtherObjectType})

  Vivian Fang · 2026-04-08 01:07:55 -07:00
  ea516f9a40
• chore: rename assign_task for followup_task (#16571)
  jif-oai · 2026-04-02 16:51:17 +02:00
  7fc36249b5
• Extract tool registry planning into codex-tools (#16513)

  ## Why
  This is a larger step in the `codex-core` -> `codex-tools` migration
  called out in `AGENTS.md`.
  
  `codex-rs/core/src/tools/spec.rs` had become mostly pure tool-spec
  assembly plus handler registration. That made it hard to move more of
  the tool-definition layer into `codex-tools`, because the runtime
  binding and the crate-independent planning logic were still interleaved
  in one function.
  
  Splitting those concerns gives `codex-tools` ownership of the
  declarative registry plan while keeping `codex-core` responsible for
  instantiating concrete handlers.
  
  ## What Changed
  - Add a `codex-tools` registry-plan layer in
  `codex-rs/tools/src/tool_registry_plan.rs` and
  `codex-rs/tools/src/tool_registry_plan_types.rs`.
  - Move feature-gated tool-spec assembly, MCP/dynamic tool conversion,
  tool-search aliases, and code-mode nested-plan expansion into
  `codex-tools`.
  - Keep `codex-rs/core/src/tools/spec.rs` as the core-side adapter that
  maps each planned handler kind to concrete runtime handler instances.
  - Update `spec_tests.rs` to import the moved `codex_tools` symbols
  directly instead of relying on top-level `spec.rs` re-exports.
  
  This is intended to be a straight refactor with no behavior change and
  no new test surface.
  
  ## Verification
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core tools::spec::tests`
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/16513).
  * #16521
  * __->__ #16513

  Michael Bolin · 2026-04-02 00:18:18 -07:00
  828b837235
• Extract code-mode nested tool collection into codex-tools (#16509)

  ## Why
  This is another small step in the `codex-core` -> `codex-tools`
  migration described in `AGENTS.md`.
  
  `core/src/tools/spec.rs` and `core/src/tools/code_mode/mod.rs` were both
  hand-rolling the same pure transformation: convert visible `ToolSpec`s
  into code-mode nested tool definitions, then sort and deduplicate by
  tool name. That logic does not depend on core runtime state or handlers,
  so keeping it in `codex-core` makes `spec.rs` harder to peel out later
  than it needs to be.
  
  ## What Changed
  - Add `collect_code_mode_tool_definitions()` to
  `codex-rs/tools/src/code_mode.rs`.
  - Reuse that helper from `codex-rs/core/src/tools/spec.rs` when
  assembling the `exec` tool description.
  - Reuse the same helper from `codex-rs/core/src/tools/code_mode/mod.rs`
  when exposing nested tool metadata to the code-mode runtime.
  
  This is intended to be a straight refactor with no behavior change and
  no new test surface.
  
  ## Verification
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core tools::spec::tests`
  - `cargo test -p codex-core code_mode_only_`

  Michael Bolin · 2026-04-01 22:17:55 -07:00
  9f71d57a65
• Extract request_user_input normalization into codex-tools (#16503)

  ## Why
  This is another incremental step in the `codex-core` -> `codex-tools`
  migration called out in `AGENTS.md`: keep pure tool-definition and
  wire-shaping logic out of `codex-core` so the core crate can stay
  focused on runtime orchestration.
  
  `request_user_input` already had its spec and mode-availability helpers
  in `codex-tools` after #16471. The remaining argument validation and
  normalization still lived in the core runtime handler, which left that
  tool split across the two crates.
  
  ## What Changed
  - Export `REQUEST_USER_INPUT_TOOL_NAME` and
  `normalize_request_user_input_args()` from
  `codex-rs/tools/src/request_user_input_tool.rs`.
  - Use that `codex-tools` surface from `codex-rs/core/src/tools/spec.rs`
  and `codex-rs/core/src/tools/handlers/request_user_input.rs`.
  - Keep the core handler responsible for payload parsing, session
  dispatch, cancellation handling, and response serialization.
  
  This is intended to be a straight refactor with no behavior change.
  
  ## Verification
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core request_user_input`

  Michael Bolin · 2026-04-01 21:18:45 -07:00
  1b5a16f05e
• Extract tool-suggest wire helpers into codex-tools (#16499)

  ## Why
  
  This is another straight-refactor step in the `codex-tools` migration.
  
  `core/src/tools/handlers/tool_suggest.rs` still owned request/response
  payload structs, elicitation metadata shaping, and connector-completion
  predicates that do not depend on `codex-core` session/runtime internals.
  Per the `AGENTS.md` guidance to keep shrinking `codex-core`, this moves
  that pure wire-format logic into `codex-rs/tools` so the core handler
  keeps only session orchestration, plugin/config refresh, and MCP cache
  updates.
  
  ## What changed
  
  - Added `codex-rs/tools/src/tool_suggest.rs` and exported its API from
  `codex-rs/tools/src/lib.rs`.
  - Moved `ToolSuggestArgs`, `ToolSuggestResult`, `ToolSuggestMeta`,
  `build_tool_suggestion_elicitation_request()`,
  `all_suggested_connectors_picked_up()`, and
  `verified_connector_suggestion_completed()` into `codex-tools`.
  - Rewired `core/src/tools/handlers/tool_suggest.rs` to consume those
  exports directly.
  - Ported the existing pure helper tests from
  `core/src/tools/handlers/tool_suggest_tests.rs` to
  `tools/src/tool_suggest_tests.rs` without adding new behavior coverage.
  
  ## Validation
  
  ```shell
  cargo test -p codex-tools
  cargo test -p codex-core tools::handlers::tool_suggest::tests
  just argument-comment-lint
  ```

  Michael Bolin · 2026-04-01 20:49:15 -07:00
  d1068e057a
• Extract tool-search output helpers into codex-tools (#16497)

  ## Why
  
  This is the next straight-refactor step in the `codex-tools` migration
  that follows #16493.
  
  `codex-rs/core` still owned a chunk of pure tool-discovery metadata and
  response shaping even though the corresponding `tool_search` /
  `tool_suggest` specs already live in `codex-rs/tools`. Per the guidance
  in `AGENTS.md`, this moves that crate-agnostic logic out of `codex-core`
  so the handler crate keeps only the BM25 ranking/orchestration and
  runtime glue.
  
  ## What changed
  
  - Moved the canonical `tool_search` / `tool_suggest` tool names and the
  `tool_search` default limit into `codex-rs/tools/src/tool_discovery.rs`.
  - Added `ToolSearchResultSource` and
  `collect_tool_search_output_tools()` in `codex-tools` so namespace
  grouping and deferred Responses API tool serialization happen outside
  `codex-core`.
  - Rewired `ToolSearchHandler`, `ToolSuggestHandler`, and
  `core/src/tools/spec.rs` to consume those exports directly from
  `codex-tools`.
  - Ported the existing `tool_search` serializer tests from
  `core/src/tools/handlers/tool_search_tests.rs` to
  `tools/src/tool_discovery_tests.rs` without adding new behavior
  coverage.
  
  ## Validation
  
  ```shell
  cargo test -p codex-tools
  cargo test -p codex-core tools::spec::tests
  just argument-comment-lint
  ```

  Michael Bolin · 2026-04-01 20:16:21 -07:00
  0b856a4757
• Extract built-in tool spec constructors into codex-tools (#16493)

  ## Why
  
  `core/src/tools/spec.rs` still had a few built-in tool specs assembled
  inline even though those definitions are pure metadata and already live
  conceptually in `codex-tools`. Keeping that construction in `codex-core`
  makes `spec.rs` do more than registry orchestration and slows the
  migration toward a right-sized `codex-tools` crate.
  
  This continues the extraction stack from #16379, #16471, #16477, #16481,
  and #16482.
  
  ## What Changed
  
  - added `create_local_shell_tool()`, `create_web_search_tool(...)`, and
  `create_image_generation_tool(...)` to `codex-rs/tools/src/tool_spec.rs`
  - exported those helpers from `codex-rs/tools/src/lib.rs`
  - switched `codex-rs/core/src/tools/spec.rs` to call those helpers
  instead of constructing `ToolSpec::LocalShell`, `ToolSpec::WebSearch`,
  and `ToolSpec::ImageGeneration` inline
  - removed the remaining core-local web-search content-type constant and
  made the affected spec test assert the literal expected values directly
  
  This is intended to be a straight refactor: tool behavior and wire shape
  should not change.
  
  ## Testing
  
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core tools::spec::tests`

  Michael Bolin · 2026-04-01 19:31:24 -07:00
  5a2f3a8102
• Extract update_plan tool spec into codex-tools (#16481)

  ## Why
  
  `codex-rs/core/src/tools/handlers/plan.rs` still owned both the
  `update_plan` runtime handler and the static tool definition. The tool
  definition is pure metadata, so keeping it in `codex-core` works against
  the ongoing effort to move tool-spec code into `codex-tools` and keep
  `codex-core` focused on orchestration and execution paths.
  
  This continues the extraction work from #16379, #16471, and #16477.
  
  ## What Changed
  
  - added `codex-rs/tools/src/plan_tool.rs` with
  `create_update_plan_tool()`
  - re-exported that constructor from `codex-rs/tools/src/lib.rs`
  - updated `codex-rs/core/src/tools/spec.rs` and
  `codex-rs/core/src/tools/spec_tests.rs` to use the `codex-tools` export
  instead of a core-local static
  - removed the old `PLAN_TOOL` definition from
  `codex-rs/core/src/tools/handlers/plan.rs`; the `PlanHandler` runtime
  logic still stays in `codex-core`
  - tightened two `codex-core` aliases to `#[cfg(test)]` now that
  production code no longer needs them
  
  ## Testing
  
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core tools::spec::tests`
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/16481).
  * #16482
  * __->__ #16481

  Michael Bolin · 2026-04-01 15:51:52 -07:00
  6cf832fc63
• Extract tool discovery helpers into codex-tools (#16477)

  ## Why
  
  Follow-up to #16379 and #16471.
  
  `codex-rs/core/src/tools/spec.rs` still owned the pure discovery-shaping
  helpers that turn app metadata and discoverable tool metadata into the
  inputs used by `tool_search` and `tool_suggest`. Those helpers do not
  need `codex-core` runtime state, so keeping them in `codex-core`
  continued to blur the crate boundary this migration is trying to
  tighten.
  
  This change keeps pushing spec-only logic behind the `codex-tools` API
  so `codex-core` can focus on wiring runtime handlers to the resulting
  tool definitions.
  
  ## What Changed
  
  - Added `collect_tool_search_app_infos` and
  `collect_tool_suggest_entries` to
  `codex-rs/tools/src/tool_discovery.rs`.
  - Added a small `ToolSearchAppSource` adapter type in `codex-tools` so
  `codex-core` can pass app metadata into that shared helper logic without
  exposing `ToolInfo` across the crate boundary.
  - Re-exported the new discovery helpers from
  `codex-rs/tools/src/lib.rs`, which remains exports-only.
  - Updated `codex-rs/core/src/tools/spec.rs` to use those `codex-tools`
  helpers instead of maintaining local `tool_search_app_infos` and
  `tool_suggest_entries` functions.
  - Removed the now-redundant helper implementations from `codex-core`.
  
  ## Testing
  
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core tools::spec::tests`

  Michael Bolin · 2026-04-01 14:41:20 -07:00
  1b711a5501
• 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`

  Michael Bolin · 2026-04-01 14:06:04 -07:00
  e6f5451a2c
• Extract tool config into codex-tools (#16379)

  ## Why
  
  `codex-core` already owns too much of the tool stack, and `AGENTS.md`
  explicitly pushes us to move shared code out of `codex-core` instead of
  letting it keep growing. This PR takes the next incremental step in
  moving `core/src/tools` toward `codex-rs/tools` by extracting
  low-coupling tool configuration and image-detail gating logic into
  `codex-tools`.
  
  That gives later extraction work a cleaner boundary to build on without
  trying to move the entire tools subtree in one shot.
  
  ## What changed
  
  - moved `ToolsConfig`, `ToolsConfigParams`, shell backend config, and
  unified-exec session selection from `core/src/tools/spec.rs` into
  `codex-tools`
  - moved original image-detail gating and normalization into
  `codex-tools`
  - updated `codex-core` to consume the new `codex-tools` exports and pass
  a rendered agent-type description instead of raw role config
  - kept `codex-rs/tools/src/lib.rs` exports-only, with extracted unit
  tests living in sibling `*_tests.rs` modules
  
  ## Testing
  
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core --lib tools::spec::`

  Michael Bolin · 2026-04-01 13:21:50 -07:00
  a99d4845e3
• codex-tools: extract discoverable tool models (#16254)

  ## Why
  
  `#16193` moved the pure `tool_search` and `tool_suggest` spec builders
  into `codex-tools`, but `codex-core` still owned the shared
  discoverable-tool model that those builders and the `tool_suggest`
  runtime both depend on. This change continues the migration by moving
  that reusable model boundary out of `codex-core` as well, so the
  discovery/suggestion stack uses one shared set of types and
  `core/src/tools` no longer needs its own `discoverable.rs` module.
  
  ## What changed
  
  - Moved `DiscoverableTool`, `DiscoverablePluginInfo`, and
  `filter_tool_suggest_discoverable_tools_for_client()` into
  `codex-rs/tools/src/tool_discovery.rs` alongside the extracted
  discovery/suggestion spec builders.
  - Added `codex-app-server-protocol` as a `codex-tools` dependency so the
  shared discoverable-tool model can own the connector-side `AppInfo`
  variant directly.
  - Updated `core/src/tools/handlers/tool_suggest.rs`,
  `core/src/tools/spec.rs`, `core/src/tools/router.rs`,
  `core/src/connectors.rs`, and `core/src/codex.rs` to consume the shared
  `codex-tools` model instead of the old core-local declarations.
  - Changed `core/src/plugins/discoverable.rs` to return
  `DiscoverablePluginInfo` directly, moved the pure client-filter coverage
  into `tool_discovery_tests.rs`, and deleted the old
  `core/src/tools/discoverable.rs` module.
  - Updated `codex-rs/tools/README.md` so the crate boundary documents
  that `codex-tools` now owns the discoverable-tool models in addition to
  the discovery/suggestion spec builders.
  
  ## Test plan
  
  - `cargo test -p codex-tools`
  - `CARGO_TARGET_DIR=/tmp/codex-core-discoverable-model cargo test -p
  codex-core --lib tools::handlers::tool_suggest::`
  - `CARGO_TARGET_DIR=/tmp/codex-core-discoverable-model cargo test -p
  codex-core --lib tools::spec::`
  - `CARGO_TARGET_DIR=/tmp/codex-core-discoverable-model cargo test -p
  codex-core --lib plugins::discoverable::`
  - `just bazel-lock-check`
  - `just argument-comment-lint`
  
  ## References
  
  - #16193
  - #16154
  - #15923
  - #15928
  - #15944
  - #15953
  - #16031
  - #16047
  - #16129
  - #16132
  - #16138
  - #16141

  Michael Bolin · 2026-03-30 10:48:49 -07:00
  258ba436f1
• codex-tools: extract discovery tool specs (#16193)

  ## Why
  
  `core/src/tools/spec.rs` still owned the pure `tool_search` and
  `tool_suggest` spec builders even though that logic no longer needed
  `codex-core` runtime state. This change continues the `codex-tools`
  migration by moving the reusable discovery and suggestion spec
  construction out of `codex-core` so `spec.rs` is left with the
  core-owned policy decisions about when these tools are exposed and what
  metadata is available.
  
  ## What changed
  
  - Added `codex-rs/tools/src/tool_discovery.rs` with the shared
  `tool_search` and `tool_suggest` spec builders, plus focused unit tests
  in `tool_discovery_tests.rs`.
  - Moved the shared `DiscoverableToolAction` and `DiscoverableToolType`
  declarations into `codex-tools` so the `tool_suggest` handler and the
  extracted spec builders use the same wire-model enums.
  - Updated `core/src/tools/spec.rs` to translate `ToolInfo` and
  `DiscoverableTool` values into neutral `codex-tools` inputs and delegate
  the actual spec building there.
  - Removed the old template-based description rendering helpers from
  `core/src/tools/spec.rs` and deleted the now-dead helper methods in
  `core/src/tools/discoverable.rs`.
  - Updated `codex-rs/tools/README.md` to document that discovery and
  suggestion models/spec builders now live in `codex-tools`.
  
  ## Test plan
  
  - `cargo test -p codex-tools`
  - `CARGO_TARGET_DIR=/tmp/codex-core-discovery-specs cargo test -p
  codex-core --lib tools::spec::`
  - `CARGO_TARGET_DIR=/tmp/codex-core-discovery-specs cargo test -p
  codex-core --lib tools::handlers::tool_suggest::`
  - `just argument-comment-lint`
  
  ## References
  
  - #16154
  - #15923
  - #15928
  - #15944
  - #15953
  - #16031
  - #16047
  - #16129
  - #16132
  - #16138
  - #16141

  Michael Bolin · 2026-03-30 08:15:12 -07:00
  716f7b0428
• codex-tools: extract utility tool specs (#16154)

  ## Why
  
  The previous `codex-tools` migration steps moved the shared schema
  models, local-host specs, collaboration specs, and related adapters out
  of `codex-core`, but `core/src/tools/spec.rs` still contained a grab bag
  of pure utility tool builders. Those specs do not need session state or
  handler logic; they only describe wire shapes for tools that
  `codex-core` already knows how to execute.
  
  Moving that remaining low-coupling layer into `codex-tools` keeps the
  migration moving in meaningful chunks and trims another large block of
  passive tool-spec construction out of `codex-core` without touching the
  runtime-coupled handlers.
  
  ## What changed
  
  - extended `codex-tools` to own the pure spec builders for:
    - code-mode `exec` / `wait`
    - `js_repl` / `js_repl_reset`
  - MCP resource tools `list_mcp_resources`,
  `list_mcp_resource_templates`, and `read_mcp_resource`
    - utility tools `list_dir` and `test_sync_tool`
  - split those builders across small module files with sibling
  `*_tests.rs` coverage, keeping `src/lib.rs` exports-only
  - rewired `core/src/tools/spec.rs` to call the extracted builders and
  deleted the duplicated core-local implementations
  - moved the direct JS REPL grammar seam test out of
  `core/src/tools/spec_tests.rs` so it now lives with the extracted
  implementation in `codex-tools`
  - updated `codex-rs/tools/README.md` so the documented crate boundary
  matches the new utility-spec surface
  
  ## Test plan
  
  - `CARGO_TARGET_DIR=/tmp/codex-tools-utility-specs cargo test -p
  codex-tools`
  - `CARGO_TARGET_DIR=/tmp/codex-core-utility-specs cargo test -p
  codex-core --lib tools::spec::`
  - `just fix -p codex-tools -p codex-core`
  - `just argument-comment-lint`
  
  ## References
  
  - #15923
  - #15928
  - #15944
  - #15953
  - #16031
  - #16047
  - #16129
  - #16132
  - #16138
  - #16141

  Michael Bolin · 2026-03-29 14:34:36 -07:00
  af568afdd5
• codex-tools: extract collaboration tool specs (#16141)

  ## Why
  
  The recent `codex-tools` migration steps have moved shared tool models
  and low-coupling spec helpers out of `codex-core`, but
  `core/src/tools/spec.rs` still owned a large block of pure
  collaboration-tool spec construction. Those builders do not need session
  state or runtime behavior; they only need a small amount of core-owned
  configuration injected at the seam.
  
  Moving that cohesive slice into `codex-tools` makes the crate boundary
  more honest and removes a substantial amount of passive tool-spec logic
  from `codex-core` without trying to move the runtime-coupled multi-agent
  handlers at the same time.
  
  ## What changed
  
  - added `agent_tool.rs`, `request_user_input_tool.rs`, and
  `agent_job_tool.rs` to `codex-tools`, with sibling `*_tests.rs` coverage
  and an exports-only `lib.rs`
  - moved the pure `ToolSpec` builders for:
  - collaboration tools such as `spawn_agent`, `send_input`,
  `send_message`, `assign_task`, `resume_agent`, `wait_agent`,
  `list_agents`, and `close_agent`
    - `request_user_input`
    - agent-job specs `spawn_agents_on_csv` and `report_agent_job_result`
  - rewired `core/src/tools/spec.rs` to call the extracted builders while
  still supplying the core-owned inputs, such as spawn-agent role
  descriptions and wait timeout bounds
  - updated the `core/src/tools/spec.rs` seam tests to build expected
  collaboration specs through `codex-tools`
  - updated `codex-rs/tools/README.md` so the crate documentation reflects
  the broader collaboration-tool boundary
  
  ## Test plan
  
  - `CARGO_TARGET_DIR=/tmp/codex-tools-collab-specs cargo test -p
  codex-tools`
  - `CARGO_TARGET_DIR=/tmp/codex-core-collab-specs cargo test -p
  codex-core --lib tools::spec::`
  - `just fix -p codex-tools -p codex-core`
  - `just argument-comment-lint`
  
  ## References
  
  - #15923
  - #15928
  - #15944
  - #15953
  - #16031
  - #16047
  - #16129
  - #16132
  - #16138

  Michael Bolin · 2026-03-28 20:39:47 -07:00
  7880414a27
• 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

  Michael Bolin · 2026-03-28 16:33:58 -07:00
  4e119a3b38
• codex-tools: extract code mode tool spec adapters (#16132)

  ## Why
  
  The longer-term `codex-tools` migration is to move pure tool-definition
  and tool-spec plumbing out of `codex-core` while leaving session- and
  runtime-coupled orchestration behind.
  
  The remaining code-mode adapter layer in
  `core/src/tools/code_mode_description.rs` was a good next extraction
  seam because it only transformed `ToolSpec` values for code mode and
  already delegated the low-level description rendering to
  `codex-code-mode`.
  
  ## What Changed
  
  - added `codex-rs/tools/src/code_mode.rs` with
  `augment_tool_spec_for_code_mode()` and
  `tool_spec_to_code_mode_tool_definition()`
  - added focused unit coverage in `codex-rs/tools/src/code_mode_tests.rs`
  - rewired `core/src/tools/spec.rs` and `core/src/tools/code_mode/mod.rs`
  to use the extracted adapters from `codex-tools`
  - removed the old `core/src/tools/code_mode_description.rs` shim and its
  test file from `codex-core`
  - added the `codex-code-mode` dependency to `codex-tools`, updated
  `Cargo.lock`, and refreshed the `codex-tools` README to reflect the
  expanded boundary
  
  ## Test Plan
  
  - `cargo test -p codex-tools`
  - `CARGO_TARGET_DIR=/tmp/codex-core-code-mode-adapters cargo test -p
  codex-core --lib tools::spec::`
  - `CARGO_TARGET_DIR=/tmp/codex-core-code-mode-adapters cargo test -p
  codex-core --lib tools::code_mode::`
  - `just bazel-lock-update`
  - `just bazel-lock-check`
  - `just argument-comment-lint`
  
  ## References
  
  - #15923
  - #15928
  - #15944
  - #15953
  - #16031
  - #16047
  - #16129

  Michael Bolin · 2026-03-28 15:32:35 -07:00
  2238c16a91