Linux OOM kills Cursor: shellcheck children in Cursor cgroup reach ~27GiB RSS during agent-loop

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

On Linux, Cursor is repeatedly killed by the kernel OOM killer. The desktop
notification blames app-org.chromium.Chromium-.scope, but that systemd
scope is Cursor itself (Electron), not the Chromium browser.
Root cause from journalctl: one or more shellcheck processes (ShellCheck
extension timonwong.shellcheck + /usr/bin/shellcheck 0.11.0) run inside
Cursor’s cgroup and allocate pathological RAM (~11–27 GiB RSS, ~1 TiB
virtual). The kernel kills shellcheck; systemd then SIGKILLs all cursor
processes in the scope. Peak scope usage ~28 GiB RAM + ~29 GiB swap on a
31 GiB machine.
This correlates with Agent (agent-loop wakelock) on a workspace with many
large Bash scripts (~549 *.sh under ~/w/serv-vidy).

Steps to Reproduce

  1. Install Cursor 3.12.30 on Ubuntu 26.04 (31 GiB RAM).
  2. Enable extension timonwong.shellcheck (shellcheck 0.11.0 available).
  3. Open a workspace with many large Bash scripts (tens of KiB each; hundreds of files).
  4. Start an Agent chat and work (edit/open .sh files so ShellCheck lints).
  5. Within minutes to ~2 hours: system OOM; Plasma shows
    “Falta de memória evitada” for app-org.chromium.Chromium-.scope;
    Cursor window dies / is SIGKILL’d.

Expected Behavior

  • A runaway shellcheck/linter child must not take down the entire IDE.
  • Child tools should be in a separate cgroup or have MemoryMax so OOM is
    limited to the linter.
  • systemd/desktop app id should be co.anysphere.cursor / “Cursor”, not
    org.chromium.Chromium (misleading notifications).
  • Agent-loop should cancel extreme child RSS instead of dying with the scope.

Screenshots / Screen Recordings

Operating System

Linux

Version Information

Cursor: 3.12.30 (stable)
Commit: 63a2996a10d9e476b6c28e951dd7691d9c0cf480
OS: Ubuntu 26.04 LTS (Resolute Raccoon)
Kernel: Linux 7.0.0-28-generic x86_64
RAM: 31 GiB + 32 GiB swap
Extensions: timonwong.shellcheck-0.39.5-linux-x64, mads-hartmann.bash-ide-vscode-1.43.0
shellcheck: 0.11.0-2 (Debian/Ubuntu package)

For AI issues: which model did you use?

Agent mode. Crash-time model name is not stored in local requestTraces;
please resolve via Request ID below.
This follow-up / diagnostic chat used: Cursor Grok 4.5.

For AI issues: add Request ID with privacy disabled

18ee323f-9961-4185-a0cb-c96109a7778a

Additional Information

Repeated same-day OOMs (all shellcheck inside Cursor scope):

  • 10:51 scope …-3133 ~24 GiB shellcheck; scope peak 28.3G / swap 28.1G
  • 11:10 scope …-26949 ~11 GiB shellcheck; peak 28.4G / swap 28.7G
  • 11:29 scope …-33830 ~21 GiB shellcheck; peak 28.8G / swap 29.2G
  • 12:04 scope …-43598 shellcheck pid 47472 ~26.1 GiB anon-rss;
    5 concurrent shellcheck PIDs; then 12:06 scope peak 27.9G / swap 28.6G;
    Killing process 43598 (cursor) SIGKILL
    Kernel: “cursor invoked oom-killer”; memcg=
    /user.slice/…/app-org.chromium.Chromium-43598.scope
    flatpak uninstall org.chromium.Chromium → not installed (false lead).

Does this stop you from using Cursor

Yes - Cursor is unusable

Hey, thanks for the detailed report. The journalctl logs, versions, and Request ID really help. From your screenshots I can see the OOM notification for app-org.chromium.Chromium-43598.scope, and the system monitor showing 30.3 GiB RAM with swap fully used.

I’ll break this into two parts.

  1. What you can fix right now (main thing). The memory blow-up is not coming from Cursor, it’s from shellcheck 0.11.0. Since 0.9 it enabled dataflow or extended analysis, and on large scripts it can balloon to tens of GiB RSS. You have about 549 large .sh files, and bash-ide-vscode runs shellcheck on every edit, which is a classic trigger. Two options:
  • Disable extended analysis globally. Add this to ~/.shellcheckrc:
    extended-analysis=false
    
    Upstream reports say this can drop peak memory from about 30 GB to about 4 GB.
  • Or disable the timonwong.shellcheck extension for this workspace if linting those scripts isn’t critical.

Start with ~/.shellcheckrc, it’s likely enough to stop the OOMs.

  1. About your expected points (Cursor side). You’re right overall. A runaway linter child process shouldn’t be able to take down the whole IDE, and on Linux we do have a known gap around isolating child processes. It’s tracked on our side, but I can’t share an ETA. The misleading scope name org.chromium.Chromium instead of Cursor is also a known cosmetic Electron desktop integration artifact. It’s not real Chromium, so your flatpak uninstall finding nothing makes sense.

Let me know if the ~/.shellcheckrc change helped. I’d like to confirm the peak memory drop on your workspace.