Cursor Agent fails with 'ConnectError: [unavailable]'

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Hello,

After upgrading Cursor, the Agent stopped working completely. Every prompt stays in “Reconnecting” for about 20 seconds and then fails.

The issue started immediately after upgrading to Cursor 3.9.16. The previous version was working correctly in the same environment.

Environment

  • Cursor 3.9.16 (Stable)
  • Windows 11 25H2 (Build 26200.8655)

Cursor version

Version: 3.9.16 (user setup)
VS Code Extension API: 1.105.1
Commit: 042b3c1a4c53f2c3808067f519fbfc67b72cad80
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0

Symptoms

Every Agent request remains in Reconnecting and eventually fails with:

Request ID: <id>

Network disconnected

RetriableError: [unknown] Network disconnected

The Developer Console also shows multiple ConnectRPC errors such as:

Failed to refresh authentication
Failed to fetch usage limits
Failed to fetch plan information

ConnectError: [unavailable]

Network diagnostics

Cursor’s built-in Network Diagnostics reports:

FAILED:
- API
- Ping
- Chat
- Agent

SUCCESS:
- DNS
- Authentication
- Marketplace
- Downloads
- CDN
- Agent Endpoint DNS

Authentication succeeds with HTTP 200.

Marketplace also succeeds.

Only API/Chat/Agent/ConnectRPC operations fail.

DNS works correctly

api2.cursor.sh
Resolved successfully

agent.api5.cursor.sh
Resolved successfully

api3.cursor.sh
Resolved successfully

The same is true for Cursor endpoints.

Important observation

The following Cursor services work correctly:

  • Authentication
  • Marketplace
  • Downloads
  • CDN
  • DNS resolution

Only these fail:

  • API
  • Ping
  • Chat
  • Agent

All failures return:

ConnectError: [unavailable]

This suggests that normal HTTPS communication is working, but ConnectRPC (or the protocol used by the Agent) is failing.

Why I believe this may be a regression

The problem started immediately after updating Cursor.

Nothing changed in the network configuration.

The previous Cursor version worked correctly behind the same corporate proxy.

Since Authentication and Marketplace continue to work, this does not appear to be a general connectivity issue.

It seems specific to the Agent/ConnectRPC communication.

Could you please advise whether this is a known issue with Cursor 3.9.16 or whether there are any additional proxy settings required for the Agent backend?

If needed, I can also provide the Developer Tools Network logs and Console output.

I can also reproduce this consistently. It fails 100% of the time on every Agent request.

Steps to Reproduce

  1. Use a Windows 11 machine

  2. Install Cursor 3.9.16 (the previous version worked correctly in the same environment).

  3. Sign in successfully to Cursor.

  4. Open any workspace.

  5. Open the Agent chat and send a simple prompt such as:

    Hello

  6. The request remains in “Reconnecting” for about 20–25 seconds and then fails with:

    ConnectError: [unavailable]

    or

    Network disconnected

Additional observations

  • Authentication succeeds.
  • Marketplace requests succeed.
  • Downloads succeed.
  • DNS resolution succeeds.
  • https://api2.cursor.sh is reachable through the proxy.
  • Only Agent/API/Chat/Ping requests fail.

The issue is 100% reproducible in our environment

Expected Behavior

The agent should respond something to the promtp “Hello”

Operating System

Windows 10/11

Version Information

Version: 3.9.16 (system setup)
VS Code Extension API: 1.105.1
Commit: 042b3c1a4c53f2c3808067f519fbfc67b72cad80
Date: 2026-06-27T06:41:01.941Z
Layout: editor
Build Type: Stable
Release Track: Default
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: Windows_NT x64 10.0.26200

Does this stop you from using Cursor

Yes - Cursor is unusable

5

Hey, thanks for the detailed report. The diagnostics are textbook and they point straight to the cause.

