# Cursor IDE fails to launch since version 3.19 - Electron version? **URL:** \ **Category:** Bug Reports\ **Tags:** linux, crashes, installation\ **Created:** [September 11, 2026, 12:30pm UTC](https://forum.cursor.com/t/cursor-ide-fails-to-launch-since-version-3-19-electron-version/171347 "2026-09-11T12:30:03Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![sgy](https://avatars.discourse-cdn.com/v4/letter/s/3bc359/32.png) [@sgy](https://forum.cursor.com/u/sgy)\ **Post date:** [September 11, 2026, 12:30pm UTC](https://forum.cursor.com/t/cursor-ide-fails-to-launch-since-version-3-19-electron-version/171347/1 "2026-09-11T12:30:03Z")
### 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): 1. upgrade cursor to version \> 3.18 (apt) 2. attempt to launch 3. 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 > > ```auto > 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: > > - 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//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): > > ```auto > 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: > > ```auto > 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 ---
**Author:** ![Colin](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/colin/32/90452_2.png) [@Colin](https://forum.cursor.com/u/Colin)\ **Post date:** [September 13, 2026, 10:26am UTC](https://forum.cursor.com/t/cursor-ide-fails-to-launch-since-version-3-19-electron-version/171347/5 "2026-09-13T10:26:16Z")
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: ```bash 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: ```bash env | grep -iE 'GTK|GIO|GDK|GLIB|LD_|QT_|XDG_CURRENT_DESKTOP|XDG_SESSION' ``` ```bash 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: ```bash 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. ---
**Author:** ![sgy](https://avatars.discourse-cdn.com/v4/letter/s/3bc359/32.png) [@sgy](https://forum.cursor.com/u/sgy)\ **Post date:** [September 17, 2026, 1:23pm UTC](https://forum.cursor.com/t/cursor-ide-fails-to-launch-since-version-3-19-electron-version/171347/7 "2026-09-17T13:23:57Z")
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: ```auto .config/gtk-3.0/settings.ini; ``` Specifically, the line: ```auto 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: ```auto 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 > > ```auto > 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: > > ```auto > abi , > include > > profile cursor /usr/share/cursor{/bin,}/cursor flags=(unconfined) { > userns, > include if exists > } > > ``` > > 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: > > > > ```auto > > 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 > > > > 1. Running under `sudo` booted reliably; as my own user it never did. > > 2. 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. > > 3. Bisected `$HOME` by building synthetic home directories containing progressively smaller subsets, launching once per subset. This reached `.config/gtk-3.0/settings.ini`. > > 4. 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. ---
**Author:** ![system](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/system/32/99069_2.png) [@system](https://forum.cursor.com/u/system)\ **Post date:** [September 20, 2026, 9:01am UTC](https://forum.cursor.com/t/cursor-ide-fails-to-launch-since-version-3-19-electron-version/171347/12 "2026-09-20T09:01:58Z")
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.