Bug: Window initialization stalls after auto-update - extension hosts spawn but never become responsive

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I used Claude to investigate this bug and write this summary

After Cursor performs an in-app update + restart (UpdateService doQuitAndInstall), the
restored window comes back in a half-initialized state. The renderer spawns the local
extension host processes, but none of them actually finish initializing - no per-extension
log files are ever written, no fileWatcher.log is created, and the renderer never gets a
file-search provider registered. Approximately 150 seconds after launch, Cursor’s internal
Connect RPC layer starts erroring out with No Connect transport provider registered. on
every poll, and continues to do so until the user manually invokes Reload Window.

The reload always recovers the session. Quitting Cursor entirely and relaunching also recovers.

This has reproduced across at least two consecutive Cursor updates on the same machine, and
the same error pattern is present in older session logs as well (one window in a multi-window
Cursor process hits it while the other doesn’t), suggesting a per-renderer startup race
rather than something tied to a specific build.

User-visible symptoms

In the affected window:

  1. Last-opened file never loads - editor tab shows a loading spinner indefinitely.
  2. Terminal panel is unresponsive - previously-open terminals are not redrawn, new
    terminals cannot be created.
  3. Output / Problems / Debug Console panels do not respond - clicking tabs does nothing.
  4. Cursor AI features fail - chat / Composer / autocomplete cannot reach the backend.
  5. MCP servers fail to start.
  6. Source control / GitLens / language servers appear inactive.

Steps to Reproduce

  1. Run Cursor on macOS arm64 with the in-app auto-updater enabled.
  2. Have at least one extension that the new build wants to upgrade (so its previous version
    ends up marked-for-removal). In this repro the marked-for-removal versions were:
    • google.geminicodeassist-2.81.0 (upgrade to 2.82.0)
    • anthropic.claude-code-2.1.140-darwin-arm64 (upgrade to 2.1.141)
    • anthropic.claude-code-2.1.139-darwin-arm64 (older copy never cleaned up)
  3. When Cursor reaches update#setState ready, click “Restart to update” (i.e. let the
    in-app doQuitAndInstall chain into the new session - do not Cmd-Q and relaunch).
  4. After restart, observe in the restored window:
    • Last-open editor tab spins indefinitely.
    • Terminal panel does not respond.
    • Cursor AI chat / Composer fail.
  5. Confirm in ~/Library/Application Support/Cursor/logs/<latest-session>/:
    • window1/exthost/ directory was never created.
    • window1/fileWatcher.log was never created.
    • window1/renderer.log contains No search provider registered for scheme: file, waiting
      that never clears, followed ~150s later by repeated No Connect transport provider registered. errors.
  6. Run Developer: Reload Window - the new renderer starts normally, exthost/ and
    fileWatcher.log are created, and all functionality returns.

Repro is not 100% - based on prior session logs, it can also hit only one window in a
multi-window Cursor process, so there appears to be a timing element.

Operating System

MacOS

Version Information

Version: 3.4.17 (Universal)
VSCode Version: 1.105.1
Commit: 93e603f703cd553a6bb3644711a3379bbbb31180
Date: 2026-05-13T21:39:55.724Z
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.5.0

Additional Information

Timeline (from log timestamps, today’s repro)

Time Source Event
10:45:08 main.log update#setState checking for updates → onUpdateAvailable()
10:45:27 main.log update#setState downloaded → ready
15:03:17 main.log (old session) UpdateService doQuitAndInstall()
15:03:17 main.log (old session) UpdateService doQuitAndInstall() - kill switch active, skipping app.exit(0) bypass
15:03:36 new logs dir New session begins (20260514T150336)
15:03:39.519 renderer.log:13 Started local extension host with pid 43807.
15:03:39.891 renderer.log:21-23 Three additional extension hosts requested for anysphere.* extensions
15:03:40.156 renderer.log:27-29 Started local extension host with pid 43808/43809/43810.
15:03:40.292 renderer.log:32 [warning] No search provider registered for scheme: file, waiting
15:03:41.786 sharedprocess.log:2-4 Shared process deletes 3 extensions marked-for-removal (see below) - this happens after the renderer has already spawned ext hosts
15:06:09.271 renderer.log:33 First No Connect transport provider registered. error (~150s after launch)
15:06:10.721 renderer.log:42-53 Same error fires from dashboardClient, keepCppModelStateUpdated, loadCppConfigIncludingHandlingProAccess
15:08:39, 15:13:39, 15:18:39, 15:23:39 … renderer.log Error re-fires on every ~5 min poll, indefinitely

