Glass renderer OOM: text models / working copies never released

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Version: 3.20.17 (commit 0c32194e3fb5ffaced9fb36430b860ec301e1fc0, stable)
OS: Fedora Linux, Wayland
When: 2026-09-16 01:31:36 WEST

What happened

The glass window renderer (pid 790635, --type=renderer) died after being up since 11:23 the previous day. The main process stayed up.

Heap: used=3912.3MB limit=4096.0MB Mark-Compact (reduce) 3912.3 (4010.5) → 3912.3 (4010.5) MB, last resort; GC in old space requested V8 javascript OOM (Reached heap limit). CodeWindow: renderer process gone (reason: crashed, code: 132)

Exit code 132 is SIGILL, which is V8’s fatal OOM path, not a bad CPU instruction. The kernel did not OOM-kill it. RSS had climbed from about 1.2 GB at 11:23 to a plateau around 6.7–7.0 GB from midnight. Last-resort GC freed nothing, so the heap was still referenced.

Why

workbench.glass.main.js creates a text model per file (ModelService._createModelData → new oF) and the model reference is not released. Each model adds an onDidChange listener. The renderer log has 3,081 potential listener LEAK detected errors from 12:00 to 01:31, every one this stack:

at new oF (workbench.glass.main.js:228:34972) at lYl._createModelData (workbench.glass.main.js:20771:2522)

After a restart at 09:23 the same window immediately logged:

Potential working copy LEAK detected, having 513 working copies already. Most frequent owner (258): file#
at nYl.acquire (workbench.glass.main.js:53:3802) at nYl.doCreateReferencedObject (workbench.glass.main.js:20750:30948)

So this is not one huge file. Glass is retaining hundreds of file working copies for the life of the renderer. Extension-host document refs (ZVf, 3 min / 80 MB / 50 refs) are not the holder. The holder is nYl / E3t.references in the glass renderer.

This was a glass window (Extension isolation is disabled (forced disabled in glass mode)), with agent loops running for hours. The lighter glass window the day before leaked 99 times in 22 hours and did not die.

Request

Please dispose file-model references when the working copy is not dirty and not attached to an editor. A forced GC cannot fix this. We confirmed last-resort GC reclaimed 0 bytes.

Steps to Reproduce

Steps to Reproduce

Cursor 3.20.17, glass mode (extension isolation forced off). Linux, Wayland.
Do not reload the window during the run. Reload is the only thing that clears the set.

Build the leaked set

  1. Open one glass window.
  2. Run local agent loops that read and edit files. In our case this ran from 11:23 on 15 Sep through 01:31 on 16 Sep, and materialized several workspaces (Census, Canvas, grok-science, enterprise-release-20260908, LawScrape, ArXiv, and others). No special setting. Agent-host topology was the legacy in-window path.
  3. Leave that window up. Do not run Developer: Reload Window.

Observe

  1. Tail ~/.config/Cursor/logs/<session>/window*/renderer.log.
  2. Within minutes, potential listener LEAK detected starts firing. Every stack is new oF → ModelService._createModelData in workbench.glass.main.js. We logged 3,081 of these over 13.5 hours.
  3. The renderer RSS climbs and does not come back down. Ours went from ~1.2 GB at 11:23 to ~6.7–7.0 GB by midnight, then sat there.
  4. At 01:31:36 the renderer dies:
    • Heap: used=3912.3MB limit=4096.0MB
    • last-resort Mark-Compact reclaims 0 bytes
    • V8 javascript OOM (Reached heap limit)
    • CodeWindow: renderer process gone (reason: crashed, code: 132)

Shorter check, after the set already exists

  1. Quit Cursor and start it again. Do not open a file by hand.
  2. About 8 seconds after the glass window starts, the same log shows listener leaks, then:
    Potential working copy LEAK detected, having 513 working copies already. Most frequent owner (258): file#<no typeId>
    Stack: nYl.acquire → nYl.doCreateReferencedObject → text-file resolve → _createModelData.
  3. That was 09:23:24 on 16 Sep, with no agent prompt sent yet. The copies are restored with the window, not created by a new prompt.

Expected

File-model references acquired for an agent read are released when the tool finishes, or at least when the model is not dirty and not attached to an editor. Restarting Cursor should not re-acquire hundreds of working copies before the user does anything. GC should be able to reclaim the heap.

Actual

References stay in nYl / E3t.references for the life of the renderer. Restart re-acquires them immediately. Last-resort GC frees nothing. The renderer hits the 4096 MB V8 heap cap and aborts.

Operating System

Linux

Version Information

Cursor IDE 3.20.17 (stable)
Commit: 0c32194e3fb5ffaced9fb36430b860ec301e1fc0
VS Code: 1.128.0
Date: 2026-09-12T03:16:10.634Z
Build: x64
OS: Linux 7.2.5-200.fc44.x86_64 (Fedora 44, Wayland)

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

6

Hey @PedroACFerreira, thanks for the detailed report.

What you traced is right! Each file the agent edits keeps a text model open while its change is still pending review, and those pending changes are saved with the workspace and reloaded when the window starts, which is why the working copies come back before you send a prompt. This is a known issue we are already tracking, and I have added your report to it.