Extension Host fails to initialize (Timeout waiting for auth and plugins), breaking AI Agents and Source Control

Nikola_Spiric · April 20, 2026, 5:04pm

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

The Cursor Extension Host completely stalls during startup, which prevents AI agents, source control, and all extensions from loading. The issue persists across standard cache wipes and running with disabled extensions. Performing a hard reset by deleting the ~/.cursor directory temporarily resolves the issue, but the host eventually degrades and fails again after a short period of use in the workspace.

Steps to Reproduce

Open Cursor and load the affected workspace.

Wait for the editor to initialize.

Observe the AI Agent panel and Source Control tab.

Open Developer Tools and review the Extension Host and Console logs.

Expected Behavior

The extension host initializes successfully within a few seconds. Source control registers the git repository and AI agents are fully responsive.

Screenshots / Screen Recordings

Operating System

Linux

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: Linux x64 6.17.0-20-generic

Additional Information

Console log states the following:

workbench.desktop.main.js:46036 [TerminalExecutionServiceProxy] v3 health check failed after 6838ms: Error: Extension host not ready after 10 attempts (6838ms elapsed)
    at mVd._createSessionWithRetry (workbench.desktop.main.js:46036:6255)
    at async mVd._healthCheckV3 (workbench.desktop.main.js:46036:4933)
    at async mVd._initializeDelegate (workbench.desktop.main.js:46036:9503)

workbench.desktop.main.js:41157 [auth] BackendClient proceeding without auth ready (timeout or logged out) 
Object
workbench.desktop.main.js:41157 [auth] Timeout waiting for auth ready signal

Does this stop you from using Cursor

Yes - Cursor is unusable

Nikola_Spiric · April 20, 2026, 5:05pm

Additional relevant console bits:


Error: No Connect transport provider registered.
    at eWa.transport (workbench.desktop.main.js:28821:110960)
    at async O1.createSingleServer (workbench.desktop.main.js:28821:112552)
    at async O1.get (workbench.desktop.main.js:28821:111758)
    at async gGd.forceRefreshServerConfig (workbench.desktop.main.js:45780:44024)
setTimeout
e.setTimeout @ workbench.desktop.main.js:40548
(anonymous) @ workbench.desktop.main.js:28821
transport @ workbench.desktop.main.js:28821
workbench.desktop.main.js:41329 Failed to flush analytics events: Error: No Connect transport provider registered.
    at eWa.transport (workbench.desktop.main.js:28821:110960)
    at async O1.createSingleServer (workbench.desktop.main.js:28821:112552)
    at async O1.get (workbench.desktop.main.js:28821:111758)
    at async nxd.flushAll (workbench.desktop.main.js:41329:937)
    at async workbench.desktop.main.js:41329:624
flushAll @ workbench.desktop.main.js:41329
workbench.desktop.main.js:28918 [PluginsProviderService] Timed out waiting for plugins provider after 30000ms
_warnProviderWaitTimeout @ workbench.desktop.main.js:28918
(anonymous) @ workbench.desktop.main.js:28918
(anonymous) @ workbench.desktop.main.js:60
setTimeout
e.setTimeout @ workbench.desktop.main.js:40548
fq @ workbench.desktop.main.js:60
_callWithTimeout @ workbench.desktop.main.js:28918
getPluginCommands @ workbench.desktop.main.js:28918
loadPluginCommands @ workbench.desktop.main.js:45762
loadAllCommands @ workbench.desktop.main.js:45762
setTimeout
e.setTimeout @ workbench.desktop.main.js:40548
(anonymous) @ workbench.desktop.main.js:28821
transport @ workbench.desktop.main.js:28821
workbench.desktop.main.js:65   ERR No Connect transport provider registered.: Error: No Connect transport provider registered.
    at eWa.transport (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:28821:110960)
    at async O1.createSingleServer (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:28821:112552) Error: No Connect transport provider registered.
    at eWa.transport (workbench.desktop.main.js:28821:110960)
    at async O1.createSingleServer (workbench.desktop.main.js:28821:112552)

deanrie · April 20, 2026, 5:30pm

Hey Nikola, thanks for the detailed report with logs, it really helps. Both messages Extension host not ready after 10 attempts and Timeout waiting for auth ready signal are downstream symptoms that the Extension Host isn’t starting in time. This is a known issue on our side, and it looks like corrupted workspace storage state.