The smoking gun - extension hosts spawn but never actually initialize

Comparing the broken window’s log directory to a healthy window from the prior session
(same Cursor process, same user, same workspace - 20260513T120901/window2/):

Healthy window Broken window (post-update)
exthost/ subdirectory created :white_check_mark: yes, with per-extension subfolders :cross_mark: never created
fileWatcher.log created :white_check_mark: yes :cross_mark: never created
renderer.log size after ~10 min ~348 KB ~13 KB
No Connect transport provider registered occurrences 0 27+ (and counting)
No search provider registered for scheme: file, waiting 1 (clears within seconds) 1 (never clears)

main.log confirms 4 extension host PIDs were spawned (43807–43810), but not one of them
wrote a single line to exthost/. The processes start and then go silent. The renderer
keeps polling for things those hosts are supposed to provide (file search provider, the
Connect transport, etc.) and never gets them.

In the previous session, the same window-level issue is visible: window1/renderer.log
contained 63 No Connect transport provider registered errors while window2/renderer.log
in the same Cursor process contained 0. So this is a per-renderer init failure, not a
global / config / network issue.

Suspected root cause: race between extension uninstall-on-update and renderer ext-host startup

From sharedprocess.log of the current session:

2026-05-14 15:03:41.681 [info] Getting extensions control
2026-05-14 15:03:41.786 [info] Deleted marked for removal extension from disk google.geminicodeassist /Users/user/.cursor/extensions/google.geminicodeassist-2.81.0
2026-05-14 15:03:41.786 [info] Deleted marked for removal extension from disk anthropic.claude-code /Users/user/.cursor/extensions/anthropic.claude-code-2.1.140-darwin-arm64
2026-05-14 15:03:41.786 [info] Deleted marked for removal extension from disk anthropic.claude-code /Users/user/.cursor/extensions/anthropic.claude-code-2.1.139-darwin-arm64

The shared process performs these deletions at 15:03:41.786 - but the renderer has already
spawned the four extension hosts starting at 15:03:39.519, two seconds before. So the
renderer enumerated the on-disk extension layout, decided how to partition them across hosts
(including putting anysphere.cursor-resolver / cursor-socket / cursor-always-local on
their own host - see renderer.log:22), and forked the hosts - while the marked-for-removal
versions were still on disk. The shared process then deleted those versions out from under
the running hosts.

The anysphere.cursor-socket / cursor-resolver extensions are the most likely owners of the
“Connect transport provider” that the renderer is asking for, and they get placed on a
dedicated extension host (renderer.log:22). If that host dies silently during the
mid-startup cleanup, the renderer is left waiting forever for a transport that nothing will
ever register.

This is consistent with:

  • The ~150-second delay before the first Connect-transport error (it’s the first
    poll-interval tick after startup).
  • The fact that reloading the window fixes it (by the time the second renderer initializes,
    the cleanup is long done and the extension directory is consistent).
  • The same symptom showing up in one window but not another in the same Cursor process
    (whichever renderer happened to lose the race).

Key log excerpts

