RangeError: Invalid array length in setCardContentReady crashes renderer (code 5) during agent-loop

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor bug report — setCardContentReady / Invalid array length → renderer crash (code 5)

Title

RangeError: Invalid array length in setCardContentReady crashes renderer (code 5) during agent-loop

Environment

Field Value
Cursor version 3.6.31
VS Code engine 1.105.1
Commit 81fcf2931d7687b4ff3f3017858d0c6dee7e2a68
Build date 2026-05-31
OS macOS 26.5 (Build 25F71)
Hardware Mac, 16 GB RAM
Mode Agent loop (agent-loop wakelock active)
Workspace Multi-root (3 folders); not iCloud-exclusive

Summary

During Agent-mode conversations, the renderer crashes with renderer process gone (reason: crashed, code: 5). This is not an OOM kill: system RAM is ~60% free and the largest renderer process is typically 0.5–1.3 GB at crash time. main.log reports reason: crashed, not reason: oom.

Every crash is preceded within ~200–350 ms by the same JavaScript error in the Composer UI:

RangeError: Invalid array length
  at fzx.setCardContentReady (workbench.desktop.main.js:55273:74924)

The failure occurs while re-rendering cumulative Composer card content after a multi-turn agent session — after file writes complete successfully. Ten occurrences on 2026-06-01, identical stack trace every time.

Steps to reproduce

  1. Open Cursor Agent (single chat, activeCount=1).
  2. Turn 1: Run a heavy agent turn — e.g. parallel shell greps across log directories, read multiple files, produce a formatted response with tables/timelines in chat.
  3. Turn 2: Ask the agent to write or update a markdown handoff/document file on disk.
  4. Agent completes tool calls; the file saves successfully.
  5. Within ~10–30 seconds, while the Composer card re-renders the cumulative transcript, the window crashes.

Observed on 2026-06-01 (representative):

  • Crash #8 (session 20260601T130717, 13:11:41): handoff saved 13:11:31, crash 10 s later.
  • Crash #9 (session 20260601T131211, 13:16:11): handoff update in progress, crash during card render (~31 s into turn 2).
  • Crash #10 (session 20260601T131623, 13:19:44): handoff saved 13:19:33, crash 11 s later.

Expected behavior

Agent turn completes; Composer card renders; no renderer crash.

Actual behavior

  1. Invalid array length logged in window*/renderer.log.
  2. ~300 ms later: CodeWindow: renderer process gone (reason: crashed, code: 5) in main.log.
  3. Window shows “terminated unexpectedly (reason: ‘crashed’, code: ‘5’)”.
  4. Work on disk is preserved; crash is UI render failure, not file I/O.

Why this is not the usual code-5 / OOM issue

Typical code-5 reports This bug
Renderer 3–4 GB+, reason: oom Renderer 0.5–1.3 GB, reason: crashed
Long session memory creep Crashes on specific turn pattern (heavy turn 1 + doc write turn 2)
Fixed by new chat / --disable-gpu Reproduced with HW accel on and off; fresh sessions still crash on same pattern
SQLite / analytics errors Consistent setCardContentReady stack; no SQLITE_ERROR in these sessions

Mitigations already tried (did not fix)

  • cursor.inlineDiff.enablePerformanceProtection: true
  • diffEditor.maxComputationTime: 5000
  • files.watcherExclude + search.exclude (broad patterns)
  • Workspace trimmed from 5 roots to 3
  • window.restoreWindows: "one", workbench.editor.limit: 8
  • "disable-hardware-acceleration": true and false in ~/.cursor/argv.json (tested both; crashes on both)
  • Single agent chat (activeCount=1) — not parallel agents
  • No docs-builder build or long background processes inside Cursor during repro

