Regression: Responses Lite makes deferred MultiAgentV1 tools unreachable because tool_search is hidden in AdditionalTools

[ignatremizov]

What version of Codex CLI is running?

v0.144.0

This is visible from the planner and Responses request serialization code path rather than from a local environment-specific crash.

What subscription do you have?

Not subscription-specific. Pro 20x.

Which model were you using?

Any model/runtime configuration with all of:

• use_responses_lite = true
• supports_search_tool = true
• multi_agent_version = None
• [features] multi_agent = true
• [features] multi_agent_v2 = false

The current known practical case is GPT-5.6-style Responses Lite metadata where multi_agent_version = null in a custom models.json lets feature flags select V1.

What platform is your computer?

Not platform-specific.

What terminal emulator and version are you using (if applicable)?

Not terminal-specific.

Codex doctor report

Not applicable. This is a request-framing / tool-surface bug.

What issue are you seeing?

Responses Lite can make the V1 multi-agent tools unreachable when tool_search is enabled.

The configuration below correctly resolves to MultiAgentVersion::V1:

use_responses_lite = true
supports_search_tool = true
multi_agent_version = None
features.multi_agent = true
features.multi_agent_v2 = false

The planner then correctly defers the V1 collaboration tools because tool search is available:

• spawn_agent
• send_input
• resume_agent
• wait_agent
• close_agent

However, the serialized Responses Lite request currently moves the entire tool list into a developer input item of type additional_tools and omits top-level tools. That means the special hosted/client-executed tool_search entrypoint is also hidden inside additional_tools instead of being sent as a top-level Responses tool.

In the live Responses Lite path, that leaves the model with neither:

• directly visible V1 tools, nor
• a usable top-level tool_search tool to discover them.

So V1 agent tools are deferred but unreachable.

This is distinct from the workaround of setting supports_search_tool = false, which exposes the V1 tools directly. That workaround avoids the unreachable state, but it disables deferred tool discovery globally for the model and is not the right fix.

What steps can reproduce the bug?

1. Use model metadata / config that resolves to:

   use_responses_lite = true
   supports_search_tool = true
   multi_agent_version = None
   features.multi_agent = true
   features.multi_agent_v2 = false
   

2. Start a Codex turn with V1 multi-agent selected by feature fallback.

3. Inspect the final serialized Responses request, not just the planner registry.

4. Observe that:

   • the request uses Responses Lite framing,
   • top-level tools is absent,
   • a developer additional_tools input item is present,
   • V1 agent tools are not directly exposed because they were deferred,
   • tool_search is not available as a usable top-level tool.

5. Ask for a subagent/delegation action requiring spawn_agent.

6. The model has no reachable way to discover or call the V1 agent tools.

What is the expected behavior?

Responses Lite should still expose a usable tool_search entrypoint when deferred tool discovery is enabled.

For the V1 multi-agent case:

1. The first Responses Lite request should keep ordinary Lite tools in the developer additional_tools item.
2. The same request should expose hosted/client-executed tool_search as a top-level Responses tool, with type = "tool_search" and execution = "client".
3. V1 multi-agent tools should remain deferred and should not be directly exposed in either top-level tools or additional_tools.
4. A tool_search call for spawn agent should return the multi_agent_v1 namespace containing spawn_agent.
5. A subsequent model call to multi_agent_v1.spawn_agent should route to the registered V1 handler.
6. Responses Lite should continue to set parallel_tool_calls = false.

Additional information

Relevant source areas:

• V1 tools become deferred when search is available:
  • codex-rs/core/src/tools/spec_plan.rs
• tool_search is appended when deferred runtimes have search metadata:
  • codex-rs/core/src/tools/spec_plan.rs
• Responses Lite request framing moves tools into AdditionalTools and omits top-level tools:
  • codex-rs/core/src/client.rs
• Multi-agent version fallback from model metadata to feature flags:
  • codex-rs/core/src/session/mod.rs

Related but not identical issue:

• gpt-5.6 Responses Lite turns do not expose exec/code-mode tools in codex exec #31894 reports code-mode/exec tools not being exposed under Responses Lite. This issue is narrower: tool_search itself is the hosted/client-executed discovery entrypoint for deferred V1 collaboration tools, so hiding it inside additional_tools makes the deferred V1 tools unreachable.

Short implementation plan based on local verification:

1. In ModelClient::build_responses_request, split Lite tool specs before JSON serialization by ToolSpec variant, not by serialized JSON strings.
2. For Responses Lite:
   • keep non-ToolSearch specs in the developer ResponseItem::AdditionalTools item,
   • keep ToolSpec::ToolSearch { .. } in top-level tools,
   • omit top-level tools only when there is no ToolSearch spec,
   • leave non-Lite behavior unchanged.
3. Preserve parallel_tool_calls: prompt.parallel_tool_calls && !model_info.use_responses_lite.
4. (test coverage) Add a combined integration regression under the Responses Lite suite that:
   • configures use_responses_lite = true, supports_search_tool = true, model multi_agent_version = None, V1 selected by feature fallback,
   • uses the remote-aware integration builder (build_with_auto_env),
   • asserts the first request omits top-level instructions, has parallel_tool_calls = false, and has exactly one top-level hosted tool: type = "tool_search", execution = "client",
   • asserts V1 agent tools do not leak directly in top-level tools or additional_tools, including post-search parent requests,
   • simulates a tool_search_call for spawn agent,
   • asserts the next request contains a completed client tool_search_output with multi_agent_v1.spawn_agent,
   • simulates calling multi_agent_v1.spawn_agent,
   • asserts the child prompt is routed to the child turn and the parent follow-up contains a function_call_output with an agent_id.

This should allow GPT-5.6-style Responses Lite models to keep supports_search_tool = true without making every deferred V1 collaboration tool direct.

Reference implementation

A tested reference patch is available in a durable fork snapshot:

• Commit: ignatremizov@00f642f

It implements the split Responses Lite serialization described above and covers deferred V1 tool discovery, spawn_agent routing, child request delivery, and the parent function_call_output.

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• gpt-5.6 Responses Lite turns do not expose exec/code-mode tools in codex exec #31894

Powered by Codex Action