“Taking longer than expected” After First Prompt

[Berkay_Beyaz]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

After the first prompt, Cursor responds (sometimes with delay), but subsequent prompts consistently hang and never complete. The message “Taking longer than expected” appears and the response does not finish.

The issue happens every time after the first successful completion.

Steps to Reproduce

Open Cursor IDE

Start a new chat

Send a prompt → response comes (sometimes delayed)

Send a second prompt

The message “Taking longer than expected” appears

The response never completes

Issue is reproducible 100% of the time.

Operating System

MacOS

Version Information

Cursor Version: 2.5.12
VSCode Version: 1.105.1
Commit: bf1b461b1a12c7edd0b7fadd45b761301e304960
Build Type: Stable
Release Track: Nightly
Electron: 39.3.0
Chromium: 142.0.7444.265
Node.js: 22.21.1
V8: 14.2.231.22-electron.0

For AI issues: which model did you use?

Opus 4.6

For AI issues: add Request ID with privacy disabled

74aec878-6af4-4306-b1bd-6867803c8dc8

Does this stop you from using Cursor

Yes - Cursor is unusable

[deanrie]

Hey, thanks for the report and the request ID.

Here are a few things to try:

1. Try a different model. Does the issue still happen with Claude Sonnet 4.5 or another model? This will help confirm whether it’s specific to Opus 4.6.

2. Disable HTTP/2. Open app settings with CMD + , search for “HTTP/2”, and turn on “Disable HTTP/2”. In some network setups, requests can hang on the second call.

3. Try Stable instead of Nightly. Since you’re on Nightly, can you switch to Stable and see if the issue still happens? (Cursor Settings > Beta > Update Access)

4. Run network diagnostics. Go to Cursor Settings > Network > Run Diagnostics and share the results here.

Let me know how it goes.

[Picolas (Nico)]

Hello, I’ve had the same problem for two days. I’m using Nightly, but it doesn’t work for the stable and beta versions either.

I can’t make any requests anymore, I keep getting the message “Taking longer than expected…”, sometimes I just get the loading message and then it crashes.

However, when I go to my dashboard, it has burned through my tokens, so I have to force Cursor to close to prevent it from burning through all my tokens.

Sometimes, if I close and reopen Cursor after the “Taking longer than expected…” message, the response is displayed in the history and the changes are applied.

This is quite urgent, as Cursor is currently completely unusable.

Screenshot of lost tokens :

I had to force Cursor to close, otherwise it would have eaten my tokens in the background :

[Remy_Lespagnol (Rémy Lespagnol)]

Same issue here!

I need to restart Cursor on each prompt in order to work.

I tested by changing the model (Opus, Codex, Composer…), nothing really change.

And I tested what @deanrie asked to try. But nothing is working

[vpanek]

Hey, also the same issue here. But it is dir specific - I am running more cursor windows on vm through ssh, and in other dirs on the same vm, the cursor works just fine.

[deanrie]

Hey @Picolas, @Remy_Lespagnol, @vpanek, to help with the investigation, please share:

1. Your Cursor version (Help > About)
2. The Request ID from the stuck chat (chat context menu in the top right > Copy Request ID)

@vpanek, interesting that the issue is tied to a specific directory. How big is that project? Is there anything unusual about it like lots of files, large binaries, or a non standard structure?

@Picolas, about token usage on stuck requests, this is on our radar. Thanks for flagging it.

Let us know if the issue still happens on the latest Nightly or Stable.

[vpanek]

41fe7d67-9af3-4e44-babc-fb37375614e8 and yes, it is not standard - there is 3GB of data. Can I exclude some subdirectories to make it work?

[deanrie]

@vpanek, yes, you can exclude subfolders using a .cursorignore file. Create it in your project root:

# Exclude large data folders
data/
assets/large-files/
**/*.bin
**/*.dat

Adjust the patterns to match your actual directory structure. After saving, delete the project cache so Cursor re-indexes it:

rm -rf ~/.cursor/projects/<your-project-folder>

Then restart Cursor. With 3 GB of data, this should help a lot. More on ignore patterns here: Ignore files | Cursor Docs

