Cursor 3.9.21 cannot use Windows Integrated Proxy (Kerberos/NTLM) after update

Support Bug Reports
, ,
1

Hi Cursor team,

After updating to Cursor 3.9.21, Cursor no longer works on our corporate network.

Environment:

  • Cursor: 3.9.21 Stable
  • Electron: 40.10.3
  • Node: 24.15.0
  • Windows 11 24H2
  • Corporate Squid Proxy with Windows Integrated Authentication (Kerberos / Negotiate)

Behavior:

  • Cursor AI fails.
  • Network Diagnostics reports:
    ERR_NAME_RESOLUTION_FAILED
    getaddrinfo EAI_AGAIN api2.cursor.sh

However the network itself is working correctly.

Evidence:

  1. curl succeeds using Kerberos authentication

curl --proxy-negotiate -u :
–proxy http://proxy01.sqb.uz:808

https://api2.cursor.sh

Result:

HTTP/1.1 200 Connection established
HTTP/1.1 200 OK
Welcome to Cursor…

  1. Kerberos tickets exist

klist shows valid tickets including

HTTP/proxy01.sqb.uz

  1. Browser works on Wi-Fi.

  2. Cursor works perfectly on Wi-Fi.

  3. Cursor fails only on Ethernet (corporate proxy).

  4. Cursor logs show

ERR_NAME_NOT_RESOLVED
getaddrinfo EAI_AGAIN api2.cursor.sh

The application appears to bypass the authenticated proxy and tries local DNS resolution instead.

The issue started immediately after upgrading to Cursor 3.9.21.

Could you please verify whether Electron 40 / Node 24 introduced a regression in Windows Integrated Proxy (Negotiate / Kerberos) support?

I can provide additional logs if necessary.

Thank you.

2

Hi there!

We detected that this may be a bug report, so we’ve moved your post to the Bug Reports category.

To help us investigate and fix this faster, could you edit your original post to include the details from the template below?

Bug Report Template - Click to expand

Where does the bug appear (feature/product)?

  • Cursor IDE
  • Cursor CLI
  • Background Agent (GitHub, Slack, Web, Linear)
  • BugBot
  • Somewhere else…

Describe the Bug
A clear and concise description of what the bug is.

Steps to Reproduce
How can you reproduce this bug? We have a much better chance at fixing issues if we can reproduce them!

  1. …
  2. …
  3. …

Expected Behavior
What is meant to happen here that isn’t working correctly?

Screenshots / Screen Recordings
If applicable, attach images or videos (.jpg, .png, .gif, .mp4, .mov)

Operating System

  • Windows 10/11
  • MacOS
  • Linux

Version Information

  • For Cursor IDE: Menu → About Cursor → Copy
  • For Cursor CLI: Run agent about in your terminal
IDE:
Version: 2.xx.x
VSCode Version: 1.105.1
Commit: ......

CLI:
CLI Version 2026.01.17-d239e66

For AI issues: which model did you use?
Model name (e.g., Sonnet 4, Tab…)

For AI issues: add Request ID with privacy disabled
Request ID: f9a7046a-279b-47e5-ab48-6e8dc12daba1
For Background Agent issues, also post the ID: bc-…

Additional Information
Add any other context about the problem here.

Does this stop you from using Cursor?

  • Yes - Cursor is unusable
  • Sometimes - I can sometimes use Cursor
  • No - Cursor works, but with this issue

The more details you provide, the easier it is for us to reproduce and fix the issue. Thanks!

6

Hey, thanks for the detailed report. The log, curl, and klist really help.

This looks like a known issue in 3.9.x. The HTTP/2 transport doesn’t go through the system HTTP proxy on Windows, so Cursor falls back to local DNS resolving instead of using the authenticated proxy. That’s why curl through the proxy returns 200, but Cursor fails with EAI_AGAIN. I’ve reported your case internally, but I can’t share an ETA for a fix yet.

As a temporary workaround, try disabling HTTP/2:

  • App Settings Ctrl+Shift+, then search for HTTP/2 and enable Disable HTTP/2
  • Or add this to settings.json: "cursor.general.disableHttp2": true

After that, restart Cursor and run Cursor Settings > Network > Run Diagnostics on Ethernet again. Let me know if it helps. If not, I’ll share the next steps.

7

Hi Dean,

I tested the workaround.

I added:

  • cursor.general.disableHttp2 = true
  • http.proxy
  • http.proxySupport = override
  • http.proxyStrictSSL = false

Then I completely exited Cursor (verified no Cursor.exe process remained) and started it again.

Unfortunately the issue is unchanged.

Network Diagnostics still reports:

  • ERR_NAME_RESOLUTION_FAILED
  • getaddrinfo EAI_AGAIN

Additional information:

  • Cursor 3.1.15 works perfectly on the same machine and same corporate Ethernet.
  • Cursor 3.9.21 fails.
  • curl with Kerberos/Negotiate through our corporate proxy returns HTTP 200 OK.
  • Kerberos tickets are present (verified with klist).
  • The problem only occurs on the corporate proxy. Wi-Fi works normally.

Please let me know the next troubleshooting steps.

Thanks!

8

Thanks for trying the workaround and sharing the results. The fact that nothing changed even with disableHttp2: true, all the proxy settings, and a full restart is unfortunately expected for some setups.

