Complete UI Freeze (Blank Grey Screen) on Restoring Multiple Heavy Workspaces concurrently (Log Analysis)

Support Bug Reports
, , ,
1

Bug Description

When launching Cursor with multiple concurrently restored window sessions containing large frontend/TypeScript codebases (such as Monorepos), the editor undergoes a ​severe UI freeze (completely grey/blank main editor area, non-rendering sidebar, and empty terminal panels) lasting between 40 to 90 seconds​.

Telemetry logs confirm systemic eventLoop starvation across all window renderer processes simultaneously. When the main thread finally recovers, the Connect (gRPC) transport client fails to initialize, producing cascading No Connect transport provider registered errors.

截屏2026-06-01 10.20.27
截屏2026-06-01 10.20.271023×666 20.2 KB

System Environment

  • Cursor Version: 3.4.20 (Stable)
  • VS Code Engine: 1.105.1
  • Host OS: macOS (Darwin arm64, Apple Silicon)
  • Active Projects on Startup: 3 windows restored concurrently:
    1. /Users/username/Documents/project/monorepo-project-a (Multi-folder workspace containing sub-package-x and sub-package-y)
    2. /Users/username/Documents/project/frontend-workspace-b
    3. /Users/username/Documents/project/frontend-workspace-c

Chronological Telemetry & Logs Evidence (Verified Facts)

We captured and analyzed the local telemetry logs under the session folder 20260601T093359 (attached as a zip). The engineering facts are detailed below:

1. Global eventLoop Starvation Gaps

All three active Electron window renderer processes recorded matching thread-freeze timestamps:

  • Window 1 (window1/renderer.log):
