Cursor is not loading on both of my Mac's - keeps infinitely loading

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

In both my work and personal Macbooks, Cursor just infinitely loads without opening anything.
Clearing the cache and the extension cache in Application Support works, but after a restart, it’s broken again.

Steps to Reproduce

Open Cursor

Expected Behavior

To Open Cursor

Screenshots / Screen Recordings

image.png
image.png1861×1236 82.1 KB

Operating System

MacOS

Version Information

Version: 3.2.11
VSCode Version: 1.105.1
Commit: e9ee1339915a927dfb2df4a836dd9c8337e17cc0
Date: 2026-04-24T14:36:47.933Z
Layout: editor
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
OS: Darwin arm64 25.3.0

Does this stop you from using Cursor

Yes - Cursor is unusable

5

same to me on both Windows and Mac. Restart PC helps, of restart Cursor 3-10 times also helps.
For me, start reproducing a few days ago

6

image
image1516×754 57.8 KB

Will this help solve the problem? Actually, things starting with “cursor” always seem to cause problems.

7

Hey, thanks for the report. We can see the screenshot with the loader stuck.

Darwin 25.3.0 = macOS Tahoe 26.3. There was a known freeze on Tahoe in 3.0.x, fixed in 3.1.14 plus macOS 26.4. Since you’re already on 3.2.11 and you’re hitting this again, it’s either a regression or a separate bug where the local DB grows over time (which would explain why only clearing the cache helps).

Can you help narrow it down:

  1. Check the size of state.vscdb:
ls -lh ~/Library/Application\ Support/Cursor/User/globalStorage/state.vscdb*

If it’s gigabytes, that’s almost certainly the cause. Try deleting only state.vscdb and state.vscdb.backup (make a backup first), not the whole Application Support/Cursor, and see if the fix lasts longer.

  1. Run with extensions disabled:
cursor --disable-extensions

Does it still reproduce?

  1. After it freezes again, share a fresh main.log from ~/Library/Application Support/Cursor/logs/ (the most recent folder by time).

  2. Is macOS Tahoe updated to 26.4+ now? Apple menu > About This Mac.

@Andreeas, the same diagnostics would be useful for you too. What Cursor version and macOS or Windows version are you on, and does deleting only state.vscdb help instead of doing a full restart?

8

@deanrie

  1. Following is the response
1.2G Apr 27 11:37 /Users/me/Library/Application Support/Cursor/User/globalStorage/state.vscdb
32K Apr 27 16:13 /Users/me/Library/Application Support/Cursor/User/globalStorage/state.vscdb-shm
2.8M Apr 27 16:13 /Users/me/Library/Application Support/Cursor/User/globalStorage/state.vscdb-wal
1.2G Apr 27 11:37 /Users/me/Library/Application Support/Cursor/User/globalStorage/state.vscdb.backup
20B Apr  8 10:49 /Users/me/Library/Application Support/Cursor/User/globalStorage/state.vscdb.options.json
  1. cursor --disable-extensions fixes this

What would be a permanent fix for this?

9

Okay, if --disable-extensions fixes it, the issue is in some extension, not in state.vscdb. Also, 1,2 GB is actually abnormal, normal size is about 20 to 30 MB, and there’s a known issue where cursorDiskKV grows without control. But that’s separate from your crash.

About state.vscdb: don’t delete it. Deleting the global state.vscdb can cause an endless Loading Chat… in all projects, and that’s a documented bug. Instead, rename it to state.vscdb.old and keep it in the same folder. Cursor will create a new file, and if chats become unavailable you can roll back. You can delete the backup state.vscdb.backup after you rename the main file.

To find the culprit extension:

  1. Run Extension Bisect: Cmd+Shift+P then type Help: Start Extension Bisect. Cursor will disable half your extensions and ask if the bug still happens. In about 5 to 10 rounds, it will find the extension that causes it.

  2. Or use Process Explorer: Cmd+Shift+P then Developer: Open Process Explorer. Check which extensionHost is using lots of CPU or memory during startup.

  3. Once you find the extension, post its name and version here. If you can, also export logs: Cmd+Shift+P then Developer: Export Logs, then attach Window, Extension Host, and Main.

About a permanent fix: until we know which extension it is, I can’t give an exact answer. If it’s a popular one, it’s probably already reported and there’s work in progress to make it compatible with Cursor 3.x.

Andreeas and Anveena, same for you. Run cursor --disable-extensions and on Windows run cursor.exe --disable-extensions from a terminal. If the issue goes away, run Extension Bisect and share which extension is responsible.

10

esbenp.prettier-vscode Unbelievable, to me, this problematic plugin is actually it.

11

--disable-extensions is not working anymore.
I renamed state.vscdb and had to login again.
After logging in Cursor is stuck on a blank Loading.... screen @deanrie

Edit: Got through loading screen, but IDE is stuck like before now, infinite loading on top

12