This is the same known 3.9.x regression discussed here: [Bug] always-local-singleton ignores http.proxy and server overrides cursor.general.disableHttp2 (see the team reply in that thread). In short: in 3.9.x the AI traffic moved to a transport that uses HTTP/2 by default, and HTTP/2 doesn’t go through the configured proxy. Forcing HTTP/1.1 usually brings the proxy back, but on some setups like yours it can still be unstable. It’s the same root cause. Kerberos or Negotiate isn’t involved here. The request never reaches the proxy and goes through direct DNS instead, which is why you see EAI_AGAIN. I reported the bug internally, but I can’t share an ETA for a fix yet.

Until there’s a fix, the most reliable stopgap is to downgrade to a version before 3.9 (3.1.15 works reliably for you on the same corporate Ethernet, so you can use that, or 3.8.24) and disable auto-update so Cursor doesn’t update back. Not ideal, I know, but it’s what actually works right now on a proxy-only network.

You can track progress in that thread above. Once there’s an update on the fix, they’ll post it there. Let me know if anything else is still blocking you after the downgrade.

9

This is also an issue for me. Curl requests gets through, but Cursor times out.
Tried 3.8.24, did not work. Then downgraded to 3.1.15 and it works.

10

I got similar problem that starting from 29 June that my cursor(3.7.X) cannot connect the SSL through the Network Diagnostics when I using my company network with the proxy server. That made the API, Ping, Chat as well as Agent “Unavailable”.

I had called the Cursor support but they reply to check the network. However this cannot help.

Though the checking with google, I got an idea from a post(After update cannot use) to clear the cursor profile and cache(%APPDATA%/Cursor).

However, even pass the Network Diagnostics, but it still fail to use the agent. After restart the Cursor client Network Diagnostics remain fail.

I had test a new PC to install the latest version 3.9.16, and got the same result.

Finally, I uninstall the cursor with deleting(renaming) the below 3 folder:

  • %APPDATA%/Cursor
  • %USERPROFILE%/.cursor
  • %USERPROFILE%/AppData/Local/Programs/cursor

And then download the old version 3.8.24 and install it. It is work now.

I had disabled the auto update and in the user settings (JSON):

{
“window.autoDetectColorScheme”: true,
“cursor.general.disableHttp2”: true,
“update.enableWindowsBackgroundUpdates”: false,
“update.mode”: “none”
}

11

@samuel_barbosa @siuming_office - thanks for confirming. This is the same known issue (3.9.x proxy-bypass for AI traffic). Good news: the fix is ready and will ship in one of the next releases. I can’t name the exact version yet. As soon as it hits stable, I’ll post an update here.

@siuming_office - about deleting %APPDATA%\Cursor, %USERPROFILE%\.cursor and reinstalling: it’s better not to do that. It wipes chat history, settings, and extensions, and the effect is temporary. Like you noticed, the bug comes back. Downgrading to 3.8.24 with auto-update disabled ("update.mode": "none") is a fine temporary workaround. You did the right thing there.

@samuel_barbosa - since 3.8.24 didn’t help but 3.1.15 works, stay on 3.1.15 for now and also disable auto-update so it doesn’t roll you back.

Until the fix is released, there are only two working options: force HTTP/1.1 (set all four disableHttp2 settings plus http.proxy plus proxySupport: override plus proxyStrictSSL: false, then fully quit and restart), or stay on a version older than 3.9. On proxy-only networks, HTTP/1.1 can still be unstable sometimes. It’s the same root cause, so downgrading is more reliable.

As soon as the fix reaches stable, I’ll post here.

13

hey～
As far as I know, this is clearly a bug introduced around version 3.9.16, likely related to mobile device support.

Starting from that version and later, users may be routed by default to the always-local-singleton plugin. This plugin ignores any proxy configuration, and the behavior is controlled by server-side feature gates.

As I mentioned before, the two feature gates are:

decompose_always_local_ext_host
cursor_extensions_isolation_v2

They are enabled by default. You only need to disable them.

On macOS, run this Bash command:

sqlite3 "$HOME/Library/Application Support/Cursor/User/globalStorage/state.vscdb" \
"INSERT OR REPLACE INTO ItemTable(key,value) VALUES
 ('decompose_always_local_ext_host','false'),
 ('cursor_extensions_isolation_v2','false');"

On Windows, run this in PowerShell:

sqlite3 "$env:APPDATA\Cursor\User\globalStorage\state.vscdb" `
"INSERT OR REPLACE INTO ItemTable(key,value) VALUES
 ('decompose_always_local_ext_host','false'),
 ('cursor_extensions_isolation_v2','false');"

After running the command, restart Cursor. This should prevent you from being routed to the new built-in plugin and fall back to the previous plugin version. In my testing, proxy functionality works normally again after this change.

If this helps you, please give it a like.

15

Hey @leokun, thanks for sharing another workaround. It’s helpful for users stuck on a proxy-only network.

A couple notes: we don’t recommend manually editing state.vscdb via sqlite as a general fix. Some of these values are controlled server-side and can silently revert, and direct edits to the internal DB can cause other issues. So as a temporary at-your-own-risk trick it’s fine, but it’s not something to rely on long-term.

The good news is that a fix for the root cause has already been merged and should land in one of the next stable releases. I can’t share the exact version yet. Until then, the most reliable stopgaps are still the same:

  • Force HTTP/1.1 (all disableHttp2 settings plus http.proxy plus proxySupport: override, then a full restart). It’s still unstable on some proxy-only setups.
  • Stay on a pre-3.9 version (3.8.24 or 3.1.15) with auto-update disabled via "update.mode": "none". Right now this is the most stable option.

Once the fix reaches stable, I’ll post an update here.