Terminal + Version Control doesn't load

[MakoriSM (Makori)]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Entire IDE just hangs when loaded up. Source control doesn’t show and terminals don’t load. Only way to fix was to rollback to an older version but when I restarted my computer it updated automatically and broke again. When this happens I just switch back to vs code and codex because it literally doesn’t work at all.

Steps to Reproduce

On Mac just open a project in cursor 3, it doesn’t happen every time though.

Expected Behavior

The terminal should show text and the version control panel should show something

Operating System

MacOS

Version Information

Version: 3.1.17
VSCode Version: 1.105.1
Commit: fce1e9ab7844f9ea35793da01e634aa7e50bce90
Date: 2026-04-19T19:33:58.189Z
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.4.0

Does this stop you from using Cursor

Yes - Cursor is unusable

[deanrie]

Hey, this is a known issue with Extension Host initialization on 3.1.17. When it doesn’t start in time, Terminal and Source Control stay stuck on loading.

Before reinstalling everything again, try a more targeted workaround. It helped another user on the same version, see Extension Host fails to initialize (Timeout waiting for auth and plugins), breaking AI Agents and Source Control

1. Fully quit Cursor.
2. On macOS, delete (or back up first) the workspace folder for this project from:

   ~/Library/Application Support/Cursor/User/workspaceStorage/
   

   These are subfolders with hashed names. You can find the right one by running grep in workspace.json for your project path, or if you don’t have many workspaces, you can delete everything there.
3. Reopen Cursor and open the project again.

We’re tracking this issue on our side, but I can’t share an ETA for a fix yet. If this helps, let me know, and if you notice any trigger for when it starts happening, like a specific action, extension, or MCP, that would really help narrow it down. If it doesn’t help, reply too and we’ll dig into the logs from Output > Extension Host.

[mlampe (Matt Lampe)]

Thanks for these instructions, I also was having this issue over the last week or some where multiple workspaces weren’t fully loading. Removing the matching workspace folder from that directory seems to have fixed it.

[MakoriSM (Makori)]

This fix works but only for a short while, every time I make the fix it will only stay for about a day before coming back.

Sorry if you guys can’t track it down but I don’t see it happen after any specific action, I’m currently not even using the Agent sidebar. Going to switch to a different IDE as I only was using Cursor anymore for completion anyway and this was unfortunately the final straw.

[deanrie]

Hey, that’s frustrating to hear, and thanks for coming back to share this. It’s a really helpful signal.

The fact that the workaround only lasts about a day and there’s no clear trigger is an important detail. We’re tracking the issue on our side, but I honestly can’t give an ETA for a full fix. The previous fix iteration covered some cases, but yours clearly isn’t one of them.

If you’re willing to help before you go, two things would be really useful:

1. Logs from View > Output > Extension Host (use the dropdown on the right and pick Extension Host) at the moment when everything is stuck.
2. Your list of installed extensions and MCP. Sometimes a pattern shows up when specific plugins overlap.

If not, that’s totally fine, I get it. When we have an update on the fix, we’ll post here so you know when it’s worth coming back.

[Ptorrsmith_JAVLN (Peter Torr Smith (JAVLN))]

Well that’s a pain… deleting the workspaceStorage blows away local settings such as pinned tabs

It seems to me that this issue pops up each time I get a cursor update.

[deanrie]

Yeah, agreed. Deleting workspaceStorage is a pretty rough fix, since that’s exactly where pinned tabs, layout, and other local workspace state are stored.

A couple things that might help:

1. Before deleting it, back up the workspace subfolder you need at ~/Library/Application Support/Cursor/User/workspaceStorage/<hash>/. After Cursor recreates it and starts normally again, you can try restoring specific files from the backup, like state.vscdb. Sometimes this brings back part of your setup without bringing the bug back. No guarantee, but it’s worth a try.
2. The note that it shows up after every update is really helpful, thanks. That matches what we’re seeing in other reports.

We’re tracking the issue and a fix is coming, but I can’t share an exact ETA yet.

[Ptorrsmith_JAVLN (Peter Torr Smith (JAVLN))]

