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:
- 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.
- 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. - 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+.