fix handling of ResponseApplyPatchToolCall in completion bridge

[jtsaw]

Relevant issues

Fixes #20905

CI failures seem unrelated to my changes..

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

• I have Added testing in the tests/litellm/ directory, Adding at least 1 test is a hard requirement - see details
• My PR passes all unit tests on make test-unit
• My PR's scope is as isolated as possible, it only solves 1 specific problem

CI (LiteLLM team)

CI status guideline:

• 50-55 passing tests: main is stable with minor issues.
• 45-49 passing tests: acceptable but needs attention
• <= 40 passing tests: unstable; be careful with your merges and assess the risk.

• Branch creation CI run
  Link:

• CI run for the last commit
  Link:

• Merge / cherry-pick CI run
  Links:

Type

🆕 New Feature
🐛 Bug Fix
🧹 Refactoring
📖 Documentation
🚄 Infrastructure
✅ Test

Changes

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
litellm	Ready	Preview, Comment	Feb 13, 2026 1:33am

[greptile-apps]

Greptile Overview

Greptile Summary

Fixes a bug where litellm.completion() with a responses/ model prefix crashed when the model returned apply_patch_call output items (e.g., from GPT-5 Codex). The bridge now handles ResponseApplyPatchToolCall by converting it to a ChatCompletions-style tool call with name="apply_patch" and the file operation serialized as JSON in function.arguments.

• Added ResponseApplyPatchToolCall handling in _convert_response_output_to_choices following the existing ResponseFunctionToolCall pattern
• Added a regression test that verifies the tool call conversion end-to-end using mocks

Confidence Score: 4/5

• This PR is safe to merge — it adds a new elif branch with no impact on existing code paths.
• The change is a straightforward addition of a new elif branch in an existing type-dispatch chain. It follows the established pattern exactly, uses json.dumps (already imported), and the test is comprehensive and mock-only. The only reason this isn't a 5 is that the apply_patch function name is hardcoded rather than derived from the item type, which could diverge from OpenAI's naming if it changes — though this is a minor concern.
• No files require special attention.

Important Files Changed

Filename	Overview
litellm/completion_extras/litellm_responses_transformation/transformation.py	Adds handling for ResponseApplyPatchToolCall in _convert_response_output_to_choices, converting it to a ChatCompletions-style tool call with name="apply_patch" and the operation serialized as JSON. Clean implementation following the existing pattern for ResponseFunctionToolCall. Minor whitespace cleanup.
tests/test_litellm/completion_extras/litellm_responses_transformation/test_completion_extras_litellm_responses_transformation_transformation.py	Adds a comprehensive regression test for the ResponseApplyPatchToolCall conversion. Uses only mocks — no real network calls. Verifies the tool call structure, operation serialization, and finish reason. Also includes minor whitespace normalization in existing tests.

[greptile-apps]

_{2 files reviewed, no comments}

_{Edit Code Review Agent Settings | Greptile}

[yuneng-jiang]

@Sameerlite can you take a look at this when you get a chance?

[Sameerlite]

nit

[Sameerlite]

Add this in as a method in LiteLLMCompletionResponsesConfig and use it here.

[jtsaw]

addressed @Sameerlite

[ghost]

@jtsaw can you fix the linting error?

[jtsaw]

@jtsaw can you fix the linting error?

actually I'm not sure how to fix these lint errors...

• the completion_extras/litellm_responses_transformation/transformation.py:230:9: PLR0915 Too many statements (60 > 50) seems to be in all new PRs and is unrelated to my changes
• the proxy/_experimental/mcp_server/mcp_server_manager.py:34:31: F401 [*] litellm.constants.MCP_NPM_CACHE_DIR imported but unused is also unrelated since that file is not modified here.

@krrishdholakia