Built-in `apply_patch` tool stops being recognized when sent together with a custom tool

Question

We are seeing what looks like a regression in Azure OpenAI model tool handling starting on Friday, March 13, 2026.

We use OpenAI models in production with built-in tools such as apply_patch. This had been working correctly for weeks using the documented tool format. Starting on March 13, apply_patch stopped being recognized in a specific and reproducible case.

What we observed

If we send:

the built-in tool apply_patch, and
any custom tool

in the same request, the model behaves as if apply_patch is not available.

But if we send only apply_patch, the model recognizes it and uses it correctly.

Expected behavior

If apply_patch is included correctly in the request, the model should still recognize and use it even when custom tools are also present.

Actual behavior

When apply_patch is combined with a custom tool, the model says it does not have access to a writing/editing tool, or otherwise does not call apply_patch.

When the same request is sent with only apply_patch, it works as expected.

Simple repro

Send a request to an Azure OpenAI model.
Include two tools:
- built-in: apply_patch
- one custom tool
Ask the model to make a code change.
The model responds as if it has no code-writing/editing tool.

Then repeat the same request with only:

built-in: apply_patch

In that case, the model correctly calls apply_patch.

Models affected

We have reproduced this with multiple GPT models, including:

gpt-5.3-codex
gpt-5.4
gpt-5.4-mini

Question

Has anyone else seen this behavior on Azure OpenAI?

More specifically:

Is this a known issue?
Did anything change around March 13, 2026 in how built-in tools are exposed when custom tools are also present?
Is there any documented workaround for using apply_patch together with custom tools in the same request?

At the moment, this is affecting our production workflow because apply_patch is the code-editing tool we rely on.

If useful, I can also post a minimal repro payload.

Answer

Please 'Upvote'(Thumbs-up) and 'Accept' as answer if the reply was helpful. This will be benefitting other community members who face the same issue.Hello Jhonatan Oliveira,

Welcome to Microsoft Q&A and Thank you for reaching out.

Thank you for sharing the detailed scenario and reproduction steps.

When multiple tools are made available in a single request, the model may prioritize tool selection differently depending on the request context. In scenarios that involve file or code edits, keeping the request scope narrow has shown more predictable results.

The below suggested workarounds are based on the practical steps to maintain stable workflows which focus on reducing ambiguity in tool selection and preserving continuity in code-editing workflows, based on current tool-enabled request behaviour.

Consider separating code editing and custom tool usage into distinct requests to maintain consistent behaviour.

Use one request that includes only the built‑in apply_patch tool when code changes are required
Then perform all file creation, updates, or deletions within this request
Send a follow‑up request for any custom tool execution, after code edits are completed
This separation helps ensure the editing tool is clearly available for code‑related tasks.

2.Please keep the code‑editing requests scoped only to apply_patch for requests that involve modifying files.Include only the apply_patch built‑in tool while excluding the custom or function‑based tools.This allows the model to focus solely on generating structured diffs.This minimizes tool selection ambiguity during edit operations.

3. As a general best practice, please confirm whether the requests are sent using a currently supported GA API version.

Please avoid using deprecated or preview API versions
Consider aligning requests with the versions listed in the official API lifecycle documentation to ensure compatibility with the latest supported features.

4. As a validation step verify tool declaration structure follows the documented schema.

Please Declare built‑in and custom tools using the standard tools array
Please avoid mixing legacy function formats with newer tool definitions
Please avoid forcing tool selection during mixed‑tool testing
This helps rule out payload inconsistencies during troubleshooting.

References:

Thank you!

Please 'Upvote'(Thumbs-up) and 'Accept' as answer if the reply was helpful. This will be benefitting other community members who face the same issue.

Answer

apply_patch is a built-in tool in the Azure AI Agent/Agent Server OpenAI-compatible stack that allows the assistant to create, delete, or update files using unified diffs. It is represented in the SDK by the ApplyPatchTool model and the corresponding tool call result type ResponseApplyPatchToolCall. There is also a ToolChoiceApplyPatch helper that forces the model to call this tool when executing a tool call.

From the available information, there is no documented change or known issue in the referenced documentation about apply_patch becoming unavailable when combined with custom tools, nor any date-specific behavioral change.

Given the behavior described (the model ignoring apply_patch when other tools are present), the only supported and documented lever in this context is to explicitly force the model to use the apply_patch tool via the ToolChoiceApplyPatch configuration when constructing the request. This ensures that, regardless of other tools present, the model is required to call apply_patch for the operation:

Use ToolChoiceApplyPatch to force the model to call the apply_patch tool when executing a tool call.
Ensure the ApplyPatchTool is correctly defined in the tools list for the request.
Handle the response using ResponseApplyPatchToolCall, which represents a tool call that applies file diffs by creating, deleting, or updating files.

If the issue persists even when ToolChoiceApplyPatch is used correctly, this would need to be treated as a service-side regression and escalated through Azure Support or the service’s support channels, as there is no additional documented workaround in the provided material beyond explicitly forcing the tool choice.