+1 Same issue with Azure OpenAI — still broken as of Cursor 0.50.x (May 2026)
I’m hitting the exact same bug. My setup:
Azure OpenAI enabled in Settings → Models
Base URL: Custom Azure proxy endpoint (https://fintopia-none-cf.xxx)
Deployment Name:gpt-5.5
API Key: Valid Azure API key
What works: Text-only conversations go through my Azure endpoint perfectly fine. No issues at all.
What breaks: The moment I attach an image, the request fails immediately with:
Invalid API key.
Unauthorized User Openai API key
Request ID: 264c0bea-337f-4923-b17b-a5dcdb030621
The error explicitly says “Openai API key” — not “Azure API key” — which confirms the hardcoded api.openai.com validation issue that @deanrie identified. Cursor is sending my Azure key to OpenAI’s endpoint for validation instead of routing through my configured Azure Base URL.
Stack trace from dev console points to the same code path:
at cVy (workbench.desktop.main.js:29387:25237)
→ runAgentLoop → streamFromAgentBackend → getAgentStreamResponse
This is a significant blocker for enterprise teams using Azure OpenAI. We chose Azure specifically for compliance and data residency requirements — telling us to “also configure an OpenAI key” defeats the entire purpose of Azure integration.
It’s been 9+ months since this was first reported and 25+ days since official confirmation. Can the team please share a concrete ETA? This is a straightforward routing bug (multimodal requests bypassing the Base URL override) and should not take this long to patch.
For now, I’m forced to switch to Cursor’s built-in models every time I need to share a screenshot — which in a UI-heavy project is essentially all the time.
Hey @leomh, thanks for the detailed report and the Request ID. Confirming this is the same root cause. The Azure path still goes through the same multimodal validation, which ignores your Base URL override, so the symptom is identical even though the backend is different. It’s the same part of the code that @nunesmatheus saw with @Browser.
I don’t have an ETA for a fix yet, and on the user side I still can’t suggest a workaround. As soon as we have something concrete, we’ll post an update here.
Good luck with getting an ETA or a solution from Cursor. I have been trying to point this out almost a month and I only recieved “no ETA for the fix.” “no updates on the fix yet” from them. Better to use codex or claude rather than cursor right now.
I am cancelling my and my team’s subscription this is really stopping our use case.
it does not much fix a hardcoded string bug fix, even a 3 months ETA was fine with me, but no updates or ETA for months is infuriating. Switching out to Zed now
I even built and open-sourced Cursor-OpenAI-BYOK-Bridge to work around Cursor’s OpenAI-compatible BYOK issue where Agent requests are sent to /v1/chat/completions, but the payload is closer to the Responses API format. The bridge translates those requests to the Responses API upstream and converts the response back into Chat Completions format, which makes GPT-5-class models and OpenAI-compatible gateways usable in Cursor again.
That workaround works for normal text requests. But I did not expect to hit an even more frustrating issue when attaching an image: the request does not even reach my bridge. Based on my bridge logs, text requests go through fine, while image requests appear to bypass the configured custom endpoint entirely and then fail with Unauthorized User Openai API key.
At that point there is nothing I can fix at the bridge layer, because Cursor never sends the request to it.
This seems like a basic routing bug, and it affects a pretty important workflow. Could the Cursor team please prioritize this and fix it?
@xiatian11, thanks for the detailed report and for sharing the bridge project. Confirmed, it’s the same root issue that’s being discussed in this thread. Multimodal requests don’t even reach your bridge because the key validation goes from our backend directly to api.openai.com, bypassing the Base URL override. There’s no way to fix this on the user or proxy side.
@Alex-John I get the frustration. Honestly, there’s no update on a fix yet, and I can’t give an ETA. What I can do right now is highlight the signal internally again: 9+ confirmations in this thread, plus separate cases for Azure, vLLM, LiteLLM, and custom bridges. That’s solid data that helps with prioritization, even if I can’t promise a timeline.
There’s still no user-side workaround. If vision is critical right now, use Cursor’s built-in models for multimodal, and keep your custom endpoint for text tasks. I know that’s not a full solution for UI and design workflows.
As soon as there’s something real on the fix, I’ll reply here.
Hey @sertdev, I’ve added you to the confirmations list. Honestly, there’s still no fix and I can’t share an ETA. There’s also no user-side workaround yet. The key validation goes straight from our backend to api.openai.com, skipping the Base URL override, so proxies or bridges won’t intercept it.
I won’t recommend IDE alternatives, that’s up to you. The only stopgap inside Cursor is to use the built-in models for multimodal requests, and keep the custom endpoint for text tasks. For UI and design this is a partial solution, I get it.
I’ll escalate the impact again internally with these new confirmations. As soon as I have anything concrete on a fix, I’ll reply in the thread.
@deanrie Brother, this thing has been dragging for months and months now and the best responses we got were, “we’re escalating this internally.” This is just unacceptable behavior. I get that there are a lots and lots of bugs to go through for the Team, but i’d say this bug specifically is a hard blocker for almost all power users, furthermore, i believe they’ve been given enough time to LITERALLY just do acknowledge the custom base url override. Like it literally can not be that hard to fix, atmost should be 5-8 lines of code fix, and if it’s not that easy, the ■■■■ are you guys doing?
