Cursor IDE fails to launch since version 3.19 - Electron version?

sgy · September 11, 2026, 12:30pm

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor fails to launch since (and including) version 3.19.

Symptoms:

start cursor from the CLI
no window starts; process visible in htop, ~120MB
after a few seconds or minutes of near 100% CPU usage, cursor process crashes.

Steps to Reproduce

On my system (Tuxedo OS / Ubuntu 24.04):

upgrade cursor to version > 3.18 (apt)
attempt to launch
no window appears; after a few minutes, cursor crashes with:

Thread 1 “cursor” received signal SIGSEGV, Segmentation fault.

Expected Behavior

The IDE to launch normally.

Operating System

Linux

Version Information

Fails on: Cursor IDE >= 3.19.*
Works on: Cursor IDE <= 3.18.*

Additional Information

Fixed by downgrading and pinning on an older version. Luckily 3.18 is still available.

I’ve asked claude code (opus) to investigate and fix. It was unable to and recommended to make a report here, with the following information:

3.19/3.20 (Electron 42) hang at startup with a syscall storm, then SIGSEGV — 3.18.25 (Electron 40) works on same machine

Summary

Cursor 3.20.10 never opens a window on my machine. About one second after launch the main
process pegs one CPU core at 100% system time, stops servicing IPC, and segfaults ~64 s
later. 3.18.25 on the identical machine and profile starts normally in 4 seconds.

The variable that tracks the failure is the bundled Electron version:

Version Electron Result

3.17.8 – works (from my usage history)

3.18.25 40.10.3 works — measured

3.19.13 – fails (from my usage history; I rolled back on Sep 8)

3.20.10 42.10.0 fails — measured

Environment

TUXEDO OS (Ubuntu 24.04 base), kernel 7.0.0-111030-tuxedo, glibc 2.39-0ubuntu8.9

KDE Plasma 6.6.6, X11

NVIDIA RTX 5060, driver 580.178.04, 3× 2560×1440

Installed via apt from downloads.cursor.com/aptrepo

Reproduction
cursor --no-sandbox --user-data-dir=$(mktemp -d) --disable-extensions /tmp/somedir
Fails with a brand-new profile and no extensions. Reproduces when the .deb is extracted to
/tmp and run directly, so it is not tied to the installed tree.

Symptoms
No window ever appears; Cursor’s own logs/ directory is never created

Main thread (CrBrowserMain): 0% user time, 100% system time, from ~1 s after launch onward
Child processes self-terminate at 15 s, since the browser process never connects:
[INFO:content/child/child_thread_impl.cc:903] Terminating current process after 15 seconds with no connection.
Main process SIGSEGV at ~64 s
It is extremely deterministic. Two independent runs (installed copy, and the .deb extracted
to a different path) ended at syscw = 8,390,092 and 8,390,119 — 27 syscalls apart out
of 8.4 million.

The anomaly

/proc/<pid>/io attributes a huge volume of write operations to the process — ~500k syscw/s,
wchar growing ~2.3 GB/s — but strace cannot see them:

In one 4-second window: kernel syscw delta 1,842,409, while strace -f filtering
write,writev,pwrite64,pwritev logged 0 calls

A full strace -f -c run to the crash observed 37,034 syscalls total, including only
112 write and 122 writev

Nothing on the system reads this data, and nothing lands on disk (456 KB written to the profile
dir). No iou-sqp/iou-wrk kernel threads exist. Blocking io_uring_setup via LD_PRELOAD
reduces the rate (545k→92k/s) but does not prevent the hang or the crash.

Crash backtrace

Captured with gdb (ASLR disabled, so library addresses are stable across runs):
Thread 1 "cursor" received signal SIGSEGV, Segmentation fault.
0x00007ffeeb1540e0 in ?? ()