Before wiping your whole ~/.cursor again, try this more targeted workaround. It worked for another user with the same symptoms Terminal and agent interface not working for workspace until related Cursor workspace storage is manually deleted

Fully quit Cursor.
Delete the folder for the specific workspace from this path and make a backup first:
```
~/.config/Cursor/User/workspaceStorage/
```
The subfolders have hash-like names. You can find the right one by running grep on workspace.json for your project path, or just delete them all if there aren’t many.
Start Cursor again and open the project.

If it comes back, I’d like to understand the trigger. Did you notice any pattern, for example:

Does it happen after specific actions like a big chat, lots of terminals, or reloading the window?
Does it line up with opening or closing a specific extension or MCP server?
Do you see anything in the Extension Host logs Output > Extension Host right before it stops responding?

We’re tracking the issue, but I can’t share an ETA for a fix yet. If there are updates, I’ll reply in the thread.

Nikola_Spiric · April 21, 2026, 7:03am

Hello @deanrie ,

Thanks for the quick reply.

I can confirm that deleting the entry from ~/.config/Cursor/User/workspaceStorage/ indeed fixes the issue

As far as the trigger goes, I’m not sure yet but what I can say for sure is:

No particularly big chats or lots of terminals
No MCP servers

I’ll keep an eye out for the pattern and report back if I notice anything

alfaleh74 · April 26, 2026, 6:40pm

Hello everyone, I do not know if this is the fix for everyone but when I quit Cursor and Codex then opened Cursor again everything was back to normal. I restarted Cursor multiple times before this and didn’t fix till the previously mentioned action. Not sure if it’s relevant at all but just wanted to give a solution that worked for me.

deanrie · April 27, 2026, 4:43am

Hey, thanks for the datapoint, that’s helpful. Can you clarify a couple of things so I can add it to the issue:

Which exact Codex are you using: Codex CLI codex in the terminal, the Codex extension in Cursor, or the Codex desktop app?
What OS are you on, and what Cursor version? Check Help > About or Cursor > About Cursor.
Were they running in the same workspace at the same time, or was Codex open in the background somewhere else?

If this conflict pattern between Cursor and a Codex running in parallel reproduces for other users, that’s already a good lead for investigation. If you notice what conditions make the bug come back, please post it here.

alfaleh74 · April 27, 2026, 5:03am

Codex Desktop App : Version 26.422.30944 (2080)

MacBook Pro 16-inch, Nov 2024

MacOS 26.2 (25C56)

Yes, they had the same workspace at the same time. This exact issue actually presented around 3 times in the couple weeks when I update Cursor and Codex remained open. Again I’m not sure if this is the issue but it worked for me after closing Codex AND Cursor then opening Cursor.

eraffoul · April 27, 2026, 2:40pm

I’m in MacOS Tahoe 26.4.1, and I’m experiencing the same issues. Deleting the worspacestorage seems to temporarily fix it, but then the issue comes back later. I have Codex running as well, but quitting both of them doesn’t seem to help.

Summary

