High CPU & RAM Usage from 'window' process while Cursor is completely idle

Describe the Bug

Hi team,

I’m experiencing severe performance issues and resource drain on Windows. Cursor consumes massive amounts of RAM (nearly 4GB) and high CPU usage (around 20%) even when the editor is completely idle and hasn’t been touched for over an hour or day.

The issue is NOT caused by extensions. As you can see in the attached screenshot of the internal Process Explorer, all extensionHost processes are at 0%-1% CPU.

The resource drain seems to come directly from the internal window processes and multiple ptyHost (PowerShell) processes that are stuck in the background, as well as the indexing engine that seems to hang.

Partial Fix & Lingering Issue:
Running Developer: Reload Window drops the CPU from ~20% down to 4%-6%. However, 4%-6% CPU usage for a completely idle application is still way too high (it should be near 0%).

Attached are screenshots from both Windows Task Manager and the Cursor Process Explorer proving the extensions are not the culprit.

Is there a known fix for these Electron/Window memory leaks and high baseline CPU during idle time?

Steps to Reproduce

Open Cursor with a regular project.

Leave the IDE in the background/idle for an hour.

Check Windows Task Manager vs. Cursor’s Process Explorer.

Expected Behavior

When the IDE is completely idle and in the background for an extended period, CPU usage should drop to near 0%-1%. Background processes (like terminals or indexing) should gracefully sleep or pause, and RAM usage should remain stable without leaking.

Screenshots / Screen Recordings

Operating System

Windows 10/11

Version Information

Version: 3.0.12 (user setup)
VSCode Version: 1.105.1
Commit: a80ff7dfcaa45d7750f6e30be457261379c29b00
Date: 2026-04-04T00:13:18.452Z
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
OS: Windows_NT x64 10.0.26200

Does this stop you from using Cursor

No - Cursor works, but with this issue

1 Like

Hey, thanks for the report and the Process Explorer screenshot, it’s really helpful.

I can see the main load is coming from two window renderer processes: one at 11% CPU / 632 MB, the other at 6% CPU / 536 MB. Terminals and extensionHost don’t seem to be the cause here, you’re right.

This is a known issue with renderer processes and the team is aware. There’s no ETA right now, but your report helps with prioritization.

A few questions and workarounds:

  1. You have 3 terminals open, try closing the ones you’re not using. They don’t use much CPU by themselves, but they can still affect the renderer.

  2. Run Developer: Reload Window. Like you noticed, it resets the load. I’d recommend doing this from time to time, especially after long sessions.

  3. Try closing the second Cursor window if you have one open, so you can remove the second window process at 536 MB / 6% CPU.

  4. Check the History (Mem) tab in Process Explorer. If the window process RAM keeps growing over time without stopping, that would confirm a leak. A screenshot from there would help.

Let me know how it goes.

Thanks for the reply and for confirming this is a known issue.

I want to emphasize that from a user perspective, this bug feels borderline critical. Because it happens constantly in the background, it completely drains my laptop’s battery, forces the fans to spin loudly all the time (which is highly distracting), and honestly, the resource consumption is so aggressive it almost feels like a botnet or malware. It makes working unplugged nearly impossible.

Regarding your points:

  1. The second window: The second “window” process you noticed is NOT a second Cursor IDE instance. It’s actually the Process Explorer window itself! I only have one single project/window open.

  2. Reloading the window: Running Developer: Reload Window temporarily drops the CPU, but the moment I touch or interact with the editor even slightly, the usage immediately spikes back up to the same high levels and stays there. It’s not a sustainable workaround.

  3. Memory History: Attached is the History (Mem) screenshot. As you can see, it doesn’t look like a classic memory leak (it’s not growing infinitely over time). Instead, it just hits a massive baseline of ~2.5GB and aggressively holds onto it, never releasing resources even when completely idle.

I really hope this context helps the team prioritize a fix soon.