#0  0x00007ffeeb1540e0 in ??? ()
#1  0x00007ffff78ddc13 in ??? () at /lib/x86_64-linux-gnu/libgio-2.0.so.0
#2  0x00007ffff78e625f in ??? () at /lib/x86_64-linux-gnu/libgio-2.0.so.0
#3  0x00007ffff787e7bb in ??? () at /lib/x86_64-linux-gnu/libgio-2.0.so.0
#4  0x00007ffff7882713 in ??? () at /lib/x86_64-linux-gnu/libgio-2.0.so.0
#5  0x00007ffff78dce62 in ??? () at /lib/x86_64-linux-gnu/libgio-2.0.so.0
#6  0x00007ffff787e7bb in ??? () at /lib/x86_64-linux-gnu/libgio-2.0.so.0
#7  0x00007ffff787e7f5 in ??? () at /lib/x86_64-linux-gnu/libgio-2.0.so.0
#8  0x00007ffff7ea545e in ??? () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#9  0x00007ffff7f04977 in ??? () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#10 0x00007ffff7ea4a23 in g_main_context_iteration () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#11 0x0000555558812f36 in ??? ()
#12 0x000002f00011c420 in ??? ()
#13 0x0000000000000000 in ??? ()

rip  0x7ffeeb1540e0
rsp  0x7fffffffc5b8
rbp  0x7fffffffc5e0
 rip = 0x7ffeeb1540e0; saved rip = 0x7ffff78ddc13
No symbol matches $rip.
Across separate runs, frames #1–#11 are identical, but frame #0 varies
(0x00007ffeeb1540e0 vs 0x00007ffff48a90e0) and falls in the thread-stack address range.
Same call path every time, different jump target — i.e. GIO dispatches a callback through a
dangling/garbage function pointer, rather than jumping to a fixed bad address.

Cursor links system glib/gio/gtk3 (no bundled copy). glib 2.80.0 was unchanged across the
working and broken versions.

systemd-coredump only stored truncated cores for these crashes, so the coredumps themselves
yield no usable stack; the live gdb capture above is the reliable artifact.

Ruled out by direct test

Each tested with a throwaway --user-data-dir:

Profile / state.vscdb — clean profile fails identically

Extensions — --disable-extensions

GPU — --disable-gpu, --use-gl=swiftshader, --in-process-gpu; hardware acceleration
already disabled via argv.json

X server / NVIDIA / multi-monitor — identical failure under xvfb-run

D-Bus — DBUS_SESSION_BUS_ADDRESS=disabled:

Keyring — --password-store=basic and gnome-libsecret

Proxy — --no-proxy-server, GIO_USE_PROXY_RESOLVER=dummy

io_uring — UV_USE_IO_URING=0, plus LD_PRELOAD returning ENOSYS from io_uring_setup

Package integrity — dpkg -V clean; downloaded .deb is MD5-identical to the apt-cached one

AppArmor — extracting to /tmp puts it outside the cursor-sandbox profile path; same failure

Side note (separate issue)

Without --no-sandbox it fails immediately with:
FATAL:sandbox/linux/services/credentials.cc:131] Check failed: . : Permission denied (13)
That’s kernel.apparmor_restrict_unprivileged_userns=1 on Ubuntu 24.04. The shipped
/etc/apparmor.d/cursor-sandbox only covers the agent helper cursorsandbox, and its userns,
rule is commented out (“Uncomment this on AppArmor 4.0”) — but Ubuntu 24.04 ships AppArmor 4.x.
Chrome’s .deb ships a profile that handles this.

Ask

Happy to run further diagnostics, test a build, or collect anything specific. Given 3.18.25
(Electron 40) works and 3.19/3.20 (Electron 42) don’t on otherwise identical software, the
Electron bump looks like the place to start.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

Colin · September 13, 2026, 10:26am

Hey @sgy, thanks for the super detailed report!

Other machines on the same TUXEDO kernel build are launching 3.19 and 3.20 just fine, so my bet is that something on your system is getting loaded into the main process (a GTK/GIO module, a preloaded library, or some session env var).