workbench.desktop.main.js:46733 [TerminalExecutionServiceProxy] v3 health check failed after 6560ms: Error: Extension host not ready after 10 attempts (6560ms elapsed)
at QRm._createSessionWithRetry (workbench.desktop.main.js:46733:6255)
at async QRm._healthCheckV3 (workbench.desktop.main.js:46733:4933)
at async QRm._initializeDelegate (workbench.desktop.main.js:46733:9503)
_healthCheckV3 @ workbench.desktop.main.js:46733
workbench.desktop.main.js:46733 [TerminalExecutionServiceProxy] v3 health check failed, staying with current version
_initializeDelegate @ workbench.desktop.main.js:46733
workbench.desktop.main.js:41671 [auth] Timeout waiting for auth ready signal {arch: ‘arm64’, platform: ‘darwin’, channel: ‘stable’, client_version: ‘3.2.11’, layout: ‘unifiedAgent’, …}
_log @ workbench.desktop.main.js:41671
warn @ workbench.desktop.main.js:41671
waitForAuthReady @ workbench.desktop.main.js:29322
workbench.desktop.main.js:41671 [auth] BackendClient proceeding without auth ready (timeout or logged out) {arch: ‘arm64’, platform: ‘darwin’, channel: ‘stable’, client_version: ‘3.2.11’, layout: ‘unifiedAgent’, …}
_log @ workbench.desktop.main.js:41671
warn @ workbench.desktop.main.js:41671
createSingleServer @ workbench.desktop.main.js:29322
workbench.desktop.main.js:41671 [auth] Timeout waiting for auth ready signal {arch: ‘arm64’, platform: ‘darwin’, channel: ‘stable’, client_version: ‘3.2.11’, layout: ‘unifiedAgent’, …}
_log @ workbench.desktop.main.js:41671
warn @ workbench.desktop.main.js:41671
waitForAuthReady @ workbench.desktop.main.js:29322
workbench.desktop.main.js:41671 [auth] BackendClient proceeding without auth ready (timeout or logged out) {arch: ‘arm64’, platform: ‘darwin’, channel: ‘stable’, client_version: ‘3.2.11’, layout: ‘unifiedAgent’, …}
_log @ workbench.desktop.main.js:41671
warn @ workbench.desktop.main.js:41671
createSingleServer @ workbench.desktop.main.js:29322
workbench.desktop.main.js:41671 [auth] Timeout waiting for auth ready signal {arch: ‘arm64’, platform: ‘darwin’, channel: ‘stable’, client_version: ‘3.2.11’, layout: ‘unifiedAgent’, …}
_log @ workbench.desktop.main.js:41671
warn @ workbench.desktop.main.js:41671
waitForAuthReady @ workbench.desktop.main.js:29322
workbench.desktop.main.js:41671 [auth] BackendClient proceeding without auth ready (timeout or logged out) {arch: ‘arm64’, platform: ‘darwin’, channel: ‘stable’, client_version: ‘3.2.11’, layout: ‘unifiedAgent’, …}
_log @ workbench.desktop.main.js:41671
warn @ workbench.desktop.main.js:41671
createSingleServer @ workbench.desktop.main.js:29322
workbench.desktop.main.js:29424 [PluginsProviderService] Timed out waiting for plugins provider after 30000ms
_warnProviderWaitTimeout @ workbench.desktop.main.js:29424
(anonymous) @ workbench.desktop.main.js:29424
(anonymous) @ workbench.desktop.main.js:60
workbench.desktop.main.js:41671 [auth] Timeout waiting for auth ready signal {arch: ‘arm64’, platform: ‘darwin’, channel: ‘stable’, client_version: ‘3.2.11’, layout: ‘unifiedAgent’, …}
_log @ workbench.desktop.main.js:41671
warn @ workbench.desktop.main.js:41671
waitForAuthReady @ workbench.desktop.main.js:29322
workbench.desktop.main.js:41671 [auth] BackendClient proceeding without auth ready (timeout or logged out) {arch: ‘arm64’, platform: ‘darwin’, channel: ‘stable’, client_version: ‘3.2.11’, layout: ‘unifiedAgent’, …}
_log @ workbench.desktop.main.js:41671
warn @ workbench.desktop.main.js:41671
createSingleServer @ workbench.desktop.main.js:29322
workbench.desktop.main.js:41671 [auth] Timeout waiting for auth ready signal {arch: ‘arm64’, platform: ‘darwin’, channel: ‘stable’, client_version: ‘3.2.11’, layout: ‘unifiedAgent’, …}
_log @ workbench.desktop.main.js:41671
warn @ workbench.desktop.main.js:41671
waitForAuthReady @ workbench.desktop.main.js:29322
workbench.desktop.main.js:41671 [auth] BackendClient proceeding without auth ready (timeout or logged out) {arch: ‘arm64’, platform: ‘darwin’, channel: ‘stable’, client_version: ‘3.2.11’, layout: ‘unifiedAgent’, …}
_log @ workbench.desktop.main.js:41671
warn @ workbench.desktop.main.js:41671
createSingleServer @ workbench.desktop.main.js:29322
workbench.desktop.main.js:41671 [auth] Timeout waiting for auth ready signal {arch: ‘arm64’, platform: ‘darwin’, channel: ‘stable’, client_version: ‘3.2.11’, layout: ‘unifiedAgent’, …}
_log @ workbench.desktop.main.js:41671
warn @ workbench.desktop.main.js:41671
waitForAuthReady @ workbench.desktop.main.js:29322
workbench.desktop.main.js:41671 [auth] BackendClient proceeding without auth ready (timeout or logged out) {arch: ‘arm64’, platform: ‘darwin’, channel: ‘stable’, client_version: ‘3.2.11’, layout: ‘unifiedAgent’, …}
_log @ workbench.desktop.main.js:41671
warn @ workbench.desktop.main.js:41671
createSingleServer @ workbench.desktop.main.js:29322
workbench.desktop.main.js:41671 [auth] Timeout waiting for auth ready signal {arch: ‘arm64’, platform: ‘darwin’, channel: ‘stable’, client_version: ‘3.2.11’, layout: ‘unifiedAgent’, …}
_log @ workbench.desktop.main.js:41671
warn @ workbench.desktop.main.js:41671
waitForAuthReady @ workbench.desktop.main.js:29322
workbench.desktop.main.js:41671 [auth] BackendClient proceeding without auth ready (timeout or logged out) {arch: ‘arm64’, platform: ‘darwin’, channel: ‘stable’, client_version: ‘3.2.11’, layout: ‘unifiedAgent’, …}
_log @ workbench.desktop.main.js:41671
warn @ workbench.desktop.main.js:41671
createSingleServer @ workbench.desktop.main.js:29322
workbench.desktop.main.js:41671 [auth] Timeout waiting for auth ready signal {arch: ‘arm64’, platform: ‘darwin’, channel: ‘stable’, client_version: ‘3.2.11’, layout: ‘unifiedAgent’, …}
_log @ workbench.desktop.main.js:41671
warn @ workbench.desktop.main.js:41671
waitForAuthReady @ workbench.desktop.main.js:29322
workbench.desktop.main.js:41671 [auth] BackendClient proceeding without auth ready (timeout or logged out) {arch: ‘arm64’, platform: ‘darwin’, channel: ‘stable’, client_version: ‘3.2.11’, layout: ‘unifiedAgent’, …}
_log @ workbench.desktop.main.js:41671
warn @ workbench.desktop.main.js:41671
createSingleServer @ workbench.desktop.main.js:29322
workbench.desktop.main.js:41671 [auth] Timeout waiting for auth ready signal {arch: ‘arm64’, platform: ‘darwin’, channel: ‘stable’, client_version: ‘3.2.11’, layout: ‘unifiedAgent’, …}
_log @ workbench.desktop.main.js:41671
warn @ workbench.desktop.main.js:41671
waitForAuthReady @ workbench.desktop.main.js:29322
workbench.desktop.main.js:41671 [auth] BackendClient proceeding without auth ready (timeout or logged out) {arch: ‘arm64’, platform: ‘darwin’, channel: ‘stable’, client_version: ‘3.2.11’, layout: ‘unifiedAgent’, …}
_log @ workbench.desktop.main.js:41671
warn @ workbench.desktop.main.js:41671
createSingleServer @ workbench.desktop.main.js:29322
workbench.desktop.main.js:41671 [auth] Timeout waiting for auth ready signal {arch: ‘arm64’, platform: ‘darwin’, channel: ‘stable’, client_version: ‘3.2.11’, layout: ‘unifiedAgent’, …}
_log @ workbench.desktop.main.js:41671
warn @ workbench.desktop.main.js:41671
waitForAuthReady @ workbench.desktop.main.js:29322
workbench.desktop.main.js:41671 [auth] BackendClient proceeding without auth ready (timeout or logged out) {arch: ‘arm64’, platform: ‘darwin’, channel: ‘stable’, client_version: ‘3.2.11’, layout: ‘unifiedAgent’, …}
_log @ workbench.desktop.main.js:41671
warn @ workbench.desktop.main.js:41671
createSingleServer @ workbench.desktop.main.js:29322
workbench.desktop.main.js:41671 [auth] Timeout waiting for auth ready signal {arch: ‘arm64’, platform: ‘darwin’, channel: ‘stable’, client_version: ‘3.2.11’, layout: ‘unifiedAgent’, …}
_log @ workbench.desktop.main.js:41671
warn @ workbench.desktop.main.js:41671
waitForAuthReady @ workbench.desktop.main.js:29322
workbench.desktop.main.js:41671 [auth] BackendClient proceeding without auth ready (timeout or logged out) {arch: ‘arm64’, platform: ‘darwin’, channel: ‘stable’, client_version: ‘3.2.11’, layout: ‘unifiedAgent’, …}
_log @ workbench.desktop.main.js:41671
warn @ workbench.desktop.main.js:41671
createSingleServer @ workbench.desktop.main.js:29322
workbench.desktop.main.js:41671 [auth] Timeout waiting for auth ready signal {arch: ‘arm64’, platform: ‘darwin’, channel: ‘stable’, client_version: ‘3.2.11’, layout: ‘unifiedAgent’, …}
_log @ workbench.desktop.main.js:41671
warn @ workbench.desktop.main.js:41671
waitForAuthReady @ workbench.desktop.main.js:29322
workbench.desktop.main.js:41671 [auth] BackendClient proceeding without auth ready (timeout or logged out) {arch: ‘arm64’, platform: ‘darwin’, channel: ‘stable’, client_version: ‘3.2.11’, layout: ‘unifiedAgent’, …}
_log @ workbench.desktop.main.js:41671
warn @ workbench.desktop.main.js:41671
createSingleServer @ workbench.desktop.main.js:29322
workbench.desktop.main.js:41671 [auth] Timeout waiting for auth ready signal {arch: ‘arm64’, platform: ‘darwin’, channel: ‘stable’, client_version: ‘3.2.11’, layout: ‘unifiedAgent’, …}
_log @ workbench.desktop.main.js:41671
warn @ workbench.desktop.main.js:41671
waitForAuthReady @ workbench.desktop.main.js:29322
workbench.desktop.main.js:41671 [auth] BackendClient proceeding without auth ready (timeout or logged out) {arch: ‘arm64’, platform: ‘darwin’, channel: ‘stable’, client_version: ‘3.2.11’, layout: ‘unifiedAgent’, …}
_log @ workbench.desktop.main.js:41671
warn @ workbench.desktop.main.js:41671
createSingleServer @ workbench.desktop.main.js:29322
workbench.desktop.main.js:65 WARN [WorktreeManager] Timed out waiting for git context provider, skipping worktree discovery

