This is a bug report for Cursor IDE where all AI requests are failing with a "Connection failed" error across local, IDE, and Agent environments on macOS

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Every AI request fails immediately with a connection error: “Connection failed. Please try again, or contact support if the issue persists.” The core error in the logs is “[unavailable] PING timed out” — the connection drops mid-stream. This happens across Cursor IDE, local development, and Background Agent.

Steps to Reproduce

  1. Open Cursor IDE
  2. Make any request (chat, agent, or any AI feature)
  3. Connection error appears immediately

Expected Behavior

Requests should complete successfully without connection errors.

Operating System

MacOS

Version Information

3.7.42 (Universal) — Commit: 5702c9cfca656d8710fad58402fe37f14345e3a0 — Date: 2026-06-15 — OS: Darwin arm64 25.5.0

For AI issues: which model did you use?

All models

For AI issues: add Request ID with privacy disabled

af2ba61a-83c4-4bfc-b4b0-6c26000ba29f

Does this stop you from using Cursor

Yes - Cursor is unusable

4

Its happening on Windows 11 also. Cursor is totally unusable for me at the moment.

7

Hi @Mert_Tuna_Yilmaz Thanks for reaching out! Good news: this isn’t an outage, and your account isn’t blocked. Our logs show your requests reaching us, with at least one completing successfully on June 17.

The issue is that the chat you keep retrying has grown large enough to exceed the model’s context limit, so the request fails to send, and the auto-summarization can’t shrink it back down. Since you’re reopening that same conversation, it looks like every request fails.

The Fix is easy! Just start a brand new chat. New chats should work normally.

If new chats also fail with the same error, it’s a network path issue rather than chat size. In that case:

  • Run Cursor Settings > Network > Run Diagnostics and share the result.
  • Switch the HTTP mode there to HTTP/1.1 and retry.
  • If you’re on a VPN, proxy, or custom DNS, try disabling it temporarily.

Anyone seeing this on a fresh chat (e.g. on Windows): please run Network Diagnostics and share your own request ID with privacy disabled. That rapidly speeds up the debugging process!

8

@Carla_Chalmers I took a look at your account and you seem to be hitting the exact same issue as Mert. The key is to start a new chat. The length of your chat has overwhelmed the summarization capability of the model and it can no longer effectively compact and summarize your long-running chat. Starting a new chat will fix this!

9

Thanks for the quick reply! Unfortunately the issue is NOT chat size — I’ve confirmed this:

  1. I started a brand new chat and just typed “merhaba” (hello). It STILL fails with the same error:
    Request ID: 6839045a-8c01-47a1-8c9b-e1464f24c1ee
    “Stream ended without turnEnded — connection likely dropped mid-stream”

  2. I have been getting this error since the very first day I installed Cursor — I have never received a single successful response in the IDE or Agent. (The successful request in your logs is the Network Diagnostic test, not a real chat.)

  3. I ran Network Diagnostics — EVERYTHING passes, including Chat: Success and Agent: Success (streaming ‘foo’ tokens fine). So the network path is healthy.

  4. I switched HTTP mode to HTTP/1.1 — no change.

  5. I am NOT using a VPN, proxy, or custom DNS.

The key clue: in the console logs, every real request triggers this before failing:

computeGlobalCache: slow … cursorRules: 26015ms, ruleCount: 61635
[composer] Extension host became UNRESPONSIVE
[composer] No first token received within 32s

So on every real request, Cursor spends ~26 seconds processing 61,635 “rules”, the extension host becomes UNRESPONSIVE, and the stream drops before any token arrives. The Network Diagnostic passes because it doesn’t run this rule/context-building step.

Important: I have searched my entire filesystem — there are ZERO .mdc files, ZERO .cursor/rules files, and no large rule/memory entries in any state.vscdb. So I cannot find where these 61,635 rules are coming from. It appears to be generated at runtime.

I also cannot see my repositories on the web dashboard even though GitHub is connected. Early logs also showed a recurring error:
getTeamRepos → ConnectError: [invalid_argument]
pollRepoBlocklist → [invalid_argument]

Could the ruleCount: 61635 and the getTeamRepos [invalid_argument] be related to a team/account configuration issue on the backend? Since this has happened since day one, never worked once, and persists on fresh chats with a clean network, it does not look like a local or chat-size problem.

System: macOS (Darwin arm64 25.5.0), Cursor 3.7.42

Happy to provide more logs or run anything else you need.

11

Hi @kevinn

I’ve now exhausted every local and network variable, and the evidence points clearly to a server/account-side issue.

WHAT I TESTED (none fixed it):

  • Started a brand new chat, typed only “merhaba” — still fails. So it is NOT chat size.
  • Completely uninstalled Cursor and deleted ALL local data (~/.cursor and ~/Library/Application Support/Cursor), then did a clean reinstall. Still fails.
  • Ran Network Diagnostics: EVERYTHING passes, including Chat: Success and Agent: Success (streaming ‘foo’ tokens fine).
  • Switched HTTP mode to HTTP/1.1 — no change.
  • Tested on a completely different network (mobile hotspot) — same error.
  • Firewall is OFF. No VPN, proxy, or custom DNS.
  • Tried both GPT-5.5 and Auto model — identical failure on both.

CURRENT BEHAVIOR (intermittent):
It is not a hard 100% failure. Occasionally, through the Agent (not the IDE chat panel), the FIRST response succeeds — but it cannot continue: as soon as the agent loop continues (next turn / tool call / longer output), the stream stalls and dies. The IDE chat panel essentially never works. So the streaming session cannot be sustained.

WHAT THE LOGS SHOW (the key part):
On the failing requests, the stream opens but NO further token arrives from the server. Cursor’s own stall detector then aborts and retries in a loop:

[NAL client stall detector] Advisory stall detected - no activity for advisory threshold period
ConnectError: [aborted] aborted
Stream ended without turnEnded — connection likely dropped mid-stream; retrying
[AGENT_ERROR_DIAGNOSTICS] decision=RETRY (countAsServerError=true, countAsTransportError=false)

Note countAsServerError=true and countAsTransportError=false — Cursor itself classifies this as a SERVER error, not a transport/network error. The connection is healthy; the server accepts the request but stops producing tokens mid-stream.

IMPORTANT CONTEXT: Since the day I installed Cursor I have essentially never been able to complete a real chat/agent session — at best the first Agent reply lands and then it stalls. Meanwhile other members of my team use Cursor normally on the same team, same network.

Latest failing Request ID (privacy disabled): f8de476d-bc7a-462b-8d18-b4ce224fd4bb

Earlier failing Request IDs:

  • 049b4e93-b905-4931-b637-c641ecc3b37f
  • 42b6a0e3-2cc6-4f34-954d-70f27271711e
  • 6839045a-8c01-47a1-8c9b-e1464f24c1ee

System: macOS (Darwin arm64 25.5.0), Cursor 3.7.42

Given that this is server-classified (countAsServerError=true), account-specific, and intermittent while teammates on the same team are fine, could you please investigate my account/user configuration on the backend? This does not appear to be anything fixable on my end.