[CLI] agent SIGILL (V8 invalid opcode) during Ink/TUI render on long --resume

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

Interactive Cursor Agent CLI (agent / cursor-agent) can abort during a long --resume session while redrawing the terminal UI. The process exits with Illegal
instruction (core dumped). The kernel reports an invalid-opcode trap inside the bundled node binary (consistent with a V8 ud2 abort). A captured V8 stack
points at Ink/TUI rendering (get() building the char grid → Yoga layout → onImmediateRender / onRender → processImmediate), not at user tool/shell code. RSS
was ~1.1 GiB at the SIGILL. Related CLI deaths under similar conditions: SIGSEGV and glibc malloc(): mismatching next->prev_size → Aborted.
NODE_OPTIONS=–report-on-fatalerror did not produce a report.*.json for the SIGILL.

Steps to Reproduce

  1. On Linux x86_64, run interactive Agent CLI in a terminal (e.g. tmux).
  2. Start or --resume a large/long-lived chat and leave it working with the TUI updating (spinner / screen repaints).
  3. Keep the session running until RSS grows large (on the order of ~1 GiB observed).
  4. Observe the process die with Illegal instruction (core dumped) (sometimes after prior SIGSEGV / malloc aborts in earlier runs).

Note: not a reliable one-shot repro; correlates with long --resume + heavy TUI redraw, not a specific user script.

Expected Behavior

The CLI should keep running (or fail with a clear, non-fatal error) instead of aborting during TUI paint. If a fatal V8 error is unavoidable, it should exit
cleanly and, when report flags are set, write a Node diagnostic report.

Operating System

Linux

Version Information

About Cursor CLI

CLI Version 2026.09.23-86fc751
Latest 2026.09.23-86fc751 (up to date)
Model Grok 4.6 Medium
Subscription Tier Pro+
OS linux (x64)
Terminal tmux
Shell bash

Additional Information

Summary
cursor-agent / agent CLI aborts with SIGILL (Illegal instruction (core dumped)) during interactive TUI rendering on a long-lived --resume session. Kernel logs this as an invalid opcode trap inside the bundled node binary (consistent with V8 intentional ud2 abort), not a host OOM.

Also observed related crashes in the same CLI process family: SIGSEGV, and glibc heap abort (malloc(): mismatching next->prev_size).

Environment
OS: Linux x86_64 (Ubuntu 24.04)
CPU: AMD Ryzen (x86_64)
Cursor Agent CLI versions observed: 2026.09.18-9a7762b (primary SIGILL); also SIGSEGV around auto-update / cleanup-install-versions on newer builds
Bundled runtime: Node from the agent package under ~/.local/share/cursor-agent/versions//node
Invocation: interactive terminal (e.g. tmux), agent --resume / long-running session
Process RSS at SIGILL: ~1.1 GiB
Reproduction (approximate)
Run interactive agent / cursor-agent in a terminal for a long session (or --resume a large chat).
Leave it running with active TUI updates (status spinner / screen redraws while working).
Eventually the process dies with Illegal instruction (core dumped) (sometimes preceded by Segmentation fault or malloc abort on other runs).
Not reliably one-shot reproducible; correlates with large RSS + TUI repaint, not with a specific user tool/script.

Actual behavior
Shell prints:

Illegal instruction (core dumped)
Kernel (sanitized):

traps: MainThread[] trap invalid opcode ip: sp: error:0 in node[,…]
V8 stack at abort (sanitized / truncated) shows Ink/TUI render, not tool execution:

get() building a terminal character grid (index.js ~line 414 region; char cells / styles)
Yoga layout path (yogaNode / render helpers)
onImmediateRender / onRender
processImmediate (node:internal/timers)
So the abort happens while painting the terminal UI.

Expected behavior
CLI should not abort the process during TUI render.
If a fatal V8 error occurs, prefer a recoverable error / clean exit, and ideally emit a Node diagnostic report when --report-on-fatalerror is set (currently often no report.*.json for this SIGILL path).
Notes
–report-on-fatalerror --report-directory=… was set via NODE_OPTIONS; no report file was produced for the SIGILL abort.
Same environment has also seen SIGSEGV and malloc heap corruption aborts from the CLI under similar long-session conditions.
This report intentionally omits hostnames, usernames, absolute home paths, chat IDs, and project/workspace contents.
Ask
Please investigate V8 abort / Ink render path under large --resume sessions, and whether TUI get()/yoga render can trigger fatal abort when the session heap is large.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

Hey @Che_Signup,

One thing that’ll save you time: this isn’t the process running out of JavaScript memory (that path prints a heap out of memory line and writes the report before exiting), so --max-old-space-size / --report-on-fatalerror won’t catch it. What would really help: on the next crash, paste the line just above the ==== JS stack trace ==== block (it starts with # Fatal error, # Check failed:, or abort:), or a native backtrace via coredumpctl gdb <PID> → bt. Please don’t upload the core file itself — it can contain your chat and project contents.

In the meantime, starting a fresh chat instead of resuming a very large one (and NO_COLOR=1) should make it much less frequent.

This isn’t intended behavior and it’s not on your end - we’ve let the team know, and I’ll follow up here when there’s an update.