Cursor hangs everytime

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor hangs repeatedly on every prompt. Starts performing a task and hangs forever, and the “the window is not responding” message arises.

Steps to reproduce:
1 open cursor
2 write the prompt
3 Hitthe arror to start prompt execution

Expected behaviour:
answer without hanging.

Version Information:

Cursor version:
Version: 3.6.31
VS Code Extension API: 1.105.1
Commit: 81fcf2931d7687b4ff3f3017858d0c6dee7e2a60
Date: 2026-05-31T17:46:29.630Z
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.220
OS: Linux x64 6.8.0-117-generic

Ways to reproduce:
add a prompt that performs background tasks like editing files or running unit tests or scripts.

Screenshot:

image
image1919×1044 337 KB

Operating System: Linux Ubuntu 24.04

FOR AI:
model sonnet 4.6 Medium.
request id: 8011e5f9-8893-42d6-9dc7-a478423163a4

Does this stop you from using Cursor?

Yes - Cursor is unusable
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!

6

Hey, thanks for the detailed report and the screenshot. I can see the The window is not responding dialog during the agent run.

This is a known issue. During heavy agent runs lots of file edits, running tests or scripts, or grepping a large project the UI can fully freeze. We’re tracking it, but I can’t share an exact ETA for a fix yet.

A few questions and temporary workarounds that might help:

  • Does restarting Cursor help for a while, or does it freeze again right after launch?
  • If you have multiple agent threads or tabs open, try keeping only one active. This sometimes reduces load on the renderer.
  • If possible, split big tasks into smaller prompts so a single turn doesn’t kick off a lot of parallel tool calls at once.

If you notice that a specific action type like grep or running a script reliably makes the window freeze, let me know. That’ll help narrow it down. Once there’s an update on the fix, I’ll reply in the thread.

7

It freezes with only one cursor window and only 1 agent running. After restarting cursor, the ide works until I launch a prompt. Even a simple task like run scripts/run_quality_checks,py and check the errors reported in the output, which are the errors added in the last prompt execution. strictly follow AGENTS.md ARCHITECTURE_GUARDRAILS.md DOMAIN_MAP.md TESTING.md AI_CONTEXT.md ARCHITECTURE.md REPO_MAP.md ARCHITECTURE_DECISIONS.md CODEBASE_ENTRYPOINTS.md ORDER_LIFECYCLE.md STYLE.md.

Some times the ide stops responding without having any prompt running.

The same happens with “auto” model. Randomly the model is automatically switched to auto.

I also saw that cursor uses a little ammount of cpu when it hangs, so is not doing any intensive task to justify the hang

%Cpu(s): 7,5 us, 2,8 sy, 0,0 ni, 89,6 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
MiB Mem : 31995,4 total, 6823,8 libre, 15504,0 usado, 10036,9 búf/caché
MiB Intercambio: 26522,0 total, 13335,6 libre, 13186,4 usado. 16491,4 dispon Mem

PID USUARIO   PR  NI    VIRT    RES    SHR S  %CPU  %MEM     HORA+ ORDEN

9007 javier 20 0 6968116 199404 89068 R 18,8 0,6 27,43 gnome-shell
2856780 javier 20 0 32,7g 69548 43132 S 12,5 0,2 47:24.92 cursor
2856848 javier 20 0 1395,3g 2,8g 79536 S 8,6 9,0 95:49.50 cursor
2856566 javier 20 0 1410,1g 210504 103868 S 5,9 0,6 18:14.63 cursor
1535345 javier 20 0 49,2g 228884 132728 S 2,3 0,7 37:03.26 chrome
3335393 javier 20 0 1451,9g 94564 76380 S 2,3 0,3 0:00.11 chrome
1535893 javier 20 0 1453,9g 332548 114580 S 2,0 1,0 17:23.88 chrome
11906 javier 20 0 4706968 841444 94116 S 1,7 2,6 7,26 Isolated Web Co
12629 javier 20 0 775688 59540 35760 S 1,3 0,2 70:07.79 gnome-terminal-
2856984 javier 20 0 1393,7g 264232 51412 S 1,3 0,8 6:23.73 cursor
2857191 javier 20 0 1393,8g 181204 45140 S 1,3 0,6 4:24.27 cursor
2857192 javier 20 0 1409,7g 232896 43236 S 1,3 0,7 10:31.99 cursor
2857193 javier 20 0 1393,7g 127140 42932 S 1,3 0,4 4:33.52 cursor
9205 javier 20 0 462576 6896 6068 S 1,0 0,0 4:03.45 gsd-housekeepin
11391 javier 20 0 5317432 991960 164004 S 1,0 3,0 22,24 firefox
774934 javier 20 0 1393,8g 387460 33304 S 1,0 1,2 167:18.26 code

