Cursor freezes/crashes ~1min after launch (PluginsProviderService blocking main thread)

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor consistently becomes unresponsive 40-90 seconds after launch. The window either crashes (SIGSEGV) or self-recovers after ~60-70 seconds of being fully frozen. Reproduced across multiple days and multiple plugin configurations, always with the identical stack trace:

at workbench.glass.main.js:14718:17403
at Array.map ()
at nDw (workbench.glass.main.js:14718:17399)
at workbench.glass.main.js:14718:16181
at Array.map ()
at XPw (workbench.glass.main.js:14718:16151)
at ZPw (workbench.glass.main.js:14718:16422)

Cursor’s own logs show PluginsProviderService’s startup scan is already slow even on non-crashing runs:
getPluginMcpServers took 1752.8ms / 7144.8ms
getPluginHooks took 1873.6ms

This points to a race: plugin scanning (getPluginMcpServers/getPluginHooks) plus other startup work (update check, LocalAgentStorage scan) runs synchronously on the main thread, and occasionally the combined blocking time exceeds the ~15s unresponsive-detection threshold.

Steps to Reproduce

  1. Have several Cursor Plugins installed (reproduced with 6-13 installed; frequency scales with plugin count but is not deterministic per plugin).
  2. Launch Cursor normally.
  3. Wait 40-90 seconds without interacting.
  4. Window becomes unresponsive; Electron logs “CodeWindow: detected unresponsive”, then either an UnresponsiveSampleError/crash, or “CodeWindow: recovered from unresponsive” after ~60-70s.

Ruled out via isolated tests (each with a clean ~110s+ launch window):

  • state.vscdb size (trimmed 5GB → 1.1GB, still hung)
  • GPU/Wayland (–disable-gpu, still hung)
  • Corrupted profile (fresh --user-data-dir, no hang)
  • Moving ~/.cursor (MCP/plugins config) aside entirely → fixed it
  • Moving only ~/.cursor/plugins aside → fixed it
  • A single bad plugin → git fsck clean on all installed plugin repos; binary-searched subsets, no single plugin or fixed combination reproduced deterministically

Expected Behavior

Cursor should remain responsive during startup regardless of how many Plugins are installed or how large the local state database is. Plugin/MCP scanning work should not block the main/renderer thread long enough to trip the unresponsive-window watchdog.

Operating System

Linux

Version Information

Cursor 3.17.8, commit 2fdd31c9f33f7fbe501f2d57772dc5bf64b63620
Electron 40.10.6 (electron40-bin, system package)
Arch Linux, Wayland, kernel 7.1.9-zen1-2-zen
Installed via AUR cursor-bin

Additional Information

Happy to share full main.log captures and coredumpctl SIGSEGV entries on request.

Separately noticed: state.vscdb’s cursorDiskKV table accumulates unbounded chat-history (bubbleId:/checkpointId:) and cache (agentKv:blob:) entries with no apparent garbage collection — mine had grown to 5GB with 3.8GB in agentKv:blob: entries that weren’t referenced anywhere else in the database. Worth adding periodic GC/pruning, as larger state.vscdb likely adds to the startup blocking time.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

5

Hey @maxik, thanks for the report!

Could you attach the main.log from a frozen session (~/.config/Cursor/logs/<latest folder>/main.log) and one of the coredumpctl SIGSEGV entries?

7

Hi Colin,

Reproduced it just now. Attached: main.log from the crash session (identical stack trace as before), and a combined file with the coredumpctl metadata + journal excerpt.

Important finding: there’s still no core file, but this time I know exactly why — systemd-coredump’s own log shows the process hit a 17GB memory peak right before the SIGSEGV (“Consumed 14.405s CPU time over 20.422s wall clock time, 17G memory peak”). That’s larger than my available disk space (and also larger than I could upload here), so no core dump can be written regardless of storage config.

This changes my read of the bug: I don’t think this is primarily a “PluginsProviderService is slow” issue anymore. A ~17GB memory footprint right before the freeze/crash looks like a leak or runaway allocation, and the nested Array.map hang is likely just GC/memory-pressure-induced main-thread blocking, not the plugin scan itself being slow. Plugin count may just correlate with how much extra state/data accumulates rather than being the root cause.

Is there a way to get an in-app heap snapshot or memory profile instead (e.g. via Help > Toggle Developer Tools > Memory, or a --trace-memory-usage-style flag)? That would probably be more useful than a raw core dump at this point.

main-repro-crash.log (1.5 KB)

crash-metadata.txt (2.0 KB)

30

Hey @maxik! Your read was right, this is memory pressure, not the plugin scan itself.

Your data helped us pin down the paths involved: very large payloads crossing between Cursor’s internal processes (including large outputs from plugin-provided MCP tools) on top of accumulated local chat state. Both are known issues we’re tracking and working on, and your findings have been added to them.

One last thing that would help confirm your specific case, if you’re up for it: open the Command Palette (Cmd/Ctrl + Shift + P), run Capture and Send Debugging Data and tick the Renderer heap snapshot option in the picker. Best timing is about 20-30 seconds after launch, while memory is climbing but before the window locks up.