This is known behavior in 3.9.16 behind a corporate proxy. Starting with that version, AI requests API, Chat, Agent, Ping use a separate HTTP/2 transport, and Node’s HTTP/2 can’t go through a proxy agent. That’s why Auth, Marketplace, and Downloads work, they use the main process that respects the proxy, but Agent fails with ConnectError: [unavailable]. The fix is to switch to HTTP/1.1, that path properly uses your http.proxy.

Try this:

  1. App Settings Ctrl+Shift+, then search for HTTP/2 and turn on Disable HTTP/2, or add this to settings.json:
    "cursor.general.disableHttp2": true
  2. Make sure you have:
    "http.proxy": "http://<your-proxy>:<port>",
"http.proxySupport": "override"
  3. Fully quit and restart Cursor. Do a real exit and relaunch, not Reload Window.

If it still fails and you suspect Windows is picking up a cached system proxy, start Cursor.exe --no-proxy-server.

Long-term IT fix: add these domains to the proxy or SSL inspection allowlist or bypass: *.cursor.sh, *.cursor.com, *.cursorapi.com, *.cursor-cdn.com, or configure the proxy to pass through HTTP/2 bidirectional streaming without buffering. More details:

On HTTP/1.1 you won’t lose functionality. Agent, Chat, and Tab still work normally, the only difference is slightly higher latency. Let me know if this helps.

7

Thanks. Unfortunately I had already tried exactly that before opening the ticket.

My current settings are:

{
“cursor.general.disableHttp2”: true,
“http.proxy”: “http://proxysis:8080”,
“http.proxySupport”: “override”
}

I also:

fully exited Cursor (not Reload Window)
restarted Cursor
configured HTTP_PROXY and HTTPS_PROXY environment variables
verified that the integrated terminal sees those variables

However, the problem remains exactly the same.

Running Cursor Network Diagnostics still reports:

Authentication: Success
Marketplace: Success
API: ConnectError: [unavailable]
Chat: ConnectError: [unavailable]
Agent: ConnectError: [unavailable]

Is there any log, debug flag, or developer setting that confirms whether the Agent is actually using the HTTP/1.1 fallback?

8

Thanks for going through the whole checklist already, that really narrows it down. If you still get ConnectError: [unavailable] even on HTTP/1.1, then it’s not the flag itself. On 3.9.x, disableHttp2: true is respected by the client. It’s more likely your proxy is cutting off or buffering even the HTTP/1.1 connection to the AI endpoints.

How to verify the Agent is actually using HTTP/1.1 through the proxy:

  1. The most reliable way is the proxy logs. Send any prompt in Agent, then check the proxysis access log for CONNECT api2.cursor.sh:443 and also api3.cursor.sh, agent.api5.cursor.sh. If you see entries, traffic is going through the proxy over HTTP/1.1. If you don’t, the connection is still going direct.
  2. On the client: Command Palette Ctrl+Shift+P → Developer: Open Logs Folder, then check the network logs right after the request.
  3. Via netstat or Wireshark during the request: the connection should go to the proxy IP:port, not directly to Cloudflare IPs.

What to try next:

  1. Add this to settings.json: "http.proxyStrictSSL": false. If the proxy does SSL inspection with a self-signed cert, the HTTP/1.1 path will fail too. Do a full restart after.
  2. If you suspect Windows is picking up a cached system proxy, run Cursor.exe --no-proxy-server.

Most likely this needs an IT or proxy-side fix. The proxy must allow bidirectional HTTP/2 streaming and SSE without buffering, or you need to allowlist or bypass SSL inspection for:
*.cursor.sh, *.cursor.com, *.cursorapi.com, *.cursor-cdn.com.
More details: Network Configuration | Cursor Docs and Network, proxy, and remote connections | Cursor Docs

Honestly, this is a known regression in 3.9.16 behind strict proxies. I can’t give a precise ETA for a fix yet. As a temporary workaround, a few users rolled back to 3.8.24 with auto-update disabled, and it works there. Let me know what you see in the proxy logs from step 1. That will show whether traffic is reaching the proxy at all.