Severe lag on M2 Pro - SQLite deadlock + listener memory leak in v2.5.25

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Hi team, I’m an Ultra subscriber and I’m experiencing persistent lag in the IDE, particularly when scrolling through chats with code blocks (PHP/HTML). The lag is usually quite noticeable — scrolling freezes, typing is delayed, and the IDE becomes sluggish. Sometimes it eases up for a while, but it always comes back. This happens even on fresh, short chats with just a few messages.

My setup is a MacBook Pro M2 Pro with zero extensions installed and no other apps running, so the hardware should not be a bottleneck.

I looked into the logs and found two issues that seem to be causing the problem:

Issue 1: SQLite Transaction Deadlock in AgentAnalyticsOperationsMainService

AgentAnalyticsOperationsMainService attempts to store AI code hashes but hits a deadlock — cannot start a transaction within a transaction — and retries in a loop, producing 77 errors in 32 seconds:

From main.log:

2026-02-25 18:03:59.789 [error] [AgentAnalyticsOperationsMainService] Error storing AI code hashes: SQLITE_ERROR: cannot start a transaction within a transaction
2026-02-25 18:03:59.790 [error] [AgentAnalyticsOperationsMainService] Error storing AI code hashes: SQLITE_ERROR: cannot start a transaction within a transaction
...repeated 77 times in 32 seconds...
2026-02-25 18:04:31.478 [error] [AgentAnalyticsOperationsMainService] Error storing AI code hashes: SQLITE_ERROR: cannot start a transaction within a transaction

Issue 2: Event Listener Leak in Chat Code Block Rendering

The renderer appears to create a Monaco editor model for every code block in chat without disposing the event listeners. They accumulate quickly:

From renderer.log:

2026-02-25 17:10:13.125 [error] [002] potential listener LEAK detected, having 200 listeners already.
2026-02-25 17:10:14.136 [error] [002] potential listener LEAK detected, having 248 listeners already.

200 → 248 listeners in 1 second. Stack trace points to $dc.createModel in workbench.desktop.main.js. This likely explains why chats with more code blocks lag more.

Steps to Reproduce

  1. Open any chat and ask the agent to generate PHP/HTML code
  2. After a few exchanges containing code blocks, scrolling becomes laggy
  3. The more code blocks in the chat, the worse it gets
  4. Check main.log for SQLITE transaction errors
  5. Check renderer.log for listener LEAK warnings

Expected Behavior

The IDE should remain responsive on this hardware, especially with no extensions installed.

Operating System

MacOS

Version Information

Version: 2.5.25
VSCode Version: 1.105.1
Commit: 7150844152b426ed50d2b68dd6b33b5c5beb73c0
Date: 2026-02-17
Electron: 39.2.7
Chromium: 142.0.7444.235
Node.js: 22.21.1
OS: Darwin arm64 25.3.0 (macOS 26.3)

For AI issues: which model did you use?

Opus 4.6

Additional Information

Things I’ve already tried without success:

  • Various GPU flags in argv.json (disable-hardware-acceleration, enable-gpu-rasterization, disable-gpu-compositing, etc.)
  • Disabling visual features (minimap, smooth scrolling, sticky scroll, etc.)
  • Setting CHROME_HEADLESS=1 via launchctl (macOS Tahoe workaround)
  • Increasing JS heap to 8GB via --max-old-space-size=8192
  • Disabling telemetry
  • Clean workspace with zero extensions

Would appreciate any guidance or a fix. Thank you!

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

3

Having the exact same problem but in this case im using typescipt. Not only the scroll and typing lags, also the file explorer and the cursor.

4

Hey, great bug report. It’s exactly what we need to diagnose this.

Both issues you found in the logs look real:

  1. A SQLite deadlock in AgentAnalyticsOperationsMainService. We saw a similar bug before, but based on your logs it looks like it’s back, or it wasn’t fully fixed in 2.5.25.

  2. A listener leak in the chat code block renderer. 200+ listeners per second is definitely not normal, and it explains the growing lag while scrolling.

I’ve shared this with the team along with your logs. No ETA yet, but your detailed report helps us prioritize it.

As a temporary workaround, it may help to start a new chat more often so listeners don’t pile up. I know it’s not a real fix, but it can reduce the lag.

@Santiago_Opazo thanks for confirming. Can you share your Cursor version and OS? That’ll help us understand how widespread this is.