Silent crash for cli

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

I’ve hit a silent crash of the cursor cli while running bazel builds within skaffold I don’t have a particular repro, just noticed that sometimes it crashes without a long stacktrace or anything. Seems different than what I’ve experienced before for long chats that hit heap memory issues.

Steps to Reproduce

  1. Start cli
  2. Run bazel builds across many terminal sessoins
  3. Eventually it’ll die?

Operating System

Linux

Version Information

│ │
│ About Cursor CLI │
│ │
│ CLI Version 2026.03.25-933d5a6 │
│ Model GPT-5.4 1M High │
│ OS linux (x64) │
│ Terminal tmux │
│ Shell zsh │
│ Last Request ID 2f63091e-fba6-4975-8447-90d8f950edcd │

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

4

have had it a lot more in the latest version, 143 is the error code I managed to pull out

6

you know what this might be our oomkiller.

8

Hi @philkuz,

Good call on the OOM theory. Exit code 143 = SIGTERM (signal 15), which narrows it down: the kernel OOM killer sends SIGKILL (exit 137), so this is most likely a userspace OOM handler like systemd-oomd or earlyoom killing the process under memory pressure from your bazel builds.

After the next crash, can you check:

  1. systemctl status systemd-oomd — is it active on your system?

  2. journalctl --user -u systemd-oomd --since "1 hour ago" — any kill events?

  3. dmesg | tail -50 — any OOM entries around the crash time?

Also helpful: approximate total system RAM and the number of concurrent tmux sessions/builds running when it happens.

If it is systemd-oomd, you can raise the memory pressure threshold or exclude your user scope from its monitoring to stop it from terminating the CLI during heavy builds.