Linux X11: system-wide keyboard input lag only while Cursor is running (goes away after killing Cursor) — also on 3.18.25

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

System-wide keyboard input lag on Linux whenever Cursor IDE is running. Typing becomes delayed by up to seconds per character in ALL apps (Cursor, Telegram, GNOME Terminal, etc.). Input returns to normal immediately after fully killing Cursor (pkill). Not RAM thrashing: ~8–10 GiB free, swap ~0, low disk IO. TTY (Ctrl+Alt+F3) stays responsive while GUI lags. Reproduces on X11; also saw severe GUI lag on Wayland. Persists after downgrade from 3.19.13 to 3.18.25. During lag, a Cursor node.mojom.NodeService process often pegs ~100%+ CPU; ~18 Cursor processes / ~2.5–3.5 GiB RSS for one window.

Steps to Reproduce

  1. Ubuntu 24.04, X11 session (also reproduced on Wayland earlier).
  2. Start Cursor IDE (single window, modest workspace; Agent panel not required).
  3. Use the desktop normally (type in terminal/Telegram/Cursor).
  4. Observe severe system-wide keyboard lag.
  5. Fully quit/kill all Cursor processes.
  6. Observe input lag disappears immediately.

Expected Behavior

Cursor should not stall keyboard input for unrelated applications. Desktop input should remain responsive while Cursor is open.

Operating System

Linux

Version Information

Version: 3.18.25
VS Code Extension API: 1.128.0
Commit: 280eca2911f1774689696e5f1efa5a4f97a87af0
Date: 2026-08-31T23:08:02.261Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.291
OS: Linux x64 6.8.0-139-generic

Does this stop you from using Cursor

Yes - Cursor is unusable

6

Thanks for the detailed report, @AvaRoberts! Since one app can only lag every other app by starving something shared, the quickest next step is to see what’s busy during the lag. While it’s actively lagging, could you paste the output of these two?

  1. top -b -n 1 -o %CPU | head -n 20 (are Xorg, gnome-shell, ibus-daemon, or only Cursor processes at the top?)
  2. cursor --status (labels each Cursor process with CPU/memory + GPU status, so we can spot the one at 100%)

And if you can, one quick check: does starting with cursor --disable-gpu change anything?