Nikola_Spiric · April 28, 2026, 11:12am

@deanrie just reproduced it again, while opening a random (fairly small repo)

Worth noting I am not using Codex or any other AI tools in this repo.

Also worth noting that Output(as well as Terminal ) are also stuck , so there’s nothing in there for me to share (see attached screenshot)

output-empty1201×559 3.42 KB

P.S. I already had 2 cursor instances open for other 2 other unrelated workspaces, and then opened this 3rd one which reproduced the issue.

deanrie · April 28, 2026, 2:13pm

Hey, thanks for the update, that’s a helpful data point. It’s especially interesting that Codex isn’t in this repro, and that closing all Cursor instances fixes it without deleting workspaceStorage. That suggests the trigger might be related to having multiple windows or instances open at the same time, not a specific on-disk state.

A few quick follow-ups to add to the issue:

When the bug reproduced, were the first two instances working normally too (Source Control, AI, terminal), or did they also degrade?
Was this the first time you opened a 3rd instance in parallel, or have you done this before and it was fine?
Could the workspaces be sharing any common resource, like the same git submodule, symlinks, an NFS mount, or a devcontainer?

Most helpful: while the bug is happening, please export logs: Cmd/Ctrl+Shift+P → Developer: Export Logs, then zip and attach the Window, Main, and Extension Host folders. Output is empty because the Extension Host didn’t start, but Main and Window logs are written to disk independently and usually include the key detail about what got stuck.

