Fixing Cursor IDE Performance Issues (Windows, WSL, and Linux)

Many users of Cursor IDE, especially on Windows with WSL2 and on Linux, have run into major performance problems like UI freezes, lag, and high GPU usage. These issues can make the editor feel slow and frustrating to use.

This guide provides a complete, step-by-step process to diagnose and fix these problems, starting with the simplest solutions and moving to more advanced ones.

The Problems

You might be experiencing one or more of these common issues:

• High GPU Usage: On Windows, Task Manager shows Cursor's GPU usage spiking, making the entire editor unresponsive.
• UI Freezing: The editor completely freezes for several seconds at a time. You can't type or click, but the app doesn't crash.
• General Slowness: Typing in the editor or the terminal has a noticeable delay.

Step 1: The Quick Fix - Disable Hardware Acceleration

For many users, the issue is a conflict between Cursor, your graphics driver, and your operating system (especially virtualized ones like WSL2). The first and easiest thing to try is to force Cursor to draw its interface using the CPU instead of the GPU (this is called software rendering).

1. Press Ctrl+Shift+P (or Cmd+Shift+P on macOS) to open the Command Palette.
2. Search for and select "Preferences: Configure Runtime Arguments".
3. This opens a file named argv.json.
4. Find the line // "disable-hardware-acceleration": true and remove the // at the beginning to uncomment it.
5. Save the file and completely restart Cursor.

// argv.json
{
    // ... other settings
    "disable-hardware-acceleration": true
}

This simple fix resolves the issue for many users, but if you still have lag, continue to the next step.

Step 2: Investigate with the Process Explorer

If the problem continues, you need to find out what part of Cursor is still slow. Cursor has a built-in tool just for this.

1. Open the Command Palette (Ctrl+Shift+P).
2. Search for and select "Developer: Open Process Explorer".

This opens a window that looks like a task manager, showing every process Cursor is running. Look for any row with high CPU (%). This will tell you where the real problem is.

Step 3: Solve the Specific Problem

Based on what you found in the Process Explorer, here are the targeted solutions.

Problem A: gpu-process Has High CPU

If you see gpu-process using a lot of CPU after disabling hardware acceleration, it means your CPU is struggling to render parts of the UI. The integrated terminal is a common cause. You should disable hardware acceleration for the terminal specifically.

1. Press Ctrl+, (or Cmd+, on macOS) to open Settings.
2. Search for terminal.integrated.gpuAcceleration.
3. Set it to off.

Problem B: fileWatcher Has High CPU

The fileWatcher process watches your project files for changes. With large projects or on WSL2 (where file access between Windows and Linux is slow), this can cause constant high CPU usage.

The solution is to tell the file watcher to ignore high-traffic folders that you don't need to watch, like node_modules or build output.

1. Open your settings.json file (Ctrl+Shift+P -> Preferences: Open User Settings (JSON)).
2. Add the files.watcherExclude block:

{
    // ... your other settings
    "files.watcherExclude": {
        "**/.git/objects/**": true,
        "**/.git/subtree-cache/**": true,
        "**/node_modules/*/**": true,
        "**/build/**": true,
        "**/dist/**": true
    }
}

Problem C: The Whole System is Slow (Investigating Docker)

If your entire computer feels slow even after closing Cursor, the problem is likely an external process that Cursor was interacting with. For developers using Docker in WSL, this is a very common issue. A misconfigured Docker container can create massive disk I/O that slows down your whole system.

1. Check Docker Stats: Run docker stats in your terminal to see if any container has extremely high BLOCK I/O (disk writes).
2. Example Fix (MySQL): We found that the MySQL container often has binary logging (binlog) enabled by default, which can write gigabytes of data. Disabling it in your docker-compose.yml solves the problem completely:

# In your docker-compose.yml
services:
    mysql:
        image: 'mysql/mysql-server:8.0'
        command: --disable-log-bin  # <-- This line fixes it
        # ... rest of mysql service

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com