Cursor 'Internal Error: An unexpected error occurred on our servers' — one message, several causes

Cursor shows:

Internal Error An unexpected error occurred on our servers.
Please try again, or contact support if the issue persists.

30-second answer

The wording says "our servers", but that alone does not tell you the servers are down.

In forum threads answered by Cursor staff, the same message came from several different causes —

including problems that never left the user's own machine.

Do this before changing anything:

1. Check Cursor status
2. Run Network Diagnostics inside Cursor
3. Save the Request ID if one is shown
4. Retry the same request in a new, empty chat
5. A long conversation or a large CLAUDE.md is a separate branch — see below

All of these are read-only checks. Nothing here deletes or reinstalls anything.

Sorting out which cause you have

Diagnostic order — all non-destructive

1. Check the official status page. If an incident is posted, stop here and wait
2. Run Network Diagnostics in Cursor. It reports SSL, API, Ping, Chat and Agent separately
3. Save the Request ID. Staff use it to check whether the request reached their backend
4. Retry in a new, empty chat. Same request, no prior history
5. Compare a short conversation against the long one. If only the long one fails, that is a signal
6. Check the size of your project's CLAUDE.md or other always-loaded rules files
7. Try a different network, or with VPN disabled
8. If it persists, post on the official forum with the Request ID and your diagnostics output

Branch A — Context budget exhausted

[reporter observed / fixed] In one thread the reporter noticed the error appeared when their

CLAUDE.md was large and a single Agent conversation had been running for a long time.

They shrank the file, restarted the IDE and started a new chat, then reported:

*"It is working now after I reduced the size."*

[Cursor staff confirmed] A Cursor staff member replied that the diagnosis was correct and

explained the mechanism: instruction files such as CLAUDE.md are **sent with every request and

count toward the model's context budget**. When one grows large and a single agent conversation

keeps going, the combined context can push a request past the model's limit.

Staff called the reporter's steps "the right moves" and recommended keeping instruction files

lean and starting fresh chats for new tasks.

The reporter found the cause; staff confirmed it and explained why. Staff did not identify it

independently, and this cause does not explain every occurrence of this message — see the other branches.

How to tell if this is you:

• The same request succeeds in a new empty chat
• It succeeds in a project without a large rules file
• Failures started after the conversation had been running a long time

Branch B — Local connection or network

[Cursor staff confirmed] In a second thread staff attributed the error to a **local connection

or network issue. In a third, staff noted that the Request ID could not be found in Cursor's

backend**, meaning the request may never have left the user's machine, and asked the user to run

Network Diagnostics.

Another user in one of those threads reported immediate failures for SSL, API, Ping, Chat and Agent

in Network Diagnostics.

Despite the wording, this is not a Cursor server error. The request was not delivered.

How to tell if this is you:

• Network Diagnostics fails one or more checks
• The Request ID is not found when staff look it up
• Other network-dependent tools fail at the same time

Staff diagnosed this branch, but the threads do not contain a confirmed fix. Start with the failing

diagnostic check, and with a different network or with VPN disabled.

Branch C — Transient

[Cursor staff confirmed] In one thread staff observed that the user had been using Cursor

normally again since a few days later, and asked whether the issue had resolved itself.

No lasting local change was required in that case.

That is the whole record. We are not inventing a fix for this branch — there is no evidence for

clearing caches or reinstalling. If the error clears on its own, note whether it comes back.

Branch D — Not yet determined

[not yet determined] In another thread staff asked the reporter to disable privacy mode and

reproduce the problem so they could investigate. The thread has no conclusion.

If none of the branches above match your observations, you are likely in this situation.

Post on the official forum with your Request ID and Network Diagnostics output rather than

applying fixes from a different branch.

Confirming it is resolved

• The same request that failed now completes
• Network Diagnostics passes every check
• If it was Branch A, a long conversation still fails while a fresh one succeeds — split your work
• The error does not return over the following days

Errors that look similar but are not this one

These have their own exact messages and their own causes. Do not apply this guide to them.

• Resource exhausted — premium request quota
• Unauthorized request. User is unauthorized
• Invalid API key. Unauthorized User API key

If your message is one of those, this guide's steps will not help.

Evidence

[Cursor staff confirmed] — that the context-budget mechanism explains one reported case;

that another case was a local connection or network issue; that a Request ID absent from the

backend suggests the request never left the machine; that one case resolved without action.

Staff roles were verified through the forum's public topic data (admin · moderator · staff,

group CursorStaff).

[reporter observed / fixed] — the large CLAUDE.md plus long-conversation observation, and the

confirmation that shrinking the file resolved it. This was a user's diagnosis that staff endorsed,

not an independent staff finding.

[not yet determined] — the thread where staff requested more information and no conclusion followed.

Scope and review

• Applies to: Cursor IDE. Reported on version 3.9.16 (released 2026-06-27)
• Still current: reports continue through 2026-07-22. No fix version has been announced
• Last reviewed: 2026-07-29