main.log - pre-update, install trigger
2026-05-14 10:45:08.851 [info] UpdateService onUpdateAvailable()
2026-05-14 10:45:08.852 [info] update#setState downloading
2026-05-14 10:45:27.196 [info] UpdateService onUpdateDownloaded()
...
2026-05-14 15:03:17.411 [info] UpdateService doQuitAndInstall()
2026-05-14 15:03:17.416 [info] UpdateService doQuitAndInstall() - kill switch active, skipping app.exit(0) bypass
sharedprocess.log - post-restart, racing cleanup
2026-05-14 15:03:41.681 [info] Getting extensions control
2026-05-14 15:03:41.786 [info] Deleted marked for removal extension from disk google.geminicodeassist .../google.geminicodeassist-2.81.0
2026-05-14 15:03:41.786 [info] Deleted marked for removal extension from disk anthropic.claude-code .../anthropic.claude-code-2.1.140-darwin-arm64
2026-05-14 15:03:41.786 [info] Deleted marked for removal extension from disk anthropic.claude-code .../anthropic.claude-code-2.1.139-darwin-arm64
renderer.log - ext-host spawn, then silent failure
2026-05-14 15:03:39.519 [info] Started local extension host with pid 43807.
2026-05-14 15:03:39.891 [info] Placing extension(s) anysphere.cursor-retrieval on a separate extension host.
2026-05-14 15:03:39.891 [info] Placing extension(s) anysphere.cursor-always-local, anysphere.cursor-resolver, anysphere.cursor-socket on a separate extension host.
2026-05-14 15:03:39.891 [info] Placing extension(s) anysphere.cursor-agent-exec, anysphere.cursor-agent-worker, anysphere.cursor-checkout on a separate extension host.
2026-05-14 15:03:40.156 [info] Started local extension host with pid 43808.
2026-05-14 15:03:40.156 [info] Started local extension host with pid 43809.
2026-05-14 15:03:40.156 [info] Started local extension host with pid 43810.
2026-05-14 15:03:40.292 [warning] No search provider registered for scheme: file, waiting
renderer.log - Connect transport repeatedly missing
2026-05-14 15:06:09.271 [error] Error fetching user pricing info: No Connect transport provider registered.
2026-05-14 15:06:09.272 [error] Failed to poll repo blocklist: No Connect transport provider registered.
2026-05-14 15:06:09.272 [error] Error fetching user privacy mode: No Connect transport provider registered.
2026-05-14 15:06:09.272 [error] No Connect transport provider registered.: Error: No Connect transport provider registered.
    at wxd.transport (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:29748:109883)
    at async vI.createSingleServer (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:29748:111410)
...
2026-05-14 15:06:10.721 [error] No Connect transport provider registered.: Error: No Connect transport provider registered.
    at wxd.transport (...workbench.desktop.main.js:29748:109883)
    at async vI.createSingleServer (...workbench.desktop.main.js:29748:111410)
    at async vI.get (...workbench.desktop.main.js:29748:110616)
    at async ykf.dashboardClient (...workbench.desktop.main.js:43896:40995)
    at async produceFn (...workbench.desktop.main.js:43896:36386)
2026-05-14 15:06:10.721 [error] No Connect transport provider registered.: Error: No Connect transport provider registered.
    at wxd.transport (...workbench.desktop.main.js:29748:109883)
    at async vI.createSingleServer (...workbench.desktop.main.js:29748:111410)
    at async vI.get (...workbench.desktop.main.js:29748:110616)
    at async G5f.keepCppModelStateUpdated (...workbench.desktop.main.js:47037:16302)
    at async G5f.loadCppConfigIncludingHandlingProAccess (...workbench.desktop.main.js:47047:1261)

The error originates from wxd.transport in workbench.desktop.main.js, which is invoked
when something tries to call a Connect-protocol RPC. The call sites include:

  • The dashboard client (ykf.dashboardClient)
  • C++ model state polling (G5f.keepCppModelStateUpdated, G5f.loadCppConfigIncludingHandlingProAccess)
  • A generic createSingleServer path (used by MCP creation and other internal RPCs)

wxd.transport apparently expects a previously-registered provider, and during a broken
startup that provider is never installed.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

6

This is a known bug. Extension hosts occasionally fail to initialize after startup (particularly after in-app updates), which causes the exact symptoms you’re seeing: the editor, terminal, AI features, and source control all go unresponsive. Our team is actively investigating.

Your analysis of the timing between extension cleanup and ext-host startup is spot-on and very helpful. We’ve added it to the tracking issue.

For now, the workarounds you’ve already found are the best options:

  1. Developer: Reload Window (Cmd+Shift+P > Reload Window) — recovers the session immediately

  2. Full quit and relaunch — also works reliably

You may also find this related thread helpful, which tracks the same root cause class on macOS: Extension Host fails to initialize (Timeout waiting for auth and plugins)

We’ll follow up here when a fix ships.