[Bug] use_chat_completions_api bridge: allowed_openai_params not forwarded + namespace/tool_search tools dropped

[W0921]

Bug Description

When using use_chat_completions_api: true to bridge /v1/responses → /v1/chat/completions, two issues cause failures with clients like Codex desktop that send Responses API requests with reasoning_effort and non-standard tool types.

Issue 1: allowed_openai_params not forwarded through the bridge path

When a model is configured with use_chat_completions_api: true and allowed_openai_params: ["reasoning_effort"], the allowed_openai_params is not forwarded from litellm.aresponses() to the underlying litellm.acompletion() call in the chat completions bridge path.

Root cause: In responses/main.py, allowed_openai_params is an explicit named parameter of the responses() / aresponses() function. When the bridge path calls litellm_completion_transformation_handler.response_api_handler(), it passes **kwargs — but allowed_openai_params has already been extracted as a named parameter and is not in kwargs. The handler then calls litellm.acompletion(**acompletion_args) without allowed_openai_params, causing UnsupportedParamsError.

Trace:

litellm.UnsupportedParamsError: openai does not support parameters: [reasoning_effort], for model=EB-GLM-5.2

Code path:

1. responses/main.py line ~1083: calls response_api_handler(... **kwargs) — allowed_openai_params is NOT in kwargs (it is a named param of responses())
2. handler.py async_response_api_handler: builds acompletion_args from kwargs — no allowed_openai_params
3. litellm.acompletion(**acompletion_args) — fails with UnsupportedParamsError

Fix applied (local patch):

• responses/main.py: explicitly pass allowed_openai_params=allowed_openai_params to the response_api_handler() call
• handler.py: read allowed_openai_params from kwargs and forward to litellm.acompletion() / litellm.completion()

Issue 2: namespace and tool_search tool types silently dropped

In transformation.py, the transform_responses_api_tools_to_chat_completion_tools() method handles tool conversion. The else branch drops namespace and tool_search types (and passes through unknown types verbatim, causing upstream 400 errors).

namespace tools contain sub-tools (all function type) that should be expanded into the flat tool list. Dropping them loses functionality (e.g., Codex sends collaboration namespace with 6 function tools for sub-agent management, and codex_app namespace with 3 function tools).

tool_search tools have description and parameters fields and can be converted to a function type tool. Dropping them loses tool discovery capability.

Error when tool_search is passed through verbatim (before any fix):

BadRequestError: OpenAIException - {"error":{"message":"name is a required property - tools.11.function","type":"invalid_request_error"}}

Fix applied (local patch):

• namespace: recursively expand sub-tools via transform_responses_api_tools_to_chat_completion_tools()
• tool_search: convert to function type with name="tool_search", description and parameters from original tool
• Only truly unsupported types (computer_use, image_generation, shell) are still dropped

Environment

LiteLLM version: 1.95.0 (dev)
Python: 3.13
Deployment: Docker (docker-compose)

Model config (stored in DB via STORE_MODEL_IN_DB=True)

{
  "model_name": "GLM-5.2",
  "litellm_params": {
    "custom_llm_provider": "openai",
    "litellm_credential_name": "Hik",
    "model": "EB-GLM-5.2",
    "use_chat_completions_api": true,
    "allowed_openai_params": ["reasoning_effort"]
  }
}

The upstream provider supports /v1/chat/completions with reasoning_effort but does NOT support /v1/responses natively, hence use_chat_completions_api: true.

Reproduction

curl -X POST http://localhost:4000/v1/responses \
  -H "Authorization: Bearer sk-1234" \
  -H "Content-Type: application/json" \
  -d {

[devin-ai-integration]

Reopening for issue 2. #35885 landed the allowed_openai_params forwarding from issue 1 and auto-closed this, but the tool handling is still open. #36253 covers the namespace half by expanding nested tools instead of dropping the container. tool_search is left alone on purpose: it is a server side Responses tool, so converting it into a function tool would have the model emit calls the client never meant to answer, and #33783 already drops it for chat only providers

[claell]

Status update from LiteLLM 1.97.0 with a check against the current release tags, since both halves of this issue are now fixed upstream but the issue (and PR #36253) are still open:

Issue 1 (allowed_openai_params forwarding) — no longer reproduces on 1.97.0 when passed to litellm.aresponses() with use_chat_completions_api=True: with allowed_openai_params=["reasoning_effort"] the bridged request goes through; without it we get the same UnsupportedParamsError: openai does not support parameters: ['reasoning_effort'] from the report. Confirms #35885 landed as intended.

Issue 2 (namespace/tool handling) — on 1.97.0 namespaces are still dropped with the Dropping Responses API tool of type 'namespace' warning, and for agent clients that is a worse failure mode than a hard error: the model silently acts as if the tools do not exist while the client keeps invoking them. However, checking the release tags: LiteLLMCompletionResponsesConfig._namespace_chat_tools — flattening namespace containers into their nested function tools, with a top-level/namespace name-conflict guard — is present in the v1.98.0 tag and absent in v1.97.0. It landed via #32536 (merged 2026-08-12), not via #36253, which is still open and looks superseded.

For anyone on a chat-completions-only upstream who wants full Codex CLI coverage: on 1.97.0 everything else already works end-to-end for us — custom/freeform tools round-trip (custom definition → function call → custom_tool_call item, 4/4 over repeated runs, including custom_tool_call/custom_tool_call_output history replay), and the cached web_search shape (external_web_access: false) is accepted. The namespace expansion in 1.98.0 closes the last gap we are aware of. Unless there is a namespace case the flattening does not cover, this issue looks closable, and #36253 probably duplicates what already shipped.