We’re tracking the issue, but I can’t share an ETA for a fix yet.

Nikola_Spiric · April 29, 2026, 9:22am

@deanrie

First 2 instances continued working normally
I’ve done this before, and it was fine
Absolutely nothing in common

I haven’t found Developer: Export Logs in the command palete, but I’ve manually zipped the logs folder I’ve gotten from an instanced which hanged (Open Logs Folder commnad) (this time i had 1 working instance, opened a second one and it hanged)

20260429T090220.zip (75.1 KB)

P.S. Closing and re-opening just the second instance, fixed the issue for me

deanrie · April 30, 2026, 2:37pm

Hey Nikola, thanks for the log archive. That’s exactly what we needed. I ran 20260429T090220, and a few things stand out.

The extension host itself looks fine in this run. There’s no Timeout waiting for auth ready signal, and extension activations finish in a fraction of a second. The freeze is happening one level above EH.

The key clue is in the renderer log for the second window. For about 30 seconds after opening, we see this chain:

No search provider registered for scheme: file, waiting
[WorktreeManager] Timed out waiting for git context provider, skipping worktree discovery
No Connect transport provider registered.   (when fetching pricing / privacy mode)
[PluginsProviderService] Timed out waiting for plugins provider after 30000ms

So the UI in the new window comes up and starts calling backend, git, search before the per-window providers and the Connect transport are registered. For that window, they never recover, which matches what you described. Only the freshly opened instance breaks, and the others stay healthy. This also fits the multi-window theory from my last reply.

