Cursor intermittently loses all source control integration after the system has been shut down for an extended period. The Source Control panel shows:
“No source control providers registered”
The issue is resolved by deleting the workspaceStorage folder, indicating corrupted or invalid workspace state.
Steps to Reproduce
Open a project with a Git/Bitbucket repository in Cursor
Shut down the computer for an extended period (e.g., overnight)
Restart the system and reopen Cursor
Open the Source Control tab
Expected Behavior
The Git repository should be detected and source control features should be available.
Operating System
Windows 10/11
MacOS
Linux
Version Information
Observed since at least version 2.6.22 through 3.1.17
Hey, thanks for the report. This is a known issue. The Extension Host doesn’t initialize after a long idle period, so the built-in Git extension doesn’t start and the SCM view shows “No source control providers registered”. Deleting workspaceStorage is a known workaround.
We’re tracking this internally, but there’s no ETA for a fix yet. To add your case to the report, please send logs:
Command Palette Ctrl+Shift+P > Developer: Open Logs Folder
Zip and attach it here. We need the Window, Main, and Extension Host sections
Also helpful to know:
Your OS. Your report lists all three, so please confirm which one you reproduced this on
Next time you hit the bug before deleting workspaceStorage, grab logs right away. That’s the most useful
When I open some of my projects, Cursor does not work.
The IDE opens, but it claims that “No source control providers registered”, I can’t see the terminals and agent is unreachable. When I try any prompt it keeps loading for some time and then times out on “Agent Execution Timed Out”. It offers to “Reload the Window” but it usually doesn’t work (sometimes, very randomly it does help).
Then sometimes it helps to restart Cursor several times, or trying to open working projects (which is also random) and then re-opening the ones that faced this issue initially. But these gymnastics are unpleasant. I need to open the project and start working.
Steps to Reproduce
Just open the Cursor IDE with the last project it remembers, or open any other project that faces this issue (most do).
Expected Behavior
I open the IDE with the last project, or I open any of the project and it just works. I can see the git history, the terminals and agents are responsive.
If codex is also running close both then only start Cursor, fixxed for me after many restart attempts on Cursor only. Have a great day.
Edit: AI Answer below
Summary
If Codex and Cursor both use VS Code-style workspace state, extensions, Git watchers, or shared workspace metadata, closing both and starting only Cursor can help because:
Codex may keep file watchers or Git processes alive.
Cursor may reopen with stale workspace state after sleep/shutdown.
Both tools may read/write related workspace cache/state.
Long shutdown/sleep can leave invalid extension host or Git provider state.
Starting Cursor alone forces a cleaner extension/Git initialization path.
But this is probably a workaround, not the root fix.
Because deleting workspaceStorage fixes it, the real issue is likely corrupted/stale Cursor workspace state, not the repository itself.
If Git appears, then Codex/shared state or lingering processes may contribute. If it still fails, the bug is inside Cursor workspace storage / Git extension activation.
Experienced the same issue today on macOS 26.3.1 (a) (25D771280a), Cursor Version 3.2.16 (Universal), with Codex enabled. Once Codex was completely uninstalled from my computer and Cursor was restarted, the IDE started working as usual. Before that, it was throwing the same errors other users mentioned in the thread.
Hey, I get it. If it crashes on every launch, that really blocks you from getting work done. We’re tracking the issue, but to add your case to the report we need a bit more info:
Your OS and Cursor version: Help > About
Do you have the Codex extension installed, or any other AI extensions? A few users in this thread said disabling Codex fixed it:
Logs from when it happens, before deleting workspaceStorage: Ctrl+Shift+P > Developer: Open Logs Folder, zip it and attach it here. We need the Window, Main, and Extension Host sections
Since it happens every time, these logs are extra useful and should help the team pin down the root cause.
One more request: before deleting workspaceStorage, please collect logs Ctrl+Shift+P > Developer: Open Logs Folder, zip them, and attach them here. We need the Window, Main, and Extension Host sections. After clearing, it’s harder to reproduce the issue, and the logs really help the team find the root cause.
I have the Codex standalone application (not the extension). But regardless, I don’t think the extension is the issue because I’m pretty sure I’ve had this error even why trying to launch Cursor with extensions disabled - not something I’ve done in a while since I now default to launching cursor with my script instead of messing around with other ways.
Logs attached - I just did the latest update which relaunched Cursor and the error is still there. So Version: 3.6.31 (Mac OS Latest)
Hey, thanks for the logs, they really help. The logs match a known pattern on macOS: Extension Host spawns but stays silent, then you get a cascade of timeouts git context provider → MCP → No Connect transport provider registered. And your point about Codex is right, the issue reproduces even without the extension, so the Codex extension isn’t the root cause. The workaround turn off Codex helps some users, but the problem is broader.
We’re tracking the issue, but there’s no ETA for a fix yet.
To add the most useful data to the report, it’d be great to also get:
The contents of ~/Library/Application Support/Cursor/logs/ from the same run. It contains Cursor Helper (Plugin).log for the exthost processes. In the archive you sent, we only had the Developer Logs Folder, and these Helper logs can show exactly what Extension Host is stuck on at startup.
If you hit the bug again before deleting workspaceStorage, please run sample <exthost-pid> and if you can, also lsof -p <exthost-pid> on the stuck process. This is the most valuable part, it shows where it’s hanging.
Optional crash reports or a sysdiagnose from the same time window.
Once you’ve got it, drop it here. If we get an update on the fix, I’ll reply in the thread.
Hey, I get it, losing 15 minutes every time to restart the window really gets in the way, especially for basic stuff like Git.
For now, a more reliable workaround than looping Reload Window is to delete workspaceStorage (it’s best to back it up first, it contains state.vscdb with chat history):
Windows user install: %APPDATA%\Cursor\User\workspaceStorage
We’re tracking the issue on our side, but honestly I can’t share an exact ETA for a fix yet.
To add your case to the report and help the team get to the root cause, please send:
Your OS and Cursor version Help > About
Logs captured before deleting workspaceStorage: Ctrl+Shift+P > Developer: Open Logs Folder, zip it and attach it here. We need Window, Main, and Extension Host
If you’re on macOS, also include ~/Library/Application Support/Cursor/logs/ from the same run (it has Cursor Helper (Plugin).log, which shows what the Extension Host is stuck on)
Logs captured at the moment the bug happens before clearing storage are the most valuable. Once there’s an update on the fix, I’ll reply in the thread.
Hey, thanks for the report. Yeah, this is the same known issue. Extension Host doesn’t initialize on startup, so the built-in Git extension doesn’t launch and the SCM panel shows No source control providers registered. We’re tracking it, but we don’t have an exact ETA for a fix yet.
Your workaround open the project in VS Code, sync, then launch Cursor is helpful, thanks for sharing. A more reliable workaround than looping Reload Window is to delete workspaceStorage (best to back it up first, it contains state.vscdb with chat history). On Linux the path is usually:
~/.config/Cursor/User/workspaceStorage
Since you’re the first user in this thread on Linux Ubuntu (before this it was only Windows and macOS), your data will be especially helpful for the team. If you hit the bug again before deleting workspaceStorage, please send logs:
Ctrl+Shift+P > Developer: Open Logs Folder, zip it and attach it here. We need the Window, Main, and Extension Host sections
Exact Cursor version: Help > About
Your Ubuntu distro and kernel version
Logs captured at the moment the bug happens, before clearing storage, are the most valuable. I’ll post an update in the thread once we have a fix.