Also, as a temporary workaround, try opening only the subfolder you need as your workspace instead of the whole project root.

[Remy_Lespagnol (Rémy Lespagnol)]

Seems better on release 2.5.16

[wang_duanchu]

I encountered the same problem, and it could occur anywhere (configuration: plan mode, mac, newest version cursor).

[Nikolay_Drozhzhinov]

Hi! the same trouble

I run npm cache clean --force and switch http/2 to http/1.1 in network.
and it start working

[Nadav_Kunievsky]

I’m experiencing the same issue. It gets stuck on “taking longer than expected” after running properly for less than a minute. Happens across models as well.

Version: 2.5.17 (Universal)
VSCode Version: 1.105.1
Commit: 7b98dcb824ea96c9c62362a5e80dbf0d1aae4770
Date: 2026-02-17T05:58:33.110Z
Build Type: Stable
Release Track: Default
Electron: 39.3.0
Chromium: 142.0.7444.265
Node.js: 22.21.1
V8: 14.2.231.22-electron.0
OS: Darwin arm64 24.6.0

[RKDev]

Same issue, please deal with this or provide a solution urgently.

Version: 2.5.17
VSCode Version: 1.105.1
Commit: 7b98dcb824ea96c9c62362a5e80dbf0d1aae4770
Date: 2026-02-17T05:58:33.110Z
Build Type: Stable
Release Track: Default
Electron: 39.3.0
Chromium: 142.0.7444.265
Node.js: 22.21.1
V8: 14.2.231.22-electron.0
OS: Darwin arm64 25.1.0

All network diagnostics pass

[RKDev]

.20 just came out and does not fix it either

[WU-SUNFLOWER]

I encountered a similar problem. There is a persistent text of “Taking longer than expected“ and the AI can’t do anything then.

although I can stop the AI by click the button at the bottom right, and prompt it to continue, this problem will appear again in the next round of conversation.

@deanrie

[k8s]

Same error here

Operating System

MacOS M2 Pro, Os: Tahoe 26.0.1

Cursor
Version: 2.5.20
VSCode Version: 1.105.1
Commit: 511523af765daeb1fa69500ab0df5b6524424610
Date: 2026-02-19T20:41:31.942Z
Build Type: Stable
Release Track: Early Access
Electron: 39.4.0
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Darwin arm64 25.0.0

Models
All including Auto, Claude, Gemini, Openai

Does this stop you from using Cursor

Yes

For AI issues: add Request ID with privacy disabled

25836dc7-8482-47cf-af29-8617801faff6

Network Diagnostic

No errors. I also used HTTP 1.1 and still not working

[Andrew_Leonidov]

I have a very similar (but even more severe) bug: it hangs right from the very first message in any new chat (not just after the first prompt).

Quick summary:

• Any request (even a simple “hello”) → immediately shows “Taking longer than expected…” with endless spinner (5–10+ minutes, never completes).

• Restarting Cursor / full PC reboot / clearing cache / switching models (tried all: Claude, GPT-4o, o1, Gemini) / VPN / new empty project — nothing helps.

• 100% reproducible from the first message in a fresh chat.

• Makes Cursor completely unusable for chat / agent / composer.

My separate thread with full details + screenshot:
https://forum.cursor.com/t/taking-longer-than-expected/152616

In that thread I selected in the poll: Yes - Cursor is unusable

Additional info:

• Cursor Version: 2.5.20 (Stable) Commit: 511523af765daeb1fa69500ab0df5b6524424610 Date: 2026-02-19T20:41:31.942Z Electron: 39.4.0 OS: Windows_NT x64 10.0.19045 (Windows 10/11)

• Default model: Same behavior across all (Anthropic, OpenAI, Gemini).

[recall (1743936072)]

same issue

[Hu_PP (胡 澎沛)]

