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.

8

Hey @sbsUtl Tarun here from the engineering team.
Thanks for the detailed write up.

There was a race condition during extension host startup that caused the scanning to index extensions that were marked as obsolete leading to a hang up state.

The fix is out, look out for an update on (i believe will be out tmr) 3.6.18
Lmk if you see it again, and feel free to upload the logs from exthost/ , main.log and render.log
(change the format to .txt if you are unable to upload)

10

Thanks for the update!
Will update after the update if it worked as expected

11

Don’t want to jinx it, but the update (3.6.21) seems to have worked as expected!
Thanks for the resolution and attention to this matter :folded_hands:

13

@tarun @mohitjain
Okay sadly this happened to me again, this time not after an update restart
I’m adding below the summary for the further investigation I let claude handle, and some logs files

cursor-bug-followup.zip (11.9 KB)

Cursor renderer-init failure — follow-up after the previous report was reportedly fixed

TL;DR

The renderer-init failure I previously reported (broken window with no exthost/ dir, never-clearing No search provider registered for scheme: file, waiting, repeated No Connect transport provider registered. floods, healthy sibling window in the same Cursor process, recoverable only by Developer: Reload Window) is still happening on Cursor 3.6.31.

Support indicated the original cause — a race between in-app-update extension cleanup and renderer ext-host startup — was patched. That patch may indeed have landed: this reproduction has no in-app update involved at all. So whatever was fixed is no longer the path in, but the same downstream broken state can still be reached. This note summarises what’s the same, what’s different, and what looks like the most promising next thread to pull.

Build details from the affected session:

  • Cursor 3.6.31 (Universal)
  • VSCode 1.105.1
  • Commit bcb2805eed557afbde05f120272cd995fec5b588b7bcfd58358ea15ebc9e0243
  • Build date 2026-05-31T17:46:29.630Z
  • Electron 39.8.1, Chromium 142.0.7444.265, Node 22.22.1, V8 14.2.231.22-electron.0
  • OS Darwin arm64 25.5.0
  • Session log directory: 20260601T174133 (the directory packaged alongside this note)

What’s the same as the previous report

The broken renderer’s fingerprint matches the previous report line-for-line:

Signal Previous report This session (window1)
window1/exthost/ directory created never never
window1/fileWatcher.log created never never
No search provider registered for scheme: file, waiting clears no no
No Connect transport provider registered. floods 27+ 19 over ~5 min, still firing
Approximate gap from renderer spawn to first Connect error ~150 s ~150 s (17:41:35 → 17:44:05)
Same call sites firing the error yes yes — bx.createSingleServer, keepCppModelStateUpdated, loadCppConfigIncludingHandlingProAccess, dashboardClient, plus the pricing-info / repo-blocklist / privacy-mode polls
Healthy sibling renderer in the same Cursor process yes — window2 yes — window2_wb0 (0 Connect errors, exthost dir populated with anysphere.cursor-socket, anysphere.cursor-always-local, anysphere.cursor-agent-exec, anysphere.cursor-retrieval, anysphere.cursor-mcp, vscode.git)
Recovery via Developer: Reload Window yes yes

So the broken end state is identical: a renderer that comes up with ext hosts spawned but inert, no Connect transport provider, no file search provider, and a stuck file-search-waiting state.

What’s different (i.e. new information)

1. No in-app update is involved this time

The previous report’s main.log showed UpdateService doQuitAndInstall() followed by a fresh session that inherited the broken state. This session’s main.log shows nothing of the sort — it’s a plain cold start:

17:41:34.143 update#setState idle
17:42:04.200 UpdateService onUpdateNotAvailable()

No doQuitAndInstall, no “kill switch active, skipping app.exit(0) bypass”, no installer chain. Whatever was patched in the original report cannot be the trigger here.

2. No “marked for removal” extension cleanup at startup

The previous report’s smoking gun was three “Deleted marked for removal extension from disk” lines in sharedprocess.log that fired ~2 s after the renderer had already spawned its ext hosts (google.geminicodeassist-2.81.0, anthropic.claude-code-2.1.140-darwin-arm64, anthropic.claude-code-2.1.139-darwin-arm64).

sharedprocess.log for this session has zero “Deleted marked for removal” lines. The only extension-store activity is auto-update of ms-python.python and mermaidchart.vscode-mermaid-chart, and all of it happens 2.5+ minutes after the broken renderer has already gone silent (renderer started 17:41:35; auto-updates run 17:44:13 – 17:44:25). So the “shared process deletes extensions out from under a freshly-spawned ext host” mechanism is not present here.

3. A new error fires at renderer init, before the “No search provider” warning

