Internal error after updatting to 3.7.21!

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Hi,
after updatting the Cursor IDE to the version 3.7.21 , i got internal error .

The Devloper log folder has been sent to [email protected] as attachment (20260610T095656.zip).
Thanks in advance
Zeiad Alkassem

Steps to Reproduce

I tried to close the IDE completely.

Screenshots / Screen Recordings

Operating System

Windows 10/11

Version Information

Version: 3.7.21 (user setup)
VS Code Extension API: 1.105.1
Commit: 517f696d8ab6c53eb04fbfdaae705cd146bf3460
Date: 2026-06-07T21:46:09.237Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
xterm.js: 6.1.0-beta.256
OS: Windows_NT x64 10.0.22631

For AI issues: which model did you use?

Composer 2.5

Does this stop you from using Cursor

Yes - Cursor is unusable

Hey, thanks for the report. The error text and the Request ID helped, it’s the same issue we discussed in this thread: Internal Error: An unexpected error occurred on our servers. Please try again, or contact support if the issue persists

It looks like it’s not related to the update, but to the context size. Your screenshot shows 132 files in context, and in total that most likely exceeds the model’s context window. Cursor tries to automatically compress the context (summarization), but when it’s far over the limit, compression isn’t enough, the request ends up in a retry loop, and it fails with this error.

What to try:

  1. Start a new chat and don’t add lots of files right away, let the agent pull what it needs.
  2. Cut down the number of files in context a lot (132 is way too many for one request).
  3. Check Skills: Cursor Settings > Rules, Skills, Subagents. If you have many, the names and descriptions of all skills are loaded into every request and eat up context before your message. Delete unused ones, and for rarely used ones add disable-model-invocation: true in the header so they only load when you manually call them via /skill-name.

This is known behavior, we’re tracking it, but I can’t share an ETA for a fix yet. Let me know if the workaround helped.

Hey,
Thanks for your quick reply.
That definitely solves the problem.
The suggestions you provided are also helpful, and I’ll keep them in mind for the future.

regards