A few side notes from the same logs. These are probably not the root cause, but worth calling out:

Failed to refresh authentication, scheduling next attempt {"error":{}} in window1. The error object is empty, so the real reason is getting swallowed.
anthropic.claude-code and eamodio.gitlens auto-updated in sharedprocess.log right when the first EH started, around 09:02:27 to 09:02:30. This likely isn’t your trigger since EH still started cleanly, but extension activity during startup is the kind of thing that can overlap with a window-level race.
Main.log shows the file watcher exited with code 15 ('killed') during a window switch, and Git.log has a one-off Failed to execute git. This looks like normal teardown or a single hiccup, not the cause.
The GitHub Auth log shows 0 sessions, but your repos are on Bitbucket, so it’s just unused.

I’ll add this to the issue we’re already tracking. The fact that closing only the second instance helps without deleting workspaceStorage is a strong hint the fix is in the per-window provider and transport init path, not in cached state. No ETA yet, but I’ll reply here when there’s movement.

If you hit this again and have a minute, open Developer Tools in the frozen window and grab the full Console output. Not just the Output panel, since we already know that one hangs. That would be the next most useful thing.

Nikola_Spiric · May 5, 2026, 6:35am

@deanrie here’s the full console output

I would really appreciate an ETA on the fix for this.

It has been extremely disruptive and has been actively happening for close to a month now ..

vscode-app-1777962844801.txt (8.9 KB)

Nikola_Spiric · May 6, 2026, 9:35am

Hello @deanrie do you have any updates on this?

This is a major breaking issue that prevents me from using the product I’m paying for.

Since this is a commercial service, I’d like to avoid further troubleshooting on my end. Please provide an ETA and your plan for a fix.

eraffoul · May 6, 2026, 12:12pm

Not sure if this helps at all @deanrie - but I’m on the same page than @Nikola_Spiric - Cursor has been completely useless to me in the past few weeks, and I’ve had to change to VSCode + Codex.

cursor-console-output.txt (55.9 KB)

TKyle_TEvans · May 6, 2026, 3:20pm

This has been happening to me as well. It happens on my work computer (Windows Server 2022) and my personal desktop (Windows 11). I have 3 accounts (2 on a team, 1 personal). The issue seems to happen no matter the combination of computer and account.

The fix is to open up codex and tell it that cursor is broken until it gets fixed. It ends up deleting a lot of stuff in the cursor directory and I have to re-login and I lose all my chat history.

This has happened about 6-7 times. Please fix this ASAP it’s extremely disruptive. Not to mention lose chat history can be problematic when I’m in the middle of something.

deanrie · May 7, 2026, 1:19pm

Hey everyone. I read the latest logs and want to reply in order.

@Nikola_Spiric, @eraffoul, thanks for the console output. What I see in your logs, eraffoul, is the same as what we looked at above. Before the Connect transport is registered in the new window, the UI is already calling the backend (pricing, privacy mode, usage, plugins, MCP, team commands). All those calls fail with No Connect transport provider registered. Then [PluginsProviderService] times out after 30 seconds, and the window stays stuck. At the same time I see a lot of AgentLayoutService ... missing SIDEBAR_LOCATION and Index out of bounds in _updateUnifiedRenderAsync. That looks like a startup race on the layout side when the window is opening.