2026-06-01 09:35:04.165 [warning] Missing property "rpcFileLoggerFolder" in oldValue...
2026-06-01 09:36:32.179 [error] Error fetching user pricing info: No Connect transport provider registered.
[logs.zip|attachment](upload://2GAEWy2Fl6Yk0YsL77sZkFfL9bq.zip) (127.8 KB)

​

  • Fact: The main event loop was completely suspended for 88.014 seconds (09:35:04.165 to 09:36:32.179).
  • Window 2 (window2/renderer.log):
    • Freeze Gap A: 09:35:04.162 to 09:35:41.149 (36.987s block).
    • Freeze Gap B: 09:35:41.149 to 09:36:31.710 (50.561s block).
  • Window 3 (window3/renderer.log):
    • Freeze Gap A: 09:35:02.157 to 09:35:41.151 (38.994s block).
    • Freeze Gap B: 09:35:41.151 to 09:36:31.711 (50.560s block).

Verdict: The synchronous blockage across all windows confirms a global process deadlock or absolute host CPU/IO saturation.

2. Excessive Process Topology via Extension Isolation

Cursor’s Extension Isolation dynamically spawns multiple Extension Host PIDs per window:

  • Window 1 PIDs: 2577 (Main), 2589 (retrieval), 2590 (always-local), 2591 (agent-exec)
  • Window 2 PIDs: 2576 (Main), 2592 (retrieval), 2593 (always-local), 2594 (agent-exec)
  • Window 3 PIDs: 2578 (Main), 2595 (retrieval), 2596 (always-local), 2597 (agent-exec)

Verdict: Simultaneously restoring 3 workspaces instantly spawns 12 separate Node.js extension host processes concurrently. This causes massive OS context-switching thrashing and CPU scheduler overload on boot.

3. Overloaded Shared Process I/O Queue

During this critical startup window, the single background Shared Process was executing a highly congested batch of I/O heavy operations:

  • ZIP Decompression/Install: At 09:34:13, it was unzipping/installing massive .vsix packages for both openai.chatgpt (v26.527.31454) and anthropic.claude-code (v2.1.159).
  • Network Updates: At 09:34:32, UpdateService triggered a background binary update download for the stable package.
  • Manifest Timeouts: Handshaking timed out at 09:34:08.722 with: Error getting extensions control manifest Timeout getting extensions control.
  • Terminal Replay Strain: At 09:34:03.879, ptyhost.log records it was actively reviving 6 orphan shell sessions and replaying a buffer of ​7980 characters​.

4. Downstream Connect gRPC Failure

Once the main thread event loop recovered from the 88-second freeze, the Connect (gRPC) client registered transport failures:

2026-06-01 09:36:32.181 [error] No Connect transport provider registered.: Error: No Connect transport provider registered.
    at OAd.transport (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:29836:109883)

​

The Connect transport provider registration failed asynchronously due to the prolonged eventLoop starvation.

Where does the bug appear (feature/product)?

  • Cursor IDE
  • Cursor CLI
  • Background Agent (GitHub, Slack, Web, Linear)
  • BugBot
  • Somewhere else…

Describe the Bug

When restoring multiple windows concurrently on startup (specifically 3 windows containing large TypeScript Monorepos and frontend codebases), the entire editor undergoes a complete UI freeze (grey/blank main editor area, non-rendering sidebar, and empty terminal panels) lasting between 40 to 90 seconds.

Our telemetry logs confirm systemic eventLoop starvation across all window renderer processes simultaneously. When the main thread finally recovers, the Connect (gRPC) transport client fails to initialize, producing cascading No Connect transport provider registered errors due to registration callbacks timing out.

Steps to Reproduce

  1. Configure Cursor to restore multiple windows on startup ("window.restoreWindows": "all").
  2. Open 3 separate windows containing large frontend workspaces/TypeScript Monorepos (with deep node_modules).
  3. (Optional to guarantee bottleneck) Trigger background extension updates/installations (such as Claude Code or ChatGPT extensions) or application updates to simulate concurrent Shared Process write operations.
  4. Relaunch Cursor. The editor will restore all windows simultaneously, spawning PIDs for all isolated AI extension host processes, and trigger a systemic eventLoop dead-lock for up to 90 seconds.

Expected Behavior

  • Workspace windows should initialize asynchronously or stagger their process-spawning sequences.
  • Shared Process background disk writes (such as ZIP extractions and application package downloads) should be queued or throttled during the initial 60 seconds of startup.
  • The Electron UI rendering thread (eventLoop) should remain responsive and not be starved by background I/O operations.

Screenshots / Screen Recordings

(Please refer to/attach the screenshot showing the completely blank editor workspace with a single grey border in the middle, empty panels, and a frozen sidebar.)

Operating System

  • Windows 10/11
  • MacOS (Apple Silicon)
  • Linux

Version Information

For Cursor IDE:

  • Version: 3.4.20 (Stable)
  • VSCode Version: 1.105.1
  • Commit: (Can be copied from: Menu → About Cursor → Copy)

Additional Information

  • Anonymized Telemetry Logs: We have fully audited and anonymized the diagnostic logs for the active session (20260601T093359) and attached them as logs.zip.
  • Key Log Findings:
    • window1/renderer.log logs a mathematically verified eventLoop block of exactly 88.014 seconds (09:35:04.165 to 09:36:32.179).
    • Process Spawning: Spawns exactly 12 concurrent Node.js extension host processes (4 per window due to Extension Isolation) concurrently, resulting in massive scheduler overhead.
    • Shared Process Congestion: Simultaneously executes large .vsix ZIP extraction, application update downloading, and terminal history replay for 6 orphan shells at the exact same time window.

Does this stop you from using Cursor?

  • Yes - Cursor is unusable (The editor becomes completely frozen and non-responsive upon launch when restoring multiple windows).
  • Sometimes - I can sometimes use Cursor
  • No - Cursor works, but with this issue
2

Hi there!

We detected that this may be a bug report, so we’ve moved your post to the Bug Reports category.

To help us investigate and fix this faster, could you edit your original post to include the details from the template below?

Bug Report Template - Click to expand

Where does the bug appear (feature/product)?

  • Cursor IDE
  • Cursor CLI
  • Background Agent (GitHub, Slack, Web, Linear)
  • BugBot
  • Somewhere else…

Describe the Bug
A clear and concise description of what the bug is.

Steps to Reproduce
How can you reproduce this bug? We have a much better chance at fixing issues if we can reproduce them!

  1. …
  2. …
  3. …

Expected Behavior
What is meant to happen here that isn’t working correctly?

Screenshots / Screen Recordings
If applicable, attach images or videos (.jpg, .png, .gif, .mp4, .mov)

Operating System

  • Windows 10/11
  • MacOS
  • Linux

Version Information

  • For Cursor IDE: Menu → About Cursor → Copy
  • For Cursor CLI: Run agent about in your terminal
IDE:
Version: 2.xx.x
VSCode Version: 1.105.1
Commit: ......

CLI:
CLI Version 2026.01.17-d239e66

For AI issues: which model did you use?
Model name (e.g., Sonnet 4, Tab…)

For AI issues: add Request ID with privacy disabled
Request ID: f9a7046a-279b-47e5-ab48-6e8dc12daba1
For Background Agent issues, also post the ID: bc-…

Additional Information
Add any other context about the problem here.

Does this stop you from using Cursor?

  • Yes - Cursor is unusable
  • Sometimes - I can sometimes use Cursor
  • No - Cursor works, but with this issue

The more details you provide, the easier it is for us to reproduce and fix the issue. Thanks!

6

Hey, thanks for the report. This is one of the most detailed log analyses we’ve seen for this scenario. I can see the screenshot with a completely blank editor (gray frame in the center, sidebar not rendering, and empty panels).

This is a known failure class. No Connect transport provider registered shows up when the extension host for a window doesn’t register the transport provider within the timeout. When multiple heavy windows restore at the same time, it can start 12 ext-host processes at once, plus competing .vsix unpacking, a binary update, and terminal replay in the Shared Process. The event loop starvation you measured (88s in window1) is exactly this effect. Related threads for context: Extension Host fails to initialize (Timeout waiting for auth and plugins), breaking AI Agents and Source Control and Timeout waiting for EverythingProvider Error.

A few things to try right now:

  1. Update to the latest stable. You’re on 3.4.20. In 3.6.18 we shipped a partial fix for one trigger in this class (a race during cleanup after auto-update). It doesn’t fully cover the multi-window scenario, but it does reduce some startup load.
  2. Don’t restore all windows at once. Set "window.restoreWindows": "one" (or "none") and open heavy workspaces one by one, with a pause. This avoids the simultaneous spawn of 12 processes that hits the timeout.
  3. If you can, let Cursor finish installing extensions and any updates on the first launch, then open heavy monorepos on the next run so Shared Process I/O isn’t competing with window startup.

About the bug itself: this is known, and I’ve shared your analysis internally. I can’t give an ETA yet. When there’s an update, I’ll reply in the thread.

Let me know if the workaround with restoreWindows: "one" helps on 3.6.18+.