I also encountered this issue and resolved it successfully based on Dean Rie’s reply by using an ignore file. Here’s how: In settings, search for “Ignore Files in .cursorignore”—you’ll see the CodebaseIndexing status above. If it hasn’t reached 100%, first try stopping it. Then, in Chat, ask it to generate an ignore file that fits your project architecture. You can provide the URL to it, such as doc ignore-files. After that, edit the .cursorignore file to paste the generated content and re-index. This should fix the problem, and you’ll find the number of files requiring indexing is greatly reduced.

[408183 (408183 周子理)]

Same issue Here:

Version

Version: 2.6.11

VSCode Version: 1.105.1

Commit: 8c95649f251a168cc4bb34c89531fae7db4bd990

Date: 2026-03-03T18:57:48.001Z (1 day ago)

Build Type: Stable

Release Track: Default

Electron: 39.6.0

Chromium: 142.0.7444.265

Node.js: 22.22.0

V8: 14.2.231.22-electron.0

OS: Darwin arm64 23.4.0

Network

All success

Cursor Network Diagnostic Results

DNS: Success
Logs:
[2026-03-05T06:29:54.499Z] Host: api2.cursor.sh
[2026-03-05T06:29:54.499Z] Servers: 30.30.30.30,fd00:1::1
[2026-03-05T06:29:54.499Z] Resolved to 98.90.180.134 in 20ms
[2026-03-05T06:29:54.512Z] Resolved to 98.90.180.134 in 13ms
[2026-03-05T06:29:54.522Z] Resolved to 98.90.180.134 in 3ms
[2026-03-05T06:29:54.525Z] Resolved to 98.90.180.134 in 2ms
[2026-03-05T06:29:54.526Z] Host: api2.cursor.sh
[2026-03-05T06:29:54.526Z] Servers: system
[2026-03-05T06:29:54.526Z] Resolved to 98.90.180.134, 54.91.216.89, 54.236.182.198, 3.212.121.206, 54.225.225.0, 100.48.152.42, 3.211.49.156, 44.215.215.40 in 1ms
[2026-03-05T06:29:54.527Z] Resolved to 98.90.180.134, 54.91.216.89, 54.236.182.198, 3.212.121.206, 54.225.225.0, 100.48.152.42, 3.211.49.156, 44.215.215.40 in 0ms
[2026-03-05T06:29:54.527Z] Resolved to 98.90.180.134, 54.91.216.89, 54.236.182.198, 3.212.121.206, 54.225.225.0, 100.48.152.42, 3.211.49.156, 44.215.215.40 in 0ms
[2026-03-05T06:29:54.527Z] Resolved to 98.90.180.134, 54.91.216.89, 54.236.182.198, 3.212.121.206, 54.225.225.0, 100.48.152.42, 3.211.49.156, 44.215.215.40 in 0ms
[2026-03-05T06:29:54.527Z] Result: true

SSL: Success
Logs:
[2026-03-05T06:29:54.472Z] Start
[2026-03-05T06:29:55.407Z] URL: https://api2.cursor.sh/
[2026-03-05T06:29:55.407Z] Status: 200
[2026-03-05T06:29:55.407Z] IP: 127.0.0.1
[2026-03-05T06:29:55.407Z] Issuer: C=US; O=Amazon; CN=Amazon RSA 2048 M01
[2026-03-05T06:29:55.407Z] Name: api2.cursor.sh
[2026-03-05T06:29:55.407Z] AltName: DNS:api2.cursor.sh, DNS:prod.authentication.cursor.sh, DNS:*.api2.cursor.sh
[2026-03-05T06:29:55.407Z] DNS Time: 10ms
[2026-03-05T06:29:55.407Z] Connect Time: 0ms
[2026-03-05T06:29:55.407Z] TLS Time: 714ms
[2026-03-05T06:29:55.407Z] Result: true in 935ms

API: Success
Logs:
[2026-03-05T06:29:54.475Z] Start
[2026-03-05T06:29:55.187Z] Result: true