8

Thanks, these details help. The fact that the CPU stays low 89% idle during the freeze is an important clue. It usually means Cursor isn’t maxing out compute, but the main thread is blocked on something else, most often disk I/O or GPU compositing. Let’s narrow that down.

  • Next time it freezes, check disk activity. Run sudo iotop -o or iostat -x 2. Heavy writes from the Cursor process during the freeze would point to a disk bottleneck.
  • Since you’re on Linux, try launching with cursor --disable-gpu and use it for a bit. If the freezes stop, it’s a GPU or compositing issue rather than disk.
  • Test for a regression in 3.6.x. Install the previous stable 3.4 or 3.5 and use it for a day. If there are no freezes on the older build, that’s a strong signal.
  • If you can grab a profile, before launching a prompt, open Cmd+Shift+P then run Developer: Capture CPU Profile. Let the freeze happen, then run the same command again to stop once the window recovers, and attach the file here. If the window is fully frozen, Cmd+Shift+P won’t respond, so you start the profile beforehand.
  • After a freeze, it would also help to zip and attach the logs from ~/.config/Cursor/logs from the latest session.

The most useful steps are iotop during the freeze and the rollback test. Let me know what the disk looks like and whether the older version or --disable-gpu helps.

9

image
image1918×1051 403 KB

It hanged asking for a command.

image
image1915×348 18.6 KB

