Fix/21193 chatgpt codex unsupported params

[jayy-77]

Summary
Fixes ChatGPT Codex (chatgpt/gpt-5.2-codex, etc.) failures where the Responses API bridge forwards unsupported params (like user, temperature, context_management) and the API rejects the request.

What changed
Updated ChatGPTResponsesAPIConfig.transform_responses_api_request() to use an allowlist of supported Responses API keys and drop everything else.
Keeps required ChatGPT defaults (streaming enabled + reasoning.encrypted_content included).

Why this works
Codex’s Responses endpoint is strict about accepted parameters. By only sending known-supported keys, we prevent “Unsupported parameter: …” errors without needing to chase every new unsupported param via pop().

Tests
Added/updated unit test in tests/test_litellm/llms/chatgpt/responses/test_chatgpt_responses_transformation.py to assert unsupported keys are removed and supported keys remain.

Fixes #21193

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
litellm	Error		Feb 14, 2026 6:49pm

[greptile-apps]

Greptile Overview

Greptile Summary

This PR fixes ChatGPT Codex (e.g., chatgpt/gpt-5.2-codex) failures caused by the Responses API bridge forwarding unsupported parameters like user, temperature, and context_management, which Codex's strict endpoint rejects.

• Replaces the previous approach of individually pop()-ing known-unsupported keys with a cleaner allowlist pattern in ChatGPTResponsesAPIConfig.transform_responses_api_request(), keeping only params confirmed to be accepted by the ChatGPT Responses API (model, input, instructions, stream, store, include, tools, tool_choice, reasoning, previous_response_id, truncation).
• Adds a unit test (test_chatgpt_drops_unsupported_responses_params) that verifies unsupported keys are stripped and supported keys are preserved; the test is mock-safe with no real network calls.
• The allowlist approach is more maintainable than the previous denylist but introduces a maintenance surface: new ChatGPT-supported params will need to be added to the allowlist. The parent class's get_supported_openai_params() is not overridden to reflect the reduced param set, so callers may believe more params are supported than actually pass through.

Confidence Score: 4/5

• This PR is safe to merge — it narrows outgoing request params for a specific provider endpoint, reducing errors without affecting other code paths.
• Score reflects that the change is well-scoped, provider-specific, and includes passing tests. Deducted 1 point because the parent class's get_supported_openai_params is not overridden to match the allowlist, creating an inconsistency where callers are told params are supported when they'll actually be silently dropped.
• litellm/llms/chatgpt/responses/transformation.py — consider overriding get_supported_openai_params to align with the allowlist.

Important Files Changed

Filename	Overview
litellm/llms/chatgpt/responses/transformation.py	Replaces individual pop() calls with an allowlist filter for ChatGPT Codex Responses API params. Clean approach, but the parent's get_supported_openai_params is not overridden to match the actual allowed set.
tests/test_litellm/llms/chatgpt/responses/test_chatgpt_responses_transformation.py	Adds a comprehensive unit test validating that unsupported params are dropped and supported params are preserved. No network calls; mock-safe.

Flowchart

flowchart TD
    A[User calls litellm.responses\nwith ChatGPT Codex model] --> B[OpenAIResponsesAPIConfig\n.transform_responses_api_request]
    B --> C[Returns full request dict\nwith all optional params]
    C --> D[ChatGPTResponsesAPIConfig\n.transform_responses_api_request]
    D --> E[Prepend default instructions\nForce stream=True, store=False\nAdd reasoning.encrypted_content]
    E --> F{Filter through\nallowed_keys set}
    F -->|Allowed| G[model, input, instructions,\nstream, store, include,\ntools, tool_choice, reasoning,\nprevious_response_id, truncation]
    F -->|Dropped| H[user, temperature, top_p,\ncontext_management, metadata,\nmax_output_tokens, stream_options, etc.]
    G --> I[Send filtered request\nto ChatGPT Responses API]

Loading

_{Last reviewed commit: cf94802}

[greptile-apps]

_{2 files reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

Allowlist may silently drop valid future parameters

The allowlist approach is a sound improvement over the previous pop() pattern, but it has a maintainability trade-off: any new parameter that ChatGPT's Responses API starts supporting in the future will be silently dropped until this allowlist is updated. Consider adding a code comment noting this so future developers know to update allowed_keys when the ChatGPT Responses API evolves.

Additionally, the parent class's get_supported_openai_params() is not overridden in ChatGPTResponsesAPIConfig, so it still advertises all OpenAI Responses API params as "supported" even though they'll be stripped here. Overriding get_supported_openai_params to return only the allowed keys would give callers accurate information about what's actually supported and enable LiteLLM's drop_params logic to surface warnings when unsupported params are provided.

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}