Connectivity to all models is brokern for 6+ hours

Support Help
1

image
image2270Ă—230 51.1 KB

image
image1758Ă—428 33.7 KB

First, IDE started to fail to connect to the models. But CLI kept working. Then CLI died.

image
image1152Ă—1206 61.2 KB

The Network diagnostics spin without producing a result.

image
image1174Ă—1604 123 KB

image
image1152Ă—1392 132 KB

image
image1214Ă—1586 121 KB

Partial connectivity on some end points, 404 on other - CDN.

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!

5

hey man, have you tried lowering the http version? doing that until a new update might help you get things back working!

6

Interesting point, but it didn’t restore functionality. Restarted Cursor, restarted OS, re-installed Cursor, tried different Network settings - all point to Cursor infrastructure, rather than the local user issue.

8

Hi @Maxim_Volkov,

We experienced a brief service disruption around the time you reported this. The issue has since been resolved on our end.

Could you try restarting Cursor one more time and testing connectivity now? If you’re still seeing errors, please run the Network Diagnostics again (Cursor Settings > Network > Run Diagnostics) and share the updated results.

9

Hi Mohit,

I have submitted another response to the support team.
Even if the issue with the model connectivity had an explainable time alignment with the Cursor system-wide hiccup, the fact that the project I was working on at the time still shows the Model Connectivity error, while other projects of mine do not, is a mystery to me. If you have some rational explanation for how this can be happening please share your thoughts. My theory that the local directory had become corrupted was not supported - the simple copy of files to a fresh directory seems to have resolved it. I wasn’t able to locate hidden files either. My new theory, which I have no chance to verify, is that Cursor has an internal cache that was affected by a system disruption. When files are copied, a cache is re-created for the “new” project with the previous content.

Regards,

Maxim

10

Diagnostics all check through regardless of the project.

11

Cursor does maintain per-project workspace state (stored outside the project directory itself), and it’s likely that the state associated with the project that was open during the disruption got into a bad state. Opening other projects or copying to a fresh directory creates new workspace state entries, which is why those work.

Our support team is investigating this via your email thread and has asked for your exported logs (Cmd+Shift+P > Developer: Export logs). Those logs should help us pinpoint exactly what got corrupted. If you haven’t already sent those, that would be the best next step.

In the meantime, if you’d prefer to keep working in the original directory rather than the copy, you can try clearing the workspace state for that project: go to ~/Library/Application Support/Cursor/User/workspaceStorage/, and you’ll see folders with hash names. You can identify the one for the affected project by checking the workspace.json file inside each folder, then delete that folder and reopen the project. This should force Cursor to rebuild the workspace state from scratch.