Log evidence (crash #10, session 20260601T131623)

window2_wb1/renderer.log (13:19:44.136):

[error] Invalid array length: RangeError: Invalid array length
    at j0 (workbench.desktop.main.js:36623:28474)
    at lM (workbench.desktop.main.js:36623:28657)
    at fPe (workbench.desktop.main.js:36623:56784)
    at HBr.value (workbench.desktop.main.js:36623:56650)
    at ot._deliver (workbench.desktop.main.js:55:2962)
    at ot._deliverQueue (workbench.desktop.main.js:55:3053)
    at ot.fire (workbench.desktop.main.js:55:3390)
    at fzx._emitDidChange (workbench.desktop.main.js:55273:78120)
    at fzx.setCardContentReady (workbench.desktop.main.js:55273:74924)
    at workbench.desktop.main.js:55370:67674 Invalid array length

main.log (13:19:44.427, ~291 ms later):

[error] CodeWindow: renderer process gone (reason: crashed, code: 5)

Wakelock context (same session, turn 2):

[info] [PowerMainService] Started wakelock id=1 owner=window:2 reason="agent-loop" activeCount=1

Crash count (2026-06-01)

Eight crashes with this signature in retained log sessions:

Time Session Notes
11:39 20260601T112304 After diff guardrail enabled
12:12 20260601T112304
12:27 20260601T112304
12:29 20260601T122737
12:31 20260601T122943
13:11 20260601T130717 Handoff write; file saved before crash
13:16 20260601T131211 Handoff update for crash #9
13:19 20260601T131623 Handoff saved 11 s before crash

Two earlier sessions (20260601T111533, 20260601T111733) also crashed with code 5; log dirs may have rotated.

Not observed: Cursor Helper (Renderer) .ips in DiagnosticReports; jetsam/memory-pressure kills.

Secondary noise (probably unrelated)

Repeated OTLP exporter errors in renderer log immediately before some crashes:

OTLPExporterError: Bad Request — "Trace spans collection is not enabled for this user"

These appear on non-crashing turns too. Including for completeness; primary failure is setCardContentReady.

Suggested fix area

Composer card content assembly in setCardContentReady — likely allocating or indexing an array with an invalid length when cumulative agent transcript + tool output exceeds an internal threshold. Consider bounds checking, chunking, or virtualizing large card content instead of throwing an uncaught RangeError that kills the renderer.

Workaround (until fixed)

  • Keep agent chat responses short; put tables/timelines in files on disk, not in chat.
  • Start a fresh chat after heavy investigation turns instead of continuing the same Composer thread.
  • Avoid multi-turn patterns: heavy parallel tool output (turn 1) → document write (turn 2) in the same chat.

Steps to Reproduce

  1. Open Cursor Agent (single chat, activeCount=1).
  2. Turn 1: Run a heavy agent turn — e.g. parallel shell greps across log directories, read multiple files, produce a formatted response with tables/timelines in chat.
  3. Turn 2: Ask the agent to write or update a markdown handoff/document file on disk.
  4. Agent completes tool calls; the file saves successfully.
  5. Within ~10–30 seconds, while the Composer card re-renders the cumulative transcript, the window crashes.

Expected Behavior

No back-to-back crashes.

Screenshots / Screen Recordings

cursor-bug-report-forum-attachment.txt (2.45 KB)

Operating System

MacOS

Version Information

Version: 3.6.31
VS Code Extension API: 1.105.1
Commit: 81fcf2931d7687b4ff3f3017858d0c6dee7e2a60
Date: 2026-05-31T17:46:29.630Z
Layout: glass
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
xterm.js: 6.1.0-beta.220
OS: Darwin arm64 25.5.0

For AI issues: which model did you use?

Opus 4.8 then after numerous crashes, Auto

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Thanks for the detailed report!

I’ve been investigating this but haven’t been able to reproduce the crash on our end yet. A couple of questions:

  1. Is the Changes/diff panel visible when the crash happens? If you try collapsing or switching away from it before running your agent turns, does the crash still occur?
  2. Do you have uncommitted file changes showing in the Changes panel before starting the agent turn? If so, roughly how many?
  3. Could you share the exact prompts you used? Even approximate wording for Turn 1 and Turn 2 would help us reproduce the same pattern.
7

Thanks for looking into this — happy to add detail. :grin:

Changes / diff panel

I wasn’t actively using the Source Control (Changes) panel during the crashes. My focus was the Agent/Composer panel. I don’t have a log entry confirming whether the Changes sidebar was open or collapsed at crash time.

That said, the renderer error is in Composer card rendering (setCardContentReady), not in the inline diff editor. I already had these settings enabled before and during the crashes:

  • cursor.inlineDiff.enablePerformanceProtection: true
  • diffEditor.maxComputationTime: 5000

Three crashes occurred after those settings went live (11:39, 12:12, 12:27), so I suspect this is separate from the diff/Changes UI — but I haven’t run a controlled test of “collapse Changes panel → run agent turns → see if crash still happens.” I can try that if it would help.

Uncommitted changes before agent turns

Yes — there were uncommitted changes in the workspace, mostly in a secondary root folder (docs-agent), not in the main repo I was working in (documentation-i).

Multi-root workspace (3 folders): documentation-i, docs-agent, ~/.cursor.

Rough counts at the time (from my notes earlier that day):

  • docs-agent: ~423 deleted tracked files + ~160 untracked files (archive/cleanup work, left uncommitted on purpose)
  • documentation-i: a small number of modified files (at least one local rule file showing as modified; no large doc PR branch checked out in that window)
  • ~/.cursor: local-only rule/settings edits (also uncommitted by design)

So the Changes panel would have shown a large change set, but the crash pattern doesn’t seem to depend on me having the panel open — it happened while Composer was re-rendering the agent transcript after the turn completed.

Exact / approximate prompts (best repro case — crash #10**, session 20260601T131623)**

Fresh chat after restart, single agent loop (activeCount=1), no background builds running inside Cursor.

Turn 1 (~40 s, completed cleanly):

investigate latest crashes back to back happened after I asked to create an updated handoff for the latest crashes

That turn triggered many parallel tool calls (log greps across ~/Library/Application Support/Cursor/logs/20260601*, reading handoff markdown files, shell timeline commands) and produced a large formatted chat response with tables.

Turn 2 (~17 s, crashed during card re-render):

yes add crash 9

That turn read the handoff skill + existing handoff file, wrote/updated ~/Documents/docs-agent/handoffs/handoff-2026-06-01-cursor-crash-setCardContentReady.md. File saved at 13:19:33; crash at 13:19:44 (~11 s later). Work on disk was fine — the window died while Composer re-rendered cumulative card content.

Two earlier crashes same day with the same two-turn pattern:

Crash #8 (session 20260601T130717, 13:11:41):

  • Turn 1: “There’s been no crash yet but can you check the most recent ones from the last hour or so and see if you can find anything new or actionable”
  • Turn 2: “no. create a handoff with latest findings and include what steps to take in the next crash.”

Crash #9 (session 20260601T131211, 13:16:11):

  • Turn 1: “you were writing a handoff for the crash issue when cursor crashed again. there have been no crashes until that so check what could have triggered it”
  • Turn 2: “yes to all then let me know when i can restart” (update handoff + flip hardware acceleration in argv.json)

All three show the same signature in logs:

RangeError: Invalid array length at fzx.setCardContentReady (workbench.desktop.main.js:55273:74924)
→ ~300 ms later → renderer process gone (reason: crashed, code: 5)

Environment reminder: Cursor 3.6.31, VS Code 1.105.1, build 2026-05-31, macOS 26.5, 16 GB RAM. Not OOM (~60% RAM free; renderer ~0.5–1.3 GB). HW acceleration tested both on and off.

Happy to run the “collapse Changes panel first” experiment and report back, or attach another log pair if useful.