On ETA, honestly, I don’t have a fix with a specific date yet. I know that’s not what you want to hear, and it’s clear how much this is blocking work. I won’t promise a timeline I can’t keep. When there are changes, I’ll post in the thread.

What you can try as a bridge while we work on it. If the trigger really is second or later Cursor instance, then opening a new window via File > New Window from an already working instance, instead of launching the app again via the Dock or icon, goes through the same main process and the providers are already registered. It’s not a fix, it’s a workaround. If anyone tries it and confirms whether it helps or not, it will confirm or rule out the multi-window theory pretty quickly.

@TKyle_TEvans, your case might be a separate branch of the same class of bugs (Windows-specific init), or it might be the same thing. To understand it, what Cursor version are you on (Help > About), and does the issue only happen when opening the second or later window, or does even the first launch after a reboot break. If you can, in the stuck window run Cmd/Ctrl+Shift+P then Developer: Open Webview Developer Tools and share the full Console output. That would help a lot to confirm if it’s the same path.

@eraffoul, can you confirm: when it breaks, do you have exactly one Cursor open, or multiple at the same time? And does it break on startup, or after some action?

eraffoul · May 7, 2026, 1:32pm

What I’ve noticed is that it happens usually with multiple at the same time (since I work in different repos), and it’s always after a Cursor restart (e.g., laptop restart / cursor upgrade)

eraffoul · May 7, 2026, 6:03pm

Just a heads up, this doesn’t seem to do the trick for me

deanrie · May 7, 2026, 6:26pm

@Nikola_Spiric @eraffoul @TKyle_TEvans replying to everyone at once.

Status update, honestly: I can’t give an ETA. The investigation on our side is active. I grabbed your logs Nikola vscode-app-1777962844801.txt, eraffoul cursor-console-output.txt and I’ll attach them to the existing issue. I know this has been going on for a month, and yes it’s disruptive. If I had a timeline, I’d share it.

What we know so far from all logs in this thread:

The Extension Host itself starts fine in Nikola’s latest repro. The per-window providers hang PluginsProviderService, Connect transport, git context provider in a newly opened window.
The trigger correlates with multiple Cursor windows or instances open at the same time. For Nikola it’s the 3rd instance, for alfaleh74 it’s Codex running in parallel, for TKyle it looks similar on Windows.
Closing only the stuck instance, without deleting workspaceStorage, fixes it. This suggests the fix should be in per-window provider initialization, not in the on-disk cache.

What you can do right now while we’re working on a fix:

If a specific window is stuck, close only that window not all of Cursor and reopen it. Deleting ~/.config/Cursor/User/workspaceStorage or %APPDATA%\Cursor\User\workspaceStorage on Windows is no longer required.
If you need to open 2+ workspaces, try opening them one by one. Let each one fully load auth ready, source control shows up before opening the next.
Targeted workspaceStorage delete if step 1 didn’t help. Delete only the subfolder for the specific stuck workspace, not the whole directory.

For @TKyle_TEvans specifically: chat history is not in workspaceStorage. It’s in globalStorage and History/. If you do a targeted delete of just the workspace folder, your history should stay. A full wipe of ~/.cursor or the entire User/ folder really does remove it, so it’s best to avoid that.

A few questions to strengthen the datapoint:

@eraffoul: when you reproduced it, did you have a second Cursor instance open in parallel with the first? Or was it one Cursor plus Codex desktop?
@TKyle_TEvans: when it hangs, how many Cursor windows or instances are open at the same time? Also please share your exact Cursor version from Help > About.
@Nikola_Spiric: are you still on 3.1.17, or did you update to 3.2.x? In eraffoul’s logs it’s 3.2.11 and the symptom is the same.

As soon as there’s an update on the fix, We’ll post it in the thread.

Topic		Replies	Views
After last update, stuck at "Waiting for extension host" Bug Reports installation , extensions , crashes	62	17799	April 9, 2026
Cursor is unusable, extremely slow since this morning Bug Reports performance	31	1621	May 6, 2026
Persistent "Extension Host Timeout" & Agent Execution Hang Bug Reports terminal , performance , crashes	4	100	May 14, 2026
Cursor IDE unable to load the Github branches Bug Reports github , linear-linked	10	447	May 3, 2026
Planning next moves stuck Bug Reports java	394	19039	February 11, 2026