[Bug] Azure OpenAI BYOK Agent fails with response.failed, error: null on GPT-5.4 and GPT-5.6

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor Agent intermittently fails when using Azure OpenAI BYOK with GPT-5 models.

The request reaches Azure and a Responses API response object is created, but Azure returns:

{
“type”: “response.failed”,
“response”: {
“status”: “failed”,
“error”: null,
“output”: ,
“model”: “gpt-5.4”
}
}

Cursor then surfaces the failure as:

[invalid_argument] Error
RetriableError: [invalid_argument] Error

The error occurs during an Agent session, commonly when Cursor resumes after one or more tool calls.

I previously reproduced the same failure structure with gpt-5.6-luna.

Steps to Reproduce

Cursor Request ID:

dfe39e34-3806-416f-8e2f-f2ad2cb4d7c5

Azure response ID:

resp_08a276285ce7059a016a6841d4a48c81948b35ec3616f6aeea

Model:

gpt-5.4

Relevant response:

{
“type”: “response.failed”,
“response”: {
“status”: “failed”,
“error”: null,
“incomplete_details”: null,
“output”: ,
“model”: “gpt-5.4”,
“parallel_tool_calls”: true,
“reasoning”: {
“context”: “all_turns”,
“effort”: “high”,
“mode”: “standard”,
“summary”: “detailed”
},
“store”: false,
“tool_choice”: “auto”
}
}

Cursor stack includes:

Object.classify
runWithSharedTurnRunner
AgentLoop.resume
streamFromAgentBackend
getAgentStreamResponse
Additional reproductions

The same failure structure occurred with gpt-5.6-luna:

Cursor Request ID:
845d7e31-7c3b-479c-a431-cc42bab7dfd9

Cursor Request ID:
12551b4e-6f31-4436-983d-1ae46b7e6a69

Cursor Request ID:
967c4abe-b298-4c0a-8668-29ef6d4c885f

In each case:

{
“status”: “failed”,
“error”: null,
“output”:
}

Cursor converted the provider failure into:

RetriableError: [invalid_argument] Error

Steps to reproduce
Configure an Azure OpenAI API key in Cursor.
Configure the Azure OpenAI-compatible v1 endpoint:
https://.cognitiveservices.azure.com/openai/v1/
Select an Azure deployment using GPT-5.4 or GPT-5.6 Luna.
Start an Agent conversation in a code repository.
Ask the Agent to inspect files and perform a coding task involving tool calls.
Continue the session for multiple Agent/tool-call turns.
Cursor eventually stops with invalid_argument, while the underlying provider response is response.failed with error: null.

Expected Behavior

Cursor should complete the Agent request successfully.

When Azure returns a failed Responses API object, Cursor should also surface the underlying provider response and useful diagnostic information rather than classifying it only as invalid_argument.

Operating System

Linux

Version Information

Version: 3.13.21
VS Code Extension API: 1.128.0
Commit: 55434bd8062ece6fee083b82beed2aee42d253f0
Date: 2026-07-27T03:26:14.573Z
Layout: IDE
Build Type: Stable
Release Track: Nightly
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Darwin arm64 25.5.0

For AI issues: which model did you use?

gpt-5.4
gpt-5.6-luna

For AI issues: add Request ID with privacy disabled

Cursor Request ID: 845d7e31-7c3b-479c-a431-cc42bab7dfd9 Cursor Request ID: 12551b4e-6f31-4436-983d-1ae46b7e6a69 Cursor Request ID: 967c4abe-b298-4c0a-8668-29ef6d4c885f

Cursor Request ID:

dfe39e34-3806-416f-8e2f-f2ad2cb4d7c5

Azure response ID:

resp_08a276285ce7059a016a6841d4a48c81948b35ec3616f6aeea

Does this stop you from using Cursor

Yes - Cursor is unusable

5

Hey, thanks for the detailed report. The request IDs and the Azure response body helped a lot, I figured it out quickly.

There are two separate things here:

  1. The failure itself. It’s intermittent on Azure’s side. Azure returns a valid response.failed with error: null and output: [], meaning the provider doesn’t explain why the request failed. This often happens mid-turn after successful tool calls, exactly like you described. We can’t prevent this, the root cause is on the provider side.

  2. How Cursor handles it. This is on our side, and it’s a real issue:

  • A response.failed like this with error: null gets misclassified as a client error and shows up as [invalid_argument], even though your arguments aren’t the problem.
  • The retry that likely would’ve succeeded, since nearby steps in the same session worked, gets skipped.
  • The provider response body isn’t passed through to you, even though that’s what you asked to see.

I’ve logged all three points with the team. I can’t share an ETA yet, but I can confirm we’ve recognized this as a bug on our side.

As a temporary workaround until it’s fixed, just retry the request when this happens. A retry in the same session usually works. Or, on unstable parts, switch to a non-BYOK model. Let me know if you notice a pattern that’s different from what I described.