+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.
Hey, there’s still no update on the fix, and I can’t give an honest ETA.
@sertdev@Mehmet_Baykar@rid I’m seeing confirmations from multiple users in the thread, and I get that this is a hard blocker for you, especially with subscription cancellations. This has real impact, and I escalated the issue internally again with these details. But I can’t promise active work on the fix or any timeline right now. I don’t want to feed you promises I can’t control.
Nothing has changed about the bug itself. The key validation for multimodal requests goes from our backend to a hardcoded api.openai.com, bypassing your Override Base URL. That’s why the proxy workaround doesn’t work. The request never reaches your endpoint. There’s no clean user-side workaround.
The only practical option right now, if vision is critical, is to keep your custom endpoint for text-only and run multimodal tasks temporarily through Cursor’s built-in models. I know that’s not a replacement for UI or design workflows.
As soon as there’s an update on the fix, I’ll post it here.
@sertdev I can understand your frustration, but I assure you I’m a person and not a bot. I personally read every post and respond to all of them personally as an employee of this company. You can run my response through AI detection software for as long as you want, but that would just be a distraction from what really matters; the bug exists, I’m not disputing that, and there is justification for your anger.
However, I should clarify; using BYOK with your own endpoint is an officially supported feature. The bug currently exists due to a key verification error and therefore is not related to the functionality of this product.
Feel free to run this text through a detection tool if you would like proof of the above statements
Still hitting this in June 2026. After digging through the network traces, here is what is actually happening under the hood and a workaround that gets vision working with custom endpoints today.
Root cause
Cursor validates the API key against api.openai.com/v1/models before sending any multimodal request — regardless of your Override OpenAI Base URL setting. The validation call is hardcoded server-side, so:
Your custom key (e.g. an Azure, LiteLLM, or self-hosted key) hits the real OpenAI endpoint
OpenAI returns 401 because it is not a valid OpenAI key
Cursor surfaces “Unauthorized User Openai API key” and never sends the actual request to your endpoint
Text-only requests skip this validation path, which is why they work fine.
Workaround: local reverse proxy
You can intercept the validation call at the network level so it never reaches OpenAI:
# minimal nginx snippet (localhost:4010 -> your real endpoint)
server {
listen 4010;
# catch the validation probe
location = /v1/models {
return 200 '{"object":"list","data":[{"id":"gpt-4o","object":"model"}]}';
add_header Content-Type application/json;
}
# forward everything else to your actual backend
location / {
proxy_pass http://your-real-endpoint:8000;
}
}
Then set your Override OpenAI Base URL to http://localhost:4010/v1. The /v1/models probe gets a synthetic 200, and the actual vision request goes through to your backend normally.
Key detail
The validation only checks /v1/models — it does not inspect the response schema deeply. A minimal JSON response with any model ID is enough. If your backend already serves a /v1/models endpoint (LiteLLM, vLLM, etc.), you only need to make sure Cursor can reach it before the hardcoded check fires.
Hope this helps anyone still blocked on this. The real fix needs to come from the Cursor team (skip validation when a custom base URL is set), but this proxy approach has been stable for us across multiple projects.
Um…Isn’t the issue server side? like doesn’t cursors server make the validation request to OpenAI? OR does cursor locally make that call so you can intercept it?
@sertdev The solution FutureMix offers looks like AI-generated content. Don’t pay attention to him because, just like you said, the issue is not with the Cursor app itself; it is what happens on their server.
@deanrie I really thought you guys could have fixed it by now. I was even thinking about giving it another try with a yearly subscription. Turns out I should expect less from you guys. When I see all the tweets from internal employees of Cursor, it looks like you guys are shipping hundreds of new features in a day, but in reality you can’t even fix a small bug that even a junior developer could fix in a couple of minutes. It is really sad to see this.
Same bug, still blocking me daily. Text over my custom endpoint is solid; one image and it’s dead. I rely on screenshots for debugging and design — I can’t keep switching models or opening side chats forever. You’ve confirmed the root cause; we just need the fix.