Ping: Success
Logs:
[2026-03-05T06:29:54.476Z] Sending ping 1
[2026-03-05T06:29:55.702Z] Response: ‘ping’ in 1226ms
[2026-03-05T06:29:55.702Z] Sending ping 2
[2026-03-05T06:29:56.814Z] Response: ‘ping’ in 1112ms
[2026-03-05T06:29:56.814Z] Sending ping 3
[2026-03-05T06:29:57.760Z] Response: ‘ping’ in 946ms
[2026-03-05T06:29:57.761Z] Sending ping 4
[2026-03-05T06:29:58.685Z] Response: ‘ping’ in 924ms
[2026-03-05T06:29:58.685Z] Sending ping 5
[2026-03-05T06:29:59.481Z] Response: ‘ping’ in 796ms
[2026-03-05T06:29:59.481Z] Result: true

Chat: Success
Logs:
[2026-03-05T06:29:54.477Z] Starting streamSSE
[2026-03-05T06:29:55.429Z] Response: ‘foo’ in 951ms
[2026-03-05T06:29:56.445Z] Response: ‘foo’ in 1016ms
[2026-03-05T06:29:57.447Z] Response: ‘foo’ in 1002ms
[2026-03-05T06:29:58.448Z] Response: ‘foo’ in 1001ms
[2026-03-05T06:29:59.455Z] Response: ‘foo’ in 1007ms
[2026-03-05T06:30:00.447Z] Result: true

Agent: Success
Logs:
[2026-03-05T06:29:54.478Z] Starting stream
[2026-03-05T06:29:54.478Z] Pushing first message
[2026-03-05T06:29:55.515Z] Response: ‘foo’ in 1037ms
[2026-03-05T06:29:56.015Z] Pushing next message
[2026-03-05T06:29:57.118Z] Response: ‘foo’ in 1603ms
[2026-03-05T06:29:57.619Z] Pushing next message
[2026-03-05T06:29:58.633Z] Response: ‘foo’ in 1515ms
[2026-03-05T06:29:59.134Z] Pushing next message
[2026-03-05T06:30:00.141Z] Response: ‘foo’ in 1508ms
[2026-03-05T06:30:00.643Z] Pushing next message
[2026-03-05T06:30:01.634Z] Response: ‘foo’ in 1493ms
[2026-03-05T06:30:01.634Z] Result: true

Marketplace: Success
Logs:
[2026-03-05T06:29:54.468Z] Host: marketplace.cursorapi.com
[2026-03-05T06:29:55.780Z] Response in 1312ms
[2026-03-05T06:29:55.780Z] Response: 200
[2026-03-05T06:29:55.780Z] Response Type: cors
[2026-03-05T06:29:55.780Z] Server: null
[2026-03-05T06:29:55.780Z] Result: OK in 1312ms

Authentication: Success
Logs:
[2026-03-05T06:29:54.469Z] Host: prod.authentication.cursor.sh
[2026-03-05T06:29:55.872Z] Response: 200 in 1403ms

Authentication UI: Success
Logs:
[2026-03-05T06:29:54.473Z] DNS lookup: authenticator.cursor.sh
[2026-03-05T06:29:54.507Z] Resolved authenticator.cursor.sh to 104.18.35.233 in 30ms

Cursor Tab: Success
Logs:
[2026-03-05T06:29:54.473Z] DNS lookup: api3.cursor.sh
[2026-03-05T06:29:54.508Z] Resolved api3.cursor.sh to 104.18.18.125 in 32ms

Agent Endpoint: Success
Logs:
[2026-03-05T06:29:54.473Z] DNS lookup: agent.api5.cursor.sh
[2026-03-05T06:29:54.507Z] Resolved agent.api5.cursor.sh to 52.9.160.66 in 30ms

Codebase Indexing: Success
Logs:
[2026-03-05T06:29:54.473Z] DNS lookup: repo42.cursor.sh
[2026-03-05T06:29:54.524Z] Resolved repo42.cursor.sh to 44.209.131.165 in 48ms

Downloads: Success
Logs:
[2026-03-05T06:29:54.472Z] Host: downloads.cursor.com
[2026-03-05T06:29:56.276Z] Response: 403 in 1804ms

CDN: Success
Logs:
[2026-03-05T06:29:54.472Z] Host: cursor-cdn.com
[2026-03-05T06:29:55.451Z] Response: 404 in 979ms