# \[CLI\] agent SIGILL (V8 invalid opcode) during Ink/TUI render on long --resume **URL:** \ **Category:** Bug Reports\ **Tags:** cli, crashes\ **Created:** [September 23, 2026, 9:52pm UTC](https://forum.cursor.com/t/cli-agent-sigill-v8-invalid-opcode-during-ink-tui-render-on-long-resume/172826 "2026-09-23T21:52:17Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![Che\_Signup](https://avatars.discourse-cdn.com/v4/letter/c/da6949/32.png) [@Che\_Signup](https://forum.cursor.com/u/Che_Signup)\ **Post date:** [September 23, 2026, 9:52pm UTC](https://forum.cursor.com/t/cli-agent-sigill-v8-invalid-opcode-during-ink-tui-render-on-long-resume/172826/1 "2026-09-23T21:52:17Z")
### 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 ---
**Author:** ![mohitjain](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/mohitjain/32/100229_2.png) [@mohitjain](https://forum.cursor.com/u/mohitjain)\ **Post date:** [September 24, 2026, 6:43am UTC](https://forum.cursor.com/t/cli-agent-sigill-v8-invalid-opcode-during-ink-tui-render-on-long-resume/172826/7 "2026-09-24T06:43:55Z")
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 ` → `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.