This is the most useful new signal. At 17:41:36.817 — ~1.3 s after the renderer spawned the local extension host and before it printed “No search provider registered for scheme: file, waiting” — the broken renderer throws a dependency-injection TypeError (window1/renderer.log:34):

[error] Cannot read properties of undefined (reading '$di$dependencies'): TypeError: Cannot read properties of undefined (reading '$di$dependencies')
    at Object.e [as getServiceDependencies] (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:61:62772)
    at Xfg._createInstance (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:47926:1595)
    at Xfg.createInstance (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:47926:1522)
    at CFg._instantiateById (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:300:25754)
    at CFg._instantiateSome (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:300:25364)
    at vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:300:24662

getServiceDependencies was called with an undefined service descriptor during the renderer’s eager-instantiation pass (_instantiateSome → _instantiateById → _createInstance). The DI graph throws, instantiation aborts, and nothing downstream of that throw ever runs — including, presumably, whatever was supposed to register the Connect transport provider and the file search provider.

This stack was not present in the previous report. Given that it lands before the missing-search-provider warning and before the silent ext-host death, it’s the strongest candidate so far for the proximate cause of this variant.

4. Marketplace 404 fires in both renderers near the failure window

Probably incidental, but flagging it because the timing correlates and it appears in both the broken and the healthy renderer:

17:41:36.630 [error] [Marketplace] Error retrieving extension gallery manifest Server returned 404   (window1)
17:44:10.484 [error] [Marketplace] Error retrieving extension gallery manifest Server returned 404   (window2_wb0)

5. Frequency is higher than the previous report suggested

The previous report described the bug as appearing across two consecutive update events. The user’s ~/Library/Application Support/Cursor/logs/ shows fresh failing-pattern sessions on 5/17, 5/18, 5/21, 5/24, 5/28, 5/31, and 6/1 — roughly weekly over the last two to three weeks, on a build (3.6.31) where the original race condition is supposedly fixed. So this variant is reproducing reliably on plain cold starts, not just on update events.

Hypothesis and suggested next step

The previous report concluded the bug was an extension-uninstall race writing the on-disk extension layout while the renderer was forking ext hosts. That race may well be fixed in 3.6.31. What this session shows is that the same end state can still be reached on a clean cold start with no extension cleanup at all.

The $di$dependencies TypeError at 17:41:36.817 is the earliest symptom on the broken renderer and is upstream of everything else that goes wrong. It would be useful for the engineer who looked at the original report to investigate:

  • Which service registrations participate in the path CFg._instantiateSome → _instantiateById → Xfg._createInstance → getServiceDependencies during renderer startup.
  • Whether any of those registrations are conditional on something async (shared-process connection ready, marketplace manifest fetch, extension scan complete, glass-mode vs non-glass-mode init, etc.) such that under the wrong ordering a service descriptor can be undefined at lookup time.
  • Whether the registration of the Connect transport provider lives in (or is gated by) one of the descriptor chains that can throw above.

Note the two renderers in this session differ in their isolation mode (window1/renderer.log:1 says “Extension isolation gate is enabled, effective isolation is enabled”; window2_wb0/renderer.log:1 says “…effective isolation is disabled (forced disabled in glass mode)”). The broken one is the non-glass renderer. That may be a coincidence, but the isolation difference is worth checking against the DI registration path that fails.

If the DI error can be reproduced with a debugger attached to the renderer, the resolved descriptor name at the throw point in getServiceDependencies should identify the missing registration directly.

Files in this package

All paths anonymized — the user’s home-directory name has been replaced with user, and the user’s name and company name have been stripped. A case-insensitive grep across the package confirms no occurrences of either remain.

cursor-bug-followup/
├── SUPPORT-NOTES.md                     ← this file
├── evidence-directory-listings.txt      ← ls of window1/ vs window2_wb0/ proving exthost/ asymmetry; Connect-error counts
├── main.log                             ← session main.log; confirms no update, no doQuitAndInstall
├── sharedprocess.log                    ← confirms no "Deleted marked for removal" at startup
├── window1/
│   └── renderer.log                     ← BROKEN renderer (DI TypeError, 19 Connect errors, no exthost/ dir)
└── window2_wb0/
    └── renderer.log                     ← HEALTHY sibling renderer in the same Cursor process

The broken renderer’s most useful lines:

  • window1/renderer.log:32 — No search provider registered for scheme: file, waiting
  • window1/renderer.log:34 — the $di$dependencies TypeError stack
  • window1/renderer.log:41 onwards — the Connect-transport flood, with full call-site stacks

The healthy sibling renderer (window2_wb0/renderer.log) is included for diff so you can see what successful startup of the same build looks like in the same Cursor process.

