Where does the bug appear (feature/product)?
Cursor CLI
Describe the Bug
Summary
Cursor window renderers steadily accumulate JavaScript heap during Agent/Chat
use until they hit the V8 heap limit and crash
(V8 javascript OOM (Ineffective mark-compacts near heap limit), renderer
exits with SIGTRAP / code 5). 18 crashes over 4 days, across two Cursor
versions. Raising the heap cap 4x only scaled the time-to-crash
proportionally, so this is steady accumulation (~4 GB/hour under heavy Agent
use), not a spike. This looks like the known Chat/Agent UI leak reported by
Windows users (forum topics 147231, 153773) — reporting here as a Linux data
point with a controlled heap-cap experiment.
Environment
Cursor: 3.18.9 (deb package, x64) — also reproduced on 3.17.21
VS Code base: 1.128.0
OS: Ubuntu 26.04, kernel 7.0.0-30-generic, Wayland (GNOME)
Hardware: AMD Ryzen AI 9 HX 470, 64 GB RAM (~45 GB free at crash time),
Radeon 890M iGPU
System RAM is never exhausted: no kernel OOM-killer events, no swap
pressure. The crash is purely the renderer’s internal V8 heap limit.
Crash signature (systemd journal)
cursor.desktop[11550]: [11550:0901/133731.240193:ERROR:third_party/blink/renderer/bindings/core/v8/v8_initializer.cc:920] V8 javascript OOM (Ineffective mark-compacts near heap limit).
cursor.desktop[11393]: [main 2026-09-01T03:37:31.500Z] CodeWindow: renderer process gone (reason: crashed, code: 5)
A few crashes show V8 javascript OOM (CALL_AND_RETRY_LAST) instead — same
heap exhaustion, different allocation site.
Heap-cap experiment
Heap cap
How set
Result
~4 GB (default)
—
Crash every 1–2 h of Agent use; as fast as 20–25 min after a window reload restores a large session
16 GB
–js-flags=–max-old-space-size=16384 (verified on the process command line)
Crash after 4 h 11 min (window spawned 09:26, crashed 13:37)
Time-to-crash scales with the cap → steady ~4 GB/hour leak. After the crash,
the restored window was already back at 1.6 GB RSS within one minute.
Note: js-flags in ~/.cursor/argv.json is silently ignored by this build
(only the CLI argument works). If argv.json support is intentional, the
ignore is itself a minor bug.
Full crash list (local time, AEST)
All are the same V8 OOM → renderer SIGTRAP signature:
Aug 29: 01:32, 23:33 (Cursor 3.17.21)
Aug 30: 00:14, 15:39, 17:11 (3.17.21) — 17:28, 17:52, 21:15, 22:02 (3.18.9)
Aug 31: 06:09, 07:08, 07:57, 14:26, 15:56, 21:35 (3.18.9, default cap)
Sep 1: 06:10, 08:15 (default cap) — 13:37 (16 GB cap)
Usage profile (likely relevant)
Multiple long-running Agent sessions, often several concurrently, including
overnight (crashes at 06:09/06:10 occurred with agent loops active and no
user interaction).
Large agent history: [LocalAgentStorage] found 1526 agent headers.
Multiple windows/workspaces open; only the window hosting the heavy Agent
sessions crashes. Extension hosts stay normal (~100–150 MB) and exit
cleanly when the renderer dies.
Ruled out
OTEL/telemetry leak variant (forum topic 153773): no otel.error /
OTLPExporterError anywhere in logs.
Hardware/OS: 64 GB RAM with ~45 GB free at crash time, no kernel
errors, no OOM-killer involvement; machine passes SMART/thermal checks.
In-place update side effects: crashes occur on long-running instances
with no pending file changes.
Steps to Reproduce
Run a few agents at the same time
Operating System
Linux
Version Information
Version: 3.18.9
VS Code Extension API: 1.128.0
Commit: 2ba48ff3f7514cc4643c52ca9f7b3173d9b66130
Date: 2026-08-27T01:42:22.092Z
Layout: Agent Window
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.291
OS: Linux x64 7.0.0-30-generic
Does this stop you from using Cursor
No - Cursor works, but with this issue