@Dave_Howson, let’s dig in. The 1,2 GB size is that known bloated DB issue. It’s in the backlog and we don’t have an ETA for a fix yet. The part where it’s stuck on an empty Loading screen after renaming state.vscdb and logging in again is a different stage. It’s more likely something is blocking startup while restoring the session or workspace, not the DB itself.

Try this in order:

  1. Force quit completely. In Activity Monitor, kill all Cursor and Cursor Helper processes, not just Cmd+Q.

  2. Check if esbenp.prettier-vscode is installed. Anveena found via Extension Bisect in this same thread that it breaks startup. If it’s installed, delete this folder:

rm -rf ~/.cursor/extensions/esbenp.prettier-vscode-*
  1. Start with a clean window and no workspace restore:
cursor --disable-extensions --new-window

Don’t open any folder, just see if an empty window shows up.

  1. If it’s still stuck on blank Loading, rename the whole Cursor folder so it starts with a totally clean state:
mv ~/Library/Application\ Support/Cursor ~/Library/Application\ Support/Cursor.bak

Launch Cursor, log in, and check if it works. If it opens, you can slowly copy back what you need from Cursor.bak/User/ like settings.json, keybindings.json, snippets, and check after each file that Loading doesn’t come back.

  1. If Cursor still gets stuck even with a fresh folder, send a new main.log from ~/Library/Application Support/Cursor.bak/logs/ from the most recent folder. Then I can check what it’s hanging on.

@Anveena, thanks for the great detective work with Extension Bisect, that really helps. esbenp.prettier-vscode is not compatible with the current extension host in Cursor 3.x. As a workaround, use the built-in formatter or an alternative like Prettier ESLint until there’s a compatible version. What version of prettier-vscode are you on?

@Andreeas, same steps for you. What Cursor version and OS are you on, and does cursor --disable-extensions help. On Windows, run cursor.exe --disable-extensions from a terminal. If it helps, run Extension Bisect Cmd+Shift+P then type Help: Start Extension Bisect and tell us which extension it finds.

13

Prettier is removed.
cursor --disable-extensions --new-window works, but as soon as I open my workspace, it’s stuck in the loading screen

Moving all of cursor settings to .bak and opening fresh works.
I don’t want to restore even at this point. Clean state is fine.
Only issue is, this works for now, but will eventually fail again I’m sure, as this has happened many times before.

14

@Dave_Howson, ok, the symptoms changed. If an empty window opens but a specific workspace freezes the IDE, then it’s not the global state.vscdb. It’s workspace specific storage. Each workspace stores its state in ~/Library/Application Support/Cursor/User/workspaceStorage/<hash>/, and it can grow on its own. This is a known pattern with bloat in workbench.find.history and cursorDiskKV.

Try this step by step, don’t wipe everything:

  1. Run this to find large workspace folders:
du -sh ~/Library/Application\ Support/Cursor/User/workspaceStorage/* | sort -h | tail -20

If something is in the hundreds of MB or in GB, that’s a good candidate.

  1. Match the hash to your workspace using the workspace.json file inside that folder:
cat ~/Library/Application\ Support/Cursor/User/workspaceStorage/<hash>/workspace.json
  1. Once you find the right workspace, rename the folder, don’t delete it:
mv ~/Library/Application\ Support/Cursor/User/workspaceStorage/<hash> ~/Library/Application\ Support/Cursor/User/workspaceStorage/<hash>.bak

Open the workspace again. Cursor will create a fresh folder.

  1. If the workspace freezes again after some time, grab two main.log files during the freeze, one from just before and one from just after, from the newest folder in ~/Library/Application Support/Cursor/logs/. Those logs usually show what the startup is getting stuck on.

No ETA on a real fix for the bloat yet, but locally this keeps the workspace usable without doing a full wipe.

15

I did all the above. The workspaceStorage directory of the workspace that I’m getting stuck on was 165MB.
I moved the json to a backup and still the same result.
main.log for this after the move is

2026-05-07 09:25:17.242 [info] updateURL https://api2.cursor.sh/updates/api/update/darwin-universal/cursor/3.2.16/37c1c9a8a92d77d29ec43b3eb3a47b07e1accb1e08cd954e2b7b1cf7289222bb/stable
2026-05-07 09:25:17.244 [info] update#setState idle
2026-05-07 09:25:18.815 [info] [Tray] getMacOSIconPath: hasNotifications: false
2026-05-07 09:25:45.695 [info] update#setState checking for updates
2026-05-07 09:25:46.565 [info] UpdateService onUpdateAvailable()
2026-05-07 09:25:46.565 [info] update#setState downloading
2026-05-07 09:26:34.959 [info] UpdateService onUpdateDownloaded()
2026-05-07 09:26:34.959 [info] update#setState downloaded
2026-05-07 09:26:34.960 [info] update#setState ready
16

For now, rm -rf ~/Library/Application\ Support/Cursor/User/workspaceStorage/ seems to solve this for me.