I get ‘Extension host terminated unexpectedly 3 times within the last 5 minutes’ every time I start Cursor. Options are ‘Start Extension Bisect’ and ‘Restart Extension Host’. I’ve tried both and the issue remains.
I seem to be able to use agents for a variety of tasks, but anything related to git is failing it looks like. The Changes panel is stuck on ‘Loading changes’ and it’s unable to retrieve git details.
This is the latest version 3.20, and I tried downgrading to 3.18, but the issue is still there.
Steps to Reproduce
Unsure about this one. It’s my Cursor instance.
Expected Behavior
That the error doesn’t appear and that the Changes panel loads.
Hey, thanks for the detailed report and screenshots. I can see both the stuck Changes panel on “Loading changes” and the error prompt itself.
Quick summary of what’s happening: the process that hosts Cursor’s built-in extensions is crashing, including git, which is why the Changes panel never finishes loading. It crashes a couple seconds after starting, then hits the “3 times in 5 minutes” limit. Since downgrading to 3.18 didn’t help, this likely isn’t a Cursor version issue, but something on the machine or in the opened project. That’s also why Extension Bisect or Restart Extension Host didn’t fix it.
Let’s narrow it down. Please follow these steps in order and tell me after which exact step the notification stops showing up:
Fully close Cursor. Right-click the tray icon and click Quit, then check Task Manager to make sure there are no Cursor processes left.
Launch Cursor, then in the Agents Window open a brand new empty folder as the project. Create it on your Desktop. Wait 2 minutes. Does the notification show up?
Close Cursor again, relaunch it, and open your usual project in the classic editor window using Open IDE from the Agents Window. Wait 2 minutes. Does it show up there?
If yes, in that same window press Ctrl+Shift+P, run Extensions: Disable All Installed Extensions, then Ctrl+Shift+P and run Developer: Reload Window. Does it still show up?
After that, in the window where it keeps crashing, press Ctrl+Shift+P and run Developer: Capture and Send Debugging Data with the default options. With your privacy setting, it will save a zip locally and show the path. Please attach that zip here.
One more thing. Did anything change on the machine around September 13, like cloning a new repo, setting up WSL, installing antivirus, or a Windows update? That can help narrow it down.
Thanks, the logs cleared it up. The cause is that the Grep Service code index crashes while loading a cached index for exactly one repo, tuniciousv2. Other projects in the same session load fine. The extension host that crashes also takes down the built-in Git extension, so the Changes panel gets stuck on “Loading changes”. This isn’t related to the Cursor version, so downgrading to 3.18 didn’t help. The on-disk cache is the same either way.
What to try:
Fully quit Cursor. Check Task Manager to make sure there are no Cursor processes left.
Delete the folder C:\Users\biggs\webdev\tuniciousv2\.git\cursor\crepe. You can delete the whole .git\cursor folder too. It’s only Cursor cache and won’t affect Git history.
Open the project again. The index will rebuild from scratch.
Let me know if it helped.
If the crash happens again after rebuilding on a fresh index, the trigger is likely in the working tree itself. It could be something in the diff from recent commits or in untracked files. Your git status shows about 3237 entries. In that case, please send the output of:
I’m especially interested in junction or symlink loops and very deeply nested folders. From that list we can identify a specific file and exclude it via .cursorignore.
I’ve passed the indexing-side issue to the team and we’re tracking it. I’ll post here if there’s an update.
Deleting the .git\cursorfolder did not do the job.
I opened the git repo in Sublime Merge and noticed a tons of backups\firestore-2026-07-09\... files unstaged on main. I deleted them all and got a ‘too long filename’ error, but they were all removed. Then I pulled from main again.
Everything is working fine now.
I had run the Get-ChildItem -Recurse -Attributes ReparsePoint you asked me to before and this was the output of that:
PS C:\Users\biggs\webdev\tuniciousv2> Get-ChildItem -Recurse -Attributes ReparsePoint
Get-ChildItem : Could not find a part of the path 'C:\Users\biggs\webdev\tuniciousv2\backups\firestore-2026-07-09\users\HLxlL3xwLKMumpHf9FVYMsxNlNw1\users\HLxlL3xwLKMumpHf9FVYMsxNlNw1\u
sers\HLxlL3xwLKMumpHf9FVYMsxNlNw1\users\HLxlL3xwLKMumpHf9FVYMsxNlNw1\users\HLxlL3xwLKMumpHf9FVYMsxNlNw1\users\HLxlL3xwLKMumpHf9FVYMsxNlNw1'.
At line:1 char:1
+ Get-ChildItem -Recurse -Attributes ReparsePoint
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ReadError: (C:\Users\biggs\...pHf9FVYMsxNlNw1:String) [Get-ChildItem], DirectoryNotFoundException
+ FullyQualifiedErrorId : DirIOError,Microsoft.PowerShell.Commands.GetChildItemCommand
Great, glad we got it sorted out. And thanks for writing down what exactly worked, it’ll help other users who run into the same thing.
Confirmed on our side: it was that deeply nested recursive tree backups\firestore-2026-07-09\...\users\<id>\users\<id>\... that was breaking the indexer. The path went past the Windows path length limit and sent the native directory traversal into infinite recursion, which then crashed the extension host. Since the built-in Git extension runs in the same host, the Changes panel also got stuck on “Loading changes” forever. This isn’t related to the Cursor version, so rolling back to 3.18 didn’t help because the cache and on-disk files were the same.
For the future: if you put similar Firestore exports or backups into the repo again, add this folder to .cursorignore so the indexer won’t scan it:
backups/
We’re tracking the underlying issue that the indexer should handle these pathological deep structures without crashing. If there’s an update, I’ll post it here. Let me know if anything pops up again.
