Cursor crashes during agent loop when switching KDE virtual desktops

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor Agents crashes(Stop responding) every time I switch to another KDE virtual desktop while an agent loop is running. The crash is consistent and reproducible.

Steps to Reproduce

Start an agent task in Cursor
Switch to another KDE virtual desktop while the agent is working

Expected Behavior

Keep responding

Operating System

Linux

Version Information

OS: EndeavourOS
Desktop: KDE Plasma 6
Cursor version: 3.3.27
Electron: 41

For AI issues: which model did you use?

I am using Composer 2 when this happen, I have not tested with other models.

Does this stop you from using Cursor

Yes - Cursor is unusable

Hey, thanks for the report with clear steps. This is a known issue: when the Cursor window loses visibility on macOS this can happen when switching Spaces or locking the screen, and on KDE it happens when switching virtual desktops, the agent’s shell tool stops receiving output and the agent gets stuck. Until now we’d only confirmed this on macOS, so your report shows it also reproduces on Linux with KDE Plasma. I’ll link it to the existing issue.

We don’t have an ETA for a fix yet. As a workaround, keep the Cursor window on the same virtual desktop while the agent is running. You can also move it into a separate window via Cursor: New Window so it doesn’t get in the way while you switch to other tasks.

If there’s an update, We’ll reply in the thread.

Small update: the fix for this bug background throttling that was choking shell polling in an inactive window has been merged on our side. It’ll roll out in one of the next stable releases, I can’t name the exact version yet. I’ll post an update here when it’s out.

For now, the workaround is the same: keep Cursor on the same virtual desktop where the agent is running, or move it to a separate window via Cursor: New Window.

Hey @maxBRT,
The crash when switching KDE virtual desktops during an agent loop has been addressed in a recent Cursor update. Updating to the latest version should resolve this — let me know if you’re still running into it!

Hey @mohitjain

Unfortunately, still dealing with the same issue despite a fresh install of Cursor on KDE.

The background-throttling fix has been deployed and should be active on your installation, so the fact that it’s still happening points to something KDE-specific that the fix doesn’t fully cover.

Could you share the following so I can investigate further?

  1. Your exact Cursor version (Help > About)

  2. Whether you’re running a Wayland or X11 session (echo $XDG_SESSION_TYPE in a terminal)

  3. When the agent “crashes” - does it stop responding entirely, or does it seem to enter a loop where shell commands return empty output?

This will help us determine whether the existing fix applies to your setup or if KDE’s compositor is handling window visibility in a way that bypasses it.

  1. Version: 3.5.38
  2. Wayland Session
  3. The entire cursor app stops responding.

You’re on a Wayland session, and the fix we shipped targets a different layer than what’s causing the issue here. On Wayland, KDE’s compositor can independently suspend window rendering when you switch virtual desktops, which is why the entire app freezes rather than just the agent stalling.

As a workaround, try launching Cursor in X11 compatibility mode:

cursor --ozone-platform=x11

This forces Cursor to use XWayland instead of native Wayland, which should let the existing background-throttling fix work properly. Give it a try and let me know if the freeze still happens when switching desktops.

One more question: when the app freezes, does it eventually recover on its own after switching back to that desktop, or does it stay frozen until you kill it?

Ill give that a shot. Thanks!

Usually if I give it a while it does recover. But it takes a very long time. 5+ minutes.

UPDATE: I unfortunately experienced the same crash despite this change.