Long Agent chats keep full history in renderer — need lazy/virtualized message list (Linux, Agents Window)

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Environment

  • Cursor: 3.15.6 (Electron 40)
  • OS: Ubuntu 26.04, KDE Wayland
  • CPU: AMD Ryzen 5 3600 (6C/12T)
  • RAM: ~47 GB available (not memory-starved)
  • Layout: Agents Window (glassMode)

Bug
When Agent chats become long, Cursor UI alone becomes laggy (typing/scrolling). Other apps stay fine. This is not general system overload.

Local measurements on my machine

  • Main UI renderer RSS ≈ 1.9–2.1 GB after a long session, often 10–50%+ CPU while interacting
  • ~/.config/Cursor/User/globalStorage/state.vscdb ≈ 428 MB live data
    • agentKv ≈ 260 MB
    • bubbleId (chat messages) ≈ 121 MB
  • One Agent chat alone: ~2874 bubbles / ~25 MB
  • Several other chats: 400–1100+ bubbles each
  • 102 composer/agent chats total in DB

Expected
Long chats should use list virtualization / lazy loading:

  • Keep only viewport + small buffer mounted in the DOM
  • Unload off-screen message nodes / heavy tool payloads from renderer memory
  • Load older messages on scroll (windowing), instead of keeping the full transcript hot in the UI process

Actual
Long Agent transcripts appear to keep large amounts of chat/tool state resident in the renderer. UI jank scales with chat length / number of open Agent sessions, even with plenty of free system RAM.

Why this matters
Users who work with long Agent sessions hit CPU/UI lag specifically inside Cursor. Workarounds (new chat, Reload Window, Delete Old Chats + GC Agent KV Blobs) help temporarily but do not replace proper chat virtualization.

Request
Please prioritize virtualized Agent chat rendering + eviction of off-screen/heavy tool-call UI state so long chats do not pin multi‑GB renderer/CPU usage.

Steps to Reproduce

  1. Open Cursor Agents Window (glass layout) on Linux (Ubuntu Wayland).
  2. Work in Agent mode on a real project and keep using the SAME chat for a long time (many tool calls, large diffs, long replies). Do not start a new chat.
  3. Continue until the conversation becomes very long (hundreds/thousands of messages / bubbles). On my machine one chat reached ~2874 bubbles (~25 MB of bubble data alone).
  4. Keep that long chat open (and optionally open additional Agent chat tabs/sessions in the same Agents Window).
  5. Interact with the UI: type in the Agent input, switch tabs, scroll the chat history, open/close diffs.
    Observed:
  • Cursor UI becomes laggy/janky (input and scrolling delay).
  • Other desktop apps remain responsive.
  • Process Explorer / system tools show the main Cursor renderer process growing to ~2 GB RSS and using significant CPU.
  • Local store grows large: ~/.config/Cursor/User/globalStorage/state.vscdb ≈ 428 MB (agentKv ≈ 260 MB, bubbleId ≈ 121 MB).
    Expected:
  • Long Agent chats should use virtualized/lazy message rendering (mount viewport + buffer only; unload off-screen / heavy tool payloads; load older messages on scroll) so UI CPU/memory stays stable as chat length grows.
    Workarounds that temporarily help (but are not a fix):
  • Start a new chat for each task
  • Developer: Reload Window
  • Developer: Delete Old Chats… then GC Agent KV Blobs

Operating System

Linux

Version Information

IDE
Version: 3.15.6
VSCode Version: 1.128.0
Commit: a1f686545fd0ce8917bbd2449f733551a9bce420
Date: 2026-08-06T01:41:03.876Z
Electron: 40.10.3
OS: Linux x64 (Ubuntu 26.04, Wayland)

Does this stop you from using Cursor

Yes - Cursor is unusable

7

Hey!

Quick note on the ask: the Agent transcript is already virtualized. Only the visible window plus a small buffer stays mounted, and off-screen messages unload from memory and reload as you scroll. So this isn’t a missing feature. The residual CPU/memory growth on very long single chats is a separate issue we’re tracking, with active work underway.

For now, the workarounds you found are the right ones, biggest lever first:

  1. Keep each task in its own chat. How much transcript/tool state piles up in one conversation is the main driver.
  2. Developer: Reload Window (Cmd/Ctrl+Shift+P) to reclaim renderer memory once a session has ballooned.
  3. Delete Old Chats to trim state.vscdb.

I’ll post here when there’s an update. If you split into shorter chats and it still climbs to multi-GB, reply here and I’ll dig in.