javier@jm:~/proyectos/emprendimientos/lonca/shipii/src/Shipii$ iostat -x 2
Linux 6.8.0-117-generic (jm) 03/06/26 x86_64 (8 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle
19,08 19,37 3,21 0,96 0,00 57,38

Device r/s rkB/s rrqm/s %rrqm r_await rareq-sz w/s wkB/s wrqm/s %wrqm w_await wareq-sz d/s dkB/s drqm/s %drqm d_await dareq-sz f/s f_await aqu-sz %util
loop91 0,00 0,00 0,00 0,00 0,07 3,19 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
nvme0n1 10,69 147,56 3,78 26,11 0,17 13,80 22,67 860,55 16,18 41,65 1,27 37,95 0,75 478,15 0,00 0,00 0,18 634,55 1,96 0,30 0,03 1,26
sda 61,32 587,02 24,17 28,27 0,24 9,57 70,41 1954,71 186,43 72,59 1,63 27,76 5,66 687,03 0,00 0,00 0,38 121,35 37,37 1,88 0,20 8,20

avg-cpu: %user %nice %system %iowait %steal %idle
7,67 37,96 2,41 0,13 0,00 51,84

Device r/s rkB/s rrqm/s %rrqm r_await rareq-sz w/s wkB/s wrqm/s %wrqm w_await wareq-sz d/s dkB/s drqm/s %drqm d_await dareq-sz f/s f_await aqu-sz %util
loop0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
loop91 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
nvme0n1 0,00 0,00 0,00 0,00 0,00 0,00 5,50 184,00 6,50 54,17 0,27 33,45 0,00 0,00 0,00 0,00 0,00 0,00 0,50 0,00 0,00 0,05
sda 0,00 0,00 0,00 0,00 0,00 0,00 1,50 50,00 11,00 88,00 3,00 33,33 0,00 0,00 0,00 0,00 0,00 0,00 1,00 1,00 0,01 0,35

^C
javier@jm:~/proyectos/emprendimientos/lonca/shipii/src/Shipii$

10

Thanks, this data really helps narrow it down. Low disk %util (peak around 8% on sda, then almost zero) together with the low CPU from your last message pretty much rules out both disk and compute as the cause. The main thread is getting blocked on something else, and renderD129 in iotop is Chromium/Electron’s GPU render process, so the suspicion shifts toward GPU or compositing.

To confirm that, there are two most useful steps left (I haven’t seen these in the report yet):

  1. Run Cursor with cursor --disable-gpu and use it like that for a while. If the freezes go away, it’s GPU or compositing.
  2. Install the previous stable version (3.4 or 3.5) and use it for a day. If there are no freezes on the older build, that’s a strong signal of a regression in 3.6.x.

One more detail: based on the screenshot, the freeze happened right when the agent requested command confirmation (the allowlist dialog). If you notice the hang reliably happens exactly when it asks for command confirmation (not during the actual execution), let me know. That will help narrow it down even more.

This is a known issue and we’re tracking it, but I can’t share an exact ETA for a fix yet. Let me know what you find with --disable-gpu and rolling back to an older version.

11

The last freeze (from the screenshot) happened when asking for command confirmation, but is not the only case, it is one of the many many freezes that occur in almost every moment of almost every prompt.
I am trying now the --disable-gpu option.

12

I confirmed that the crashes occur regardless of whether the --disable-gpu option is set or not.

13

Thanks, this is an important result. Since --disable-gpu doesn’t stop the freezes, we can rule out GPU and compositing, along with the already ruled out CPU and disk. That means the main thread is being blocked by something else, and now the most useful next steps are two things we haven’t tried in this thread yet:

  1. Rollback test. Install the previous stable version 3.4 or 3.5 and use it for a day. If the old build has no freezes, that’s a strong signal the regression is specifically in 3.6.x. Older versions: Cursor · Download
  2. CPU profile during a freeze. Since the window becomes fully unresponsive during a freeze and Cmd+Shift+P won’t work, you need to start profiling in advance: open Cmd+Shift+P then run Developer: Capture CPU Profile before you run the prompt, let the freeze happen, then once the window unfreezes, run the command again to stop the recording, and attach the file here.

The profile will show exactly which call is blocking the main thread, which is what we’re missing right now to pinpoint the cause.

This is a known issue and we’re tracking it, but I can’t share an exact ETA for a fix yet. Let me know what the rollback shows and whether you were able to capture the profile.

14

same problem i have. i tried to download previous version but the problem still exists in multitask mode.

15

When the whole app doesnt hang, the prompt hanngs.

Captura de pantalla de 2026-06-05 10-34-38
Captura de pantalla de 2026-06-05 10-34-381277×806 89.7 KB

image
image1277×794 80.3 KB

16

Thanks, the screenshots make it clear. This is a different issue than a full window freeze. The Agent Execution Timed Out card with ERROR_EXTENSION_HOST_TIMEOUT means the extension host didn’t respond in time (it’s responsible for running the agent), not that the UI rendering is hanging. This is a separate known issue, we’re tracking it, but I can’t share an exact ETA for a fix yet.

What you can do right now:

  • When that card pops up, click Reload Window (the button on it). This usually brings the extension host back without fully restarting Cursor.
  • Check if a third-party extension is slowing down the extension host. Run cursor --disable-extensions and work like that for a bit. If the timeouts stop, one of the extensions is likely the cause.

Also, two things from my earlier messages that would still help (we don’t have data on these yet):

  1. Rollback test: install the previous stable version 3.4 or 3.5 and use it for a day. If there are no freezes or timeouts on the older build, that’s a strong signal it’s a regression in 3.6.x. Older versions: Cursor · Download
  2. CPU profile at the moment it hangs: open Cmd+Shift+P → Developer: Capture CPU Profile before starting the prompt, let it hang, then after the window recovers run the same command again to stop recording, and attach the file here.

Let me know what you see after rolling back to 3.4 or 3.5, and whether --disable-extensions helps.

17

Iam ripped off with cursor “known issues” forever, I will switch to vs code with codex.

19

I get the frustration, you’ve spent a ton of time on this and the freezes are still happening. Sorry about that.

From this thread, we’ve already ruled out CPU, disk, and GPU. The most useful next step is to roll back to 3.4 or 3.5 Cursor · Download and use it for a day. If the freezes don’t happen on the older build, that’s a clear sign it’s a regression in 3.6.x.

In the latest screenshots, ERROR_EXTENSION_HOST_TIMEOUT is a different issue, an extension host timeout. Try running cursor --disable-extensions. If the timeouts go away, it’s likely caused by a third-party extension.

If the rollback helps, let me know and I’ll share an update when we have one.