Could you run a few things on 3.20 and paste what you get?

Quit Cursor completely, then start it like this:

env -i HOME="$HOME" DISPLAY="$DISPLAY" XAUTHORITY="$XAUTHORITY" PATH=/usr/local/bin:/usr/bin:/bin /usr/share/cursor/cursor --no-sandbox --user-data-dir="$(mktemp -d)" --disable-extensions /tmp/somedir

Do you get a window?

If yes, also paste the output of these from your normal shell:

env | grep -iE 'GTK|GIO|GDK|GLIB|LD_|QT_|XDG_CURRENT_DESKTOP|XDG_SESSION'

ls /usr/lib/x86_64-linux-gnu/gio/modules/

It would also be helpful to peek at the process while it’s stuck at 100%

Within the first minute, open a second terminal and run:

PID=$(pgrep -o -x cursor)
sudo cat /proc/$PID/stack
sudo cat /proc/$PID/syscall
ls -l /proc/$PID/fd | head -60

That’ll tell us what the kernel is doing with the main thread and where all those writes are going.

Finally, try creating a brand new local user on the same machine, log in, and launch 3.20 once:

Works there? It’s something in your user config.
Still broken? It’s system-wide.

sgy · September 17, 2026, 1:23pm

Hey Colin, thanks a lot for the quick reply!

I tried running all of the commands you suggested, preparing to post here. During this process, Claude and I managed to fix it - not with the commands you have alone unfortunately, although they are related.

I’ll skip posting the output of the commands you posted and instead focus on the solution - let me know if you’d like the output anyway, I have them on file.

Fix

During my investigation, I accidentally ran cursor as sudo, which booted it. With Claude, we figured that setting HOME to an empty temp dir also makes it boot. So then we bisected my entire home directory with symlinks, attempting a boot after every cycle - and noticed that the culprit is the following file:

 .config/gtk-3.0/settings.ini;

Specifically, the line:

gtk-modules=colorreload-gtk-module:window-decorations-gtk-module:appmenu-gtk-module

I’m also told that removing this line by hand is unlikely to grip because KDE writes it every time on boot.

Fixed instead by permanently diverting the so file:

 sudo dpkg-divert --add --rename --divert /usr/lib/x86_64-linux-gnu/gtk-3.0/modules/libappmenu-gtk-module.so.disabled /usr/lib/x86_64-linux-gnu/gtk-3.0/modules/libappmenu-gtk-module.so

Which will disables the global top menu bar for some applications I’m told, and instead show them in-app, but I’m fine with that.

If you consider this a bug / something that’s interesting to investigate further, let me know.

Second issue

Claude suggested I post the following output below. Not going to lie; I don’t understand it in detail. Feel free to follow up though:

There’s also a second, separate bug I hit along the way: launching without --no-sandbox dies instantly with
FATAL:sandbox/linux/services/credentials.cc:131] Check failed: . : Permission denied (13)
Ubuntu 24.04 blocks unprivileged user namespaces, which Chromium’s sandbox requires. Ubuntu ships allow-profiles for VS Code (/etc/apparmor.d/code) and Chrome (/etc/apparmor.d/chrome), but the Cursor package ships none for its main binary — and its own /etc/apparmor.d/cursor-sandbox has the needed rule commented out with “Uncomment this on AppArmor 4.0” (I’m on AppArmor 4.0.1). Adding this fixed it:
abi <abi/4.0>,
include <tunables/global>

profile cursor /usr/share/cursor{/bin,}/cursor flags=(unconfined) {
  userns,
  include if exists <local/cursor>
}
This is also why the new-user test crashed rather than hung — that account was launching without --no-sandbox.

My note: On my account launch also failed without --no-sandbox since forever, I launched cursor with that flag every time via .bashrc.

Further diganostics

