Sometimes when we open the IDE it shows loading ui at the top and gets stuck with that, the branches name at the bottom are not visible, even on the changes tab it shows No source providers registered.
Steps to Reproduce
It’s random but frequent whenever I open a project that hasn’t loaded in few hours or a closed project it goes into loading state.
Expected Behavior
It should show the branch name and github repository it’s attached with and it should not show the loader at top
These are subfolders with hash-like names. You can find the right one by running grep for your project path in workspace.json. If you only have a few workspaces, you can delete everything there.
Open Cursor and the project again.
We’re tracking this issue on our side, but I can’t share an ETA for a fix yet. If the workaround helps, let me know. If it doesn’t, please tell me too, and we’ll look at the logs from Output > Extension Host. Also, if you notice any trigger like a specific action, extension, or MCP, that would really help narrow it down.
On my side I’ve had theses “episodes” of Cursor completely lagging and the git panel loading more or less daily. It seems to be triggered when a lot (let’s say 10+) files are in “review” after an agent has ran ? Not sure if there is any connection but I have prettier on staged files configured and its seems maybe be linked.
Hey, this is the same known bug with the Extension Host timeout on 3.1.17. We’re already tracking it on our side, and there’s no ETA for a fix yet.
Your hint about review files and running prettier on staged files is helpful, and it might be one of the triggers. To add this to the ticket, a few questions:
When the git panel gets stuck, can you open Output > Extension Host and Output > Log (Window) and share the last lines? I’m especially interested in anything with TIMEOUT or extension host.
What exact pre-commit hook are you using, husky + lint-staged, or just prettier --write? Also, about how many files are staged when it happens.
Your Cursor version from Cursor > About, and your macOS version.
For now the workaround is the same as above: fully quit Cursor, delete ~/Library/Application Support/Cursor/User/workspaceStorage/ for the affected workspace, then open it again. If Developer: Reload Window from the Command Palette via Cmd+Shift+P helps faster, that’s also a useful signal.
I have attached the logs you asked for + a screenshot of what I had going on (not much). It started hanging at the end seemingly when the git tool calls were made.
In the log files, I have only copied an extract, but it was spamming the same content for ~5 minutes until it finally settled.
Hey, thanks, the logs are really helpful. I can see the root cause in them: Cursor’s main process is hitting the file descriptor limit, so it can’t spawn child processes, including ps for process monitoring every second. That’s why you’re seeing lots of EMFILE errors, and as a result the Extension Host becomes unresponsive and the git panel freezes.
Cursor spawns ps every second to monitor extensionHost processes, and together with file watchers on a large monorepo plus husky/lint-staged plus a couple of agents, it looks like you’re exhausting the default macOS ulimit -n.
Can you check this and try raising the limit:
In a normal terminal, run ulimit -n. This is the soft limit for shells, but Cursor inherits the limit from the process that launched it, usually launchd.
For GUI apps on macOS, the limit is set via launchctl limit maxfiles. You can temporarily raise it with:
sudo launchctl limit maxfiles 524288 524288
Then restart Cursor with a full quit, not just Reload Window.
When it happens again, in another terminal you can check how many FDs the Cursor process has open:
lsof -p <Cursor main pid> | wc -l
If it’s close to the limit, that confirms the hypothesis.
The pattern where the main process does spawn ps is on our radar, it’s known behavior. I can’t share an ETA for an optimization yet.
If raising maxfiles makes your sessions stable, let me know. That’s a useful signal.
These are subfolders with hash-like names. You can find the right one by running grep for your project path in workspace.json. If you only have a few workspaces, you can delete everything there.
Open Cursor and the project again.
I’ve created created a shell script that will do this for you:
#!/bin/bash
#
# cursor-clear-workspace.sh
# Backs up Cursor workspaceStorage folders matching a given repo name.
#
# Usage: ./cursor-clear-workspace.sh <repo-name>
# Example: ./cursor-clear-workspace.sh some-repo-name
set -euo pipefail
# --- Check argument ---
if [ $# -ne 1 ]; then
echo "Usage: $0 <repo-name>"
exit 1
fi
REPO_NAME="$1"
WORKSPACE_DIR="$HOME/Library/Application Support/Cursor/User/workspaceStorage"
BACKUP_DIR="$HOME/cursor-workspace-backup/$(date +%Y%m%d-%H%M%S)-$REPO_NAME"
# --- Sanity checks ---
if [ ! -d "$WORKSPACE_DIR" ]; then
echo "Error: workspaceStorage not found at:"
echo " $WORKSPACE_DIR"
exit 1
fi
cd "$WORKSPACE_DIR"
# --- Find exact matches (path segment match, not substring) ---
MATCHES=$(grep -lE "[/\"]${REPO_NAME}[/\"]" */workspace.json 2>/dev/null || true)
if [ -z "$MATCHES" ]; then
echo "No workspaces found matching '$REPO_NAME'."
exit 0
fi
# --- Show matches and confirm ---
echo "Found the following workspace(s) matching '$REPO_NAME':"
echo "$MATCHES" | while read -r match; do
folder=$(dirname "$match")
project=$(grep -oE '"folder"[^,}]*' "$match" || echo "(unknown)")
echo " - $folder $project"
done
echo
read -r -p "Move these to backup at $BACKUP_DIR? [y/N] " CONFIRM
if [[ ! "$CONFIRM" =~ ^[Yy]$ ]]; then
echo "Aborted."
exit 0
fi
# --- Back up ---
mkdir -p "$BACKUP_DIR"
echo "$MATCHES" | while read -r match; do
folder=$(dirname "$match")
mv "$folder" "$BACKUP_DIR/"
echo "Moved $folder -> $BACKUP_DIR/"
done
echo
echo "Done. Backup location:"
echo " $BACKUP_DIR"
echo
echo "Next steps:"
echo " 1. Fully quit Cursor (Cmd+Q)."
echo " 2. Reopen your project."
echo " 3. If it didn't help, restore with:"
echo " mv \"$BACKUP_DIR\"/* \"$WORKSPACE_DIR/\""
@sawongam On Linux the pattern is similar, but the workspaceStorage path is different. Try the same workaround:
Fully close Cursor.
Delete or back up ~/.config/Cursor/User/workspaceStorage/ (you can remove the whole folder if you only have a few workspaces. Otherwise find the right one by checking workspace.json via grep).
Reopen the project.
If it still doesn’t help, please share:
Your Cursor version Cursor > About and your Arch build info (kernel and DE).
The last lines from Output > Extension Host and Output > Log (Window), especially anything with TIMEOUT, EMFILE, or extension host unresponsive.
Whether you use husky or lint-staged, big monorepos, lots of active file watchers, anything that could increase the number of open file descriptors.
We’re tracking this issue, but I can’t share an ETA for a fix yet.
Cursor version: 3.5.17
Commit: d5b2fc092e16007956c9e5047f76097b9e626ca0
OS: Arch Linux
Kernel: 7.0.9-arch1-1
DE/WM: Hyprland
Git: 2.54.0
Repo: normal git clone, git status works in terminal
ulimit -n: 524288
Cursor Git.log shows repository opened and git status runs successfully, but SCM UI does not show changes / cannot diff /
cannot commit / branch switching UI broken.
Renderer log:
Extension host (LocalProcess [role: user] pid: 373507) is unresponsive.
Extension host (LocalProcess [role: user] pid: 380154) is unresponsive.
+1, git history, TS server doesnt load at all, need to restart cursor IDE for several times, 2-5, than it starts working like it should be. I really dont understand, how to fix it. Using windows11
Hey @elyigar13, @vvvvv21, thanks for the reports. This is the same family of Extension Host bugs that’s being discussed earlier in the thread. The issue is being tracked, but I can’t share an exact ETA for a fix yet.
@elyigar13: I described a Linux workaround in this post Cursor IDE unable to load the Github branches - #16 by deanrie fully close Cursor, delete or back up ~/.config/Cursor/User/workspaceStorage/ (or just the specific workspace folder, you can find it by running grep for your project path in workspace.json), then reopen the project. You already set ulimit -n 524288, so it’s not the FD limit. To add your case to the ticket, please send the last lines from Output > Extension Host and Output > Log (Window), especially anything with TIMEOUT, EMFILE, or extension host unresponsive. Also confirm if you have husky or lint-staged, a large monorepo, or lots of file watchers.
@vvvvv21: On Windows the path is different: %APPDATA%\Cursor\User\workspaceStorage\. Fully close Cursor (and check in Task Manager that no processes are left), delete or back up the workspace folder, then reopen the project. If it reproduces, please share:
Cursor version via Help > About and your Windows version
The last lines from Output > Extension Host and Output > Log (Window) that include TIMEOUT or extension host unresponsive
Any antivirus, corporate proxy, or VPN, since those can affect Extension Host initialization
If the workaround makes sessions stable, let me know. That’s a useful signal for the ticket.
This issue is still happening on Mac, hasn’t been fixed, lost 3 hours trying to make it work. Should be fixed and taken care off this is super annoying. This was a known bug on April 22nd, it’s June 9th and hasn’t been patched.
Hey, thanks for the report, and I’m sorry you lost so much time. That kind of thing can really throw you off.
This is the same Extension Host bug family that’s being discussed earlier in the thread. We’re tracking it on our side, but I can’t share an exact ETA for a fix yet.
What helps right now, this workaround was confirmed by another user on macOS:
Fully quit Cursor using Cmd+Q, then make sure there are no Cursor processes still running.
Delete or back up the workspaceStorage folder for the affected workspace:
These are subfolders with hash-like names. You can find the right one by running grep for your project path inside workspace.json. If you don’t have many workspaces, you can delete everything in there.
Reopen the project.
Post #13 has a ready-to-run shell script that does this with a backup, if you’d rather automate it.
To add your case to our tracking, please send:
Your Cursor version from Cursor > About and your macOS version.
The last lines from Output > Extension Host and Output > Log (Window), especially anything with TIMEOUT, EMFILE, or extension host unresponsive.
Whether you’re using husky or lint-staged, a large monorepo, or lots of active file watchers, these can be potential triggers.
Let me know if the workaround makes your sessions stable.
Hey, Omarchy is based on Arch, so a Linux workaround should apply. It’s the same Extension Host issue that’s discussed in the thread above. The issue is being tracked, but there’s no exact ETA for a fix yet.
Try this:
Fully quit Cursor and make sure there are no Cursor processes still running.
Delete or back up the workspace folder at ~/.config/Cursor/User/workspaceStorage/. You can find the needed subfolder by running grep for your project path in workspace.json. If you only have a few workspaces, you can remove everything in there.
Open the project again.
Another common trigger is closing Cursor while a git diff (working tree) file is open. On the next launch it can get stuck on loading. Before restarting, switch to a normal file, not a git diff view.
If it happens again, please share:
your Cursor version Cursor > About, plus your kernel version and DE/WM
the last lines from Output > Extension Host and Output > Log (Window), especially anything with TIMEOUT, EMFILE, or extension host unresponsive
whether you use husky or lint-staged, a large monorepo, or lots of active file watchers
Hey everyone. Since this thread was active, we’ve made a bunch of changes in this area, especially around Source Control and the terminal getting stuck on loading when opening a window, and freezes when reopening a project that restores the git diff tab. These changes are already in the latest stable release 3.16.x.
Can you check if the loading hang still happens on the latest version? If it’s gone, no need to reply. If you can still reproduce it, please share a few details and we’ll take another look:
your Cursor version from Cursor > About and your OS
the last lines from Output > Extension Host and Output > Log (Window), especially anything with TIMEOUT, EMFILE, or extension host unresponsive
whether you use husky or lint-staged, a large monorepo, or lots of active file watchers