14

Thanks for the follow-up and the log package.

You’re right that this is a different path from the original fix. @tarun’s patch addressed the extension cleanup race, which is why 3.6.21 was clean. This recurrence on 3.6.31 has no extension cleanup involved - it’s a different variant of the ext host init failure.

The $di$dependencies TypeError you identified is a known regression in 3.6.31 (fix ready, missed this build by a narrow margin). It may not be the direct cause of the stall itself - but either way, both that regression and the broader ext host init issue are actively being worked on.

Your observation about extension isolation (broken window has it enabled, healthy Glass window has it disabled) is a genuinely useful signal and matches what we’ve been seeing. Isolation spawns multiple extension host processes instead of one, which increases the surface area for these timing-related failures. This has been flagged with the team working on it.

Reload Window (Cmd+Shift+P > Reload Window) remains the workaround. Please update when the next version drops and let us know if the issue persists - both fixes should be in it.

15

Okay thanks, will wait for the next update to see if it is fixed.

Just a small FYI, it seems that reloading doesn’t always fixes the problem, and it stays after (multiple) reloads, killing all cursor processes and restarting usually works better.

17

Just happened again, this time the update restart again:

Cursor unresponsive again on 3.7.21, original update-race bug, not the DI variant

Same fingerprint as the original report:

  • window1/exthost/ never created; No search provider registered for scheme: file, waiting never clears.
  • No Connect transport provider registered. flood begins ~149 s after renderer start (11:10:14 → 11:12:44).
  • Per-renderer: 11 Connect errors in window1, 0 in window2_wb0 (whose exthost/ is populated normally).
  • DI $di$dependencies TypeError from the June 1 session is absent here.

The race is present this session: shared process deleted extensions ~1.8 s after the renderer had already spawned its ext hosts.

window1/renderer.log


11:10:14.627 Started local extension host with pid 78038.
11:10:14.848 Started local extension host with pid 78042. / 78043. / 78044.
11:10:15.039 [warning] No search provider registered for scheme: file, waiting
11:12:44.272 [error] Error fetching user pricing info: No Connect transport provider registered.
11:12:44.275 [error] No Connect transport provider registered.
at YYm.transport (...workbench.desktop.main.js:35612:99621)
at async ex.createSingleServer (...workbench.desktop.main.js:35612:102710)

sharedprocess.log


11:10:16.386 Marked extension as removed anthropic.claude-code-2.1.168-darwin-arm64
11:10:16.386 Marked extension as removed eamodio.gitlens-18.0.0
11:10:16.386 Marked extension as removed google.geminicodeassist-2.85.0
11:10:16.386 Marked extension as removed googlecloudtools.cloudcode-2.40.0
11:10:16.386 Marked extension as removed googlecloudtools.datacloud-0.3.1
11:10:16.386 Marked extension as removed mermaidchart.vscode-mermaid-chart-2.6.8
11:10:16.458 Deleted marked for removal extension from disk anthropic.claude-code .../anthropic.claude-code-2.1.168-darwin-arm64
11:10:16.459 Deleted marked for removal extension from disk eamodio.gitlens .../eamodio.gitlens-18.0.0
11:10:16.459 Deleted marked for removal extension from disk google.geminicodeassist .../google.geminicodeassist-2.85.0
11:10:16.460 Deleted marked for removal extension from disk mermaidchart.vscode-mermaid-chart .../mermaidchart.vscode-mermaid-chart-2.6.8

The original update-uninstall race is still reproducing on 3.7.21 - the patch you described does not appear to have closed this code path. Same symptom, same timing, same per-renderer asymmetry.

18

To be straight with you: the earlier fix addressed one cause of this (the extension-cleanup timing), and it’s in the build you’re on. Your logs show it didn’t close this path, which matches what we’ve found - that fix doesn’t cover the extension that registers the transport provider, so the same broken end state is still reachable.

What’s new since we last talked: the team has narrowed the dominant cause on recent builds to how extension hosts get isolated when a classic editor window and a Glass window run together. The broken window is the non-Glass one with isolation active, the healthy sibling is Glass (where isolation is off) -which lines up exactly with your window1 vs window2_wb0 split. A fix targeting that is going into an upcoming build.

I’m not going to tell you it’s fixed until you can confirm it on your end, since the last “should be fixed” didn’t hold for you. When the next update lands, please give it a run and report back here.

In the meantime, your own observation in your earlier reply is the best recovery: a Reload Window often isn’t enough, but fully quitting Cursor (make sure no Cursor processes are left running) and relaunching reliably brings the window back. That stays the workaround until the fix reaches you.