Full diagnostic summary — method, evidence, and what was ruled out

Author also claude:

Culprit

appmenu-gtk-module, loaded into every GTK3 application’s main process via the gtk-modules= key in ~/.config/gtk-3.0/settings.ini. It hangs Electron 42, which Cursor moved to in 3.19.

Bisecting the three modules in that line individually, launching once per variant:
no gtk-modules line (control)   BOOTS
colorreload-gtk-module          BOOTS
window-decorations-gtk-module   BOOTS
appmenu-gtk-module              HANGS
all three (control)             HANGS
appmenu-gtk3-module is a dependency of plasma-workspace, so it is installed on every KDE Plasma system. This should reproduce on any Plasma machine, which likely explains why non-Plasma machines on the same kernel are unaffected.

Why environment-based tests could not have found it

GTK reads gtk-modules from settings.ini on disk, independently of GTK_MODULES in the environment. A launch under env -i therefore still loads the module, and env | grep GTK shows nothing relevant. The module genuinely is loaded into the main process — it just doesn’t arrive via the environment.

How it was isolated

Running under sudo booted reliably; as my own user it never did.

That turned out not to be privilege: the root launch had HOME pointing at an empty temp dir. Setting HOME to a temp dir as my normal user also booted.

Bisected $HOME by building synthetic home directories containing progressively smaller subsets, launching once per subset. This reached .config/gtk-3.0/settings.ini.

Bisected that file’s 18 lines, then the modules within the guilty line.

Boot success was determined by checking for a mapped window whose _NET_WM_PID matched a live cursor process, rather than by eye — a hung process stays alive and looks similar otherwise.

Editing settings.ini is not a durable fix

KDE’s gtkconfig KDED module regenerates ~/.config/gtk-3.0/settings.ini at login. Verified directly: after removing appmenu-gtk-module by hand and rebooting, the file’s checksum had changed and the module was back on line 13. Diverting the .so is what makes the fix persist.

Failure signature while hung

Main process spins at 100% CPU. /proc/$PID/syscall returns running — spinning in userspace, not blocked in a syscall.

No window is ever mapped.

It eventually takes SIGSEGV with rip == rax, pointing into a zero-filled page: an indirect call through a bad function pointer. ldd -r reports no unresolved symbols and no missing libraries, so it is not a link-time resolution failure.

Child processes become zombies that the parent never reaps.

Threads then wedge in do_exit and the process survives SIGKILL, requiring a reboot to clear. Each such process held 4 io_uring fds.

Ruled out, each by direct test

Environment variables and preloaded libraries — env -i launch still hung.

User-level configuration — a fresh user account also failed.

io_uring — UV_USE_IO_URING=0 changed nothing; 6/6 identical failures with and without.

Foreground vs background launch — appeared decisive at first, but was an artifact of my own test harness wrapping one arm in timeout and not the other.

disable-hardware-acceleration in argv.json — hung with the setting present and absent.

Unprivileged user namespaces — setting kernel.apparmor_restrict_unprivileged_userns=0, verified effective via unshare --user, did not fix the hang.

--no-sandbox — no effect on the hang in either direction.

Stale profile state — every trial used a fresh mktemp -d as --user-data-dir.

--gtk-version=4 — still hangs, so the GTK3 module is loaded regardless of that flag.

Environment

TUXEDO OS / Ubuntu 24.04, kernel 7.0.0-111030-tuxedo, KDE Plasma 6.6.6 on X11, glibc 2.39, AppArmor 4.0.1.
Cursor 3.20.21-1789329270 — Electron 42.10.0 / Chromium 148.0.7778.280 / Node 24.18.1.
3.18.25 works with identical configuration.

Version	Electron	Result
3.17.8	–	works (from my usage history)
3.18.25	40.10.3	works — measured
3.19.13	–	fails (from my usage history; I rolled back on Sep 8)
3.20.10	42.10.0	fails — measured