Kills entire GNOME session (Linux)

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor memory exhaustion kills entire GNOME session (Linux)

Steps to Reproduce

  1. Ask the Cursor agent to read a link (web page) or an image in chat.
  2. The window freezes (renderer blocked ~19 s, confirmed by Cursor’s own RendererPing log).
  3. Memory usage of the Cursor scope grows to ~19 GB.
  4. System enters memory pressure; systemd-oomd kills the session.

Screenshots / Screen Recordings

cursor-oom-journal-2026-07-14.log (38 KB)

Operating System

Linux

Version Information

Version: 3.11.19
VS Code Extension API: 1.125.0
Commit: bf249e6efb5b097f23d7e21d7283429f0760b740
Date: 2026-07-12T21:39:24.175Z
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.256
OS: Linux x64 6.8.0-134-generic

For AI issues: which model did you use?

Auto

Additional Information

Bug report: Cursor memory exhaustion kills entire GNOME session (Linux)

Summary

Cursor’s renderer process memory balloons when the agent reads a link or image in chat.
On a 32 GB RAM laptop this exhausted system memory twice in one day. The second time,
systemd-oomd killed not only Cursor but also gnome-shell and dbus, terminating the
whole desktop session (user is thrown back to the login screen and loses all in-progress
agent work). From the user’s perspective it looks like the notebook rebooted.

Environment

  • Cursor: 3.11.19 (commit bf249e6efb5b097f23d7e21d7283429f0760b740), x64
  • OS: Ubuntu 24.04, kernel 6.8.0-134-generic, GNOME on Wayland
  • Hardware: Avell laptop, 32 GB RAM, NVMe SSD
  • Swap at the time of the incident: 2 GB (Ubuntu default swapfile)
  • Multiple Cursor windows open (5+ renderer windows), each running agent sessions

Reproduction pattern (as experienced by the user)

  1. Ask the Cursor agent to read a link (web page) or an image in chat.
  2. The window freezes (renderer blocked ~19 s, confirmed by Cursor’s own RendererPing log).
  3. Memory usage of the Cursor scope grows to ~19 GB.
  4. System enters memory pressure; systemd-oomd kills the session.

Evidence (journalctl, 2026-07-14)

Incident 1 — 12:31, kernel OOM killer kills a Cursor process:

12:31:12 cursor.desktop[5845]: No ptyHost heartbeat after 6 seconds
12:31:33 kernel: Out of memory: Killed process 6265 (cursor) total-vm:1461774276kB, anon-rss:561684kB
12:31:33 systemd[3486]: app-gnome-cursor-5845.scope: Failed with result 'oom-kill'.

Note the virtual memory size: ~1.4 TB total-vm for a single cursor process.

Incident 2 — 16:21–16:23, systemd-oomd kills the whole session:

16:21:08 cursor.desktop[52077]: [RendererPing] window 1 (pid 52182) blocked for ~18953ms
16:21:12 cursor.desktop[52077]: [RendererPing] window 5 (pid 52222) blocked for ~18952ms
16:21:14 cursor.desktop[52077]: No ptyHost heartbeat after 6 seconds
16:23:27 cursor.desktop[52077]: [RendererPing] window 3 (pid 52202) blocked for ~19894ms
16:23:30 systemd-resolved[1301]: Under memory pressure, flushing caches.
16:23:30 systemd[3486]: app-org.chromium.Chromium-52077.scope: systemd-oomd killed some process(es) in this unit.
16:23:30 systemd[3486]: [email protected]: systemd-oomd killed some process(es) in this unit.
16:23:30 systemd[3486]: dbus.service: systemd-oomd killed some process(es) in this unit.
16:23:30 systemd[3486]: app-gnome-cursor-52077.scope: systemd-oomd killed some process(es) in this unit.

systemd-oomd top candidate at kill time:

Path: /user.slice/.../app-org.chromium.Chromium-52077.scope
Pressure: Avg10: 34.01 Avg60: 29.74
Current Memory Usage: 18.8G

(The Chromium-52077 scope is Cursor: same PID as cursor.desktop[52077].)

Full raw journal extract attached: cursor-oom-journal-2026-07-14.log

Impact

  • Loss of the entire desktop session and all unsaved/in-flight agent work.
  • Because gnome-shell and dbus die, the user perceives it as a spontaneous reboot.
  • Happened twice in one day during normal agent usage (reading links/images).

Suggestions

  1. Cap or monitor renderer/agent memory when fetching links/images; fail the fetch
    gracefully instead of growing unbounded.
  2. Show a warning in the UI when a Cursor window exceeds a memory threshold
    (RendererPing already detects the 15 s block threshold — memory could piggyback on it).
  3. Consider setting ManagedOOMMemoryPressure/oom_score_adj so that systemd-oomd
    prefers killing the offending Cursor renderer instead of escalating to the session.
  4. Installer/docs tip for Linux: recommend adequate swap (Ubuntu’s default 2 GB swapfile
    on a 32 GB machine gives systemd-oomd almost no headroom before it kills the session).

Does this stop you from using Cursor

Yes - Cursor is unusable

7

Hey there,

This is a real client-side issue, not your setup. Reading a link or image in chat can spike a window’s memory, and on Linux there’s a second problem: under that pressure systemd-oomd can take down the whole session (gnome-shell + dbus) rather than just Cursor. I’ve reported both parts to our team. Reducing renderer memory growth during heavy agent use is already an area we’re working on.

What should help in the meantime:

  1. Run fewer windows/agents at once. Each Cursor window is one process with a shared memory budget, so 5+ windows each running agents concentrates all of it into one process.
  2. Add system headroom. On a 32 GB machine the default 2 GB swap gives systemd-oomd almost nothing before it kills the session - a larger swap file (or zram) makes that collateral session-kill much less likely.
  3. Start fresh chats for long runs, restart Cursor periodically, and close unused tabs.

If it reproduces reliably, the most useful thing for us: right when memory spikes after reading a link/image, run Developer: Capture and Upload Renderer Heap Snapshot (Cmd/Ctrl+Shift+P) and share the reference, plus a note on what you were reading (link vs image, rough size). More here: Reporting bugs