Happened again after the latest Cursor update installed.

I tried the approach to make a copy, but then trying to cherry pick bits so I don’t lose all my settings is a right pain.

Even if I don’t install the upgrade, it gets installed when I next start Cursor and it’s dead in the water and just hangs.

Seems to come back after 3-4 restarts of Cursor,

Can I stop auto-updates until you get a fix for this? Can’t see that option in Cursor Settings (just in VS-Code settings)

[deanrie]

About auto-updates: there’s no toggle for it in the Cursor Settings UI, but the VS Code setting still works. Open Preferences: Open User Settings (JSON) via Cmd+Shift+P and add:

"update.mode": "none"

Options: none means don’t check at all, manual means check but don’t download automatically, start means only check on launch. After this, Cursor won’t pull updates on startup until you choose to update.

On the bug: we’re tracking the extension host issue on our side, but I can’t share an exact ETA yet. I get that the workspaceStorage workaround isn’t great, especially when the bug comes back after another update. If you notice any trigger along the way like a specific extension, MCP, or an action right before it freezes, drop it here. It helps narrow down the cause.

[Ptorrsmith_JAVLN (Peter Torr Smith (JAVLN))]

I’ve set VS Code to “manual” updates, but doesn’t seem to have made any difference. Perhaps not related to the update process.

But I notice when I re-start Cursor, almost every time now, it hangs. No terminal, no git changes UI "No source control loading, pretty much dead. It takes 4-6 restarts of cursor to finally get the terminal and changes to load (or else I have to clear out my workspaceStorage again, which is also disruptive.

This is a show-stopper, is causing much disruption in my work flow, and is forcing me to go back to use OG VSCode to do just basic things (as this does not hang)

I can open the Agents Window and access a terminal and a (difficult to use/understand) change control window there, but not in the main/old Cursor app. The Agents Window is challenging to use / does not support a number of basic things (like managing stashes via the UI), so I need to use the old/main Cursor app (which has been great up until this issue), but it’s now just so unreliable.

[Ptorrsmith_JAVLN (Peter Torr Smith (JAVLN))]

Wondering if this helps at all in your investigations/fix?

Appears nothing to do with any updates as I have them disabled currently.

The suspicious part is the old workspace DB:

/Users/petersmith/Library/Application Support/Cursor/User/workspaceStorage copy 3/d5aa16015e813f28e94bee76c6069dfb/state.vscdb

It contains stale layout/view state for terminal and SCM, for example:

• terminal = {"terminal":{"collapsed":false,"isHidden":true,"size":1596}}

• workbench.scm.views.state has workbench.scm hidden with size:1318

• old-only SCM state: scm.viewState2

• old-only Cursor layout keys like cursor/agentLayout.panelVisible, sidebarVisible, widths/heights, etc.

The fresh DB has much cleaner terminal state and a new key:

• terminal.integrated.layoutInfo = {"workspaceId":"d5aa...","tabs":[...]}

So my read is: this is probably not “database corruption”; the DB passes PRAGMA integrity_check. It looks like bad/stale workspace UI state that Cursor then mishandles, causing terminal/source control views not to initialize.

[deanrie]

This is a really helpful write-up, thanks for digging so deep. Your read matches what we’re seeing. It’s not DB corruption since it passes PRAGMA integrity_check, it’s stale UI state in state.vscdb that gets mishandled during layout restore. That’s why Terminal, Output, and Source Control don’t initialize.

Your surgical workaround is the right direction, and it’s much cleaner than deleting the whole workspaceStorage. With Cursor closed, you only move aside:

.../workspaceStorage/<hash>/state.vscdb
.../workspaceStorage/<hash>/state.vscdb-shm
.../workspaceStorage/<hash>/state.vscdb-wal

and optionally empty-window/state.vscdb. This resets the broken layout state, but keeps extension caches and most settings. You can find the right <hash> by grepping for your project path in workspace.json.

The fact that update.mode didn’t change anything is also an important signal. It means the issue isn’t the update itself, it’s stale state building up over time, which explains why it comes back after 3 to 4 restarts.

One request to fully confirm the chain. Next time it hangs, please send the log from View > Output with the Extension Host channel selected, captured while the panels aren’t loading. That’ll help tie your state.vscdb finding to the exact point where initialization fails.

We’re tracking this issue on our side. I can’t share a firm ETA for a fix yet, but your write-up really helps narrow down the cause.

[Ptorrsmith_JAVLN (Peter Torr Smith (JAVLN))]

Sadly, failing (terminal, SCM) quite frequently on startup. I’ve monitored the “Output” but sadly there is none

I closed cursor and re-opened a couple of times, and it came right… sometimes takes 2-6 restarts, after that if no luck, I delete my workspaceStorage

[deanrie]

Thanks for keeping the reports coming. Even the fact that Output is empty is a useful signal. When there are no panels at all, no Terminal, no SCM, and not a single channel in the Output dropdown, it means layout and panel restore is failing on startup, not just the extension host. That matches what you found with the stale state.vscdb.

That’s also why you won’t see the Extension Host channel in Output. It doesn’t get loaded when this bug hits. But the logs still get written to disk, so we can grab them directly. Next time you catch the stuck state:

1. Open Finder and go to ~/Library/Application Support/Cursor/logs/
2. Open the newest folder by date
3. You’ll see exthost.log and main.log. Please send those from the run where the panels didn’t come back up. If there’s a renderer.log, that’s useful too.

That will tie your state.vscdb finding to the exact point where init fails.

For the workaround, the surgical option is still cleaner than deleting the whole workspaceStorage. With Cursor fully closed, move just state.vscdb, state.vscdb-shm, and state.vscdb-wal in the right <hash>. The fact that 2 to 6 restarts can also fix it fits the stale state idea.

We’re tracking this on our side. Your breakdown really helps narrow down the cause. I can’t share an exact ETA for a fix yet, but I’ll post an update in the thread as soon as I have one.

[Ptorrsmith_JAVLN (Peter Torr Smith (JAVLN))]

Ok, so Cursor was working, so I closed and restarted Cursor this morning, and it froze again.

So I went into the logs folder. I only found a main.log and in a subfolder a renderer.log (attached) but no sign of a exthost.log

renderer.log (6.3 KB)

main.log (538 Bytes)

One other strange thing… you can see the datestamp folders (seem to be UTC based not local?) in the logs folder, the log from right now is 20260610T200430, however I notice there is another folder in there 20260610T223250 which has logs from yesterday (but the datestamp of the folder seems future-dated)

PS: My mention that it seems to come right after a few restarts may not be correct. After 5-6 restart attempts I give up and delete the state.vscdb, state.vscdb-shm and state.vscdb-wal files

[deanrie]

This is super helpful, thanks. renderer.log gave us a new signal.

What it shows: this time the extension hosts actually started (pid 77476-77479, WorktreeManager picked up 2 worktrees). So it’s no longer “ext host didn’t start”. But about 2.5 minutes later the renderer starts spamming:

• No Connect transport provider registered (pricing, privacy mode, repo blocklist)
• No search provider registered for scheme: file, waiting

In plain English: the renderer didn’t register the Connect transport, which is the layer used to talk to backend services. SCM and part of the panel startup depend on it. That’s why Terminal and Source Control get stuck on loading. And that’s also why there’s no exthost.log. The pipeline never reaches full initialization. So your note about empty Output fits this exactly.

One important detail: in your logs folder you have multiple windows (window1, window2_wb0, window3, window4, etc.). Transport registration failures often show up when multiple windows restore at once. Can you test this: when it’s stuck, try keeping only one window and one workspace open. Close the others before launch, then see if it’s more stable. This will tell us if multi-window restore is the trigger.

If you catch the hang again, please zip the full fresh folder from ~/Library/Application Support/Cursor/logs/<date>/ including all the window* subfolders, plus main/renderer, and exthost.log if it appears, then send it here. That way we’ll see the full picture across all windows, not just one.

About the “future” folder dates, that’s expected. The log folder names are in UTC, while Finder’s Modified time is local. So 20260610T223250 is just an older session in UTC format, not a bug.