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

Support Bug Reports
,
25

@deanrie I’m running 3.3.27, issue still happening routinely

26

Multiple Cursor instances. Because of the nature of my work, I normally work in parallel in different repos.

27

Hey, thanks for the follow-ups.

@Nikola_Spiric Confirming 3.3.27 still hits this is an important data point. That tells us the fix isn’t in any current stable. I’ll add it to the issue we’re tracking.

@eraffoul Two useful confirmations from your side: parallel multi-Cursor plus a cold start (laptop restart or Cursor upgrade) is the trigger, and File > New Window from a healthy instance doesn’t resolve it. The second one rules out the shared main process registers providers once theory I mentioned. Useful, so thank you.

What this tells us together: it’s not just second window in the same main process. It’s closer to fresh per-window provider initialization racing something on cold start when more than one window is loading at the same time. I’m updating the issue with all of this.

Honest status: still no ETA. The investigation on our side is active and your logs are feeding it directly. I won’t commit to a date I can’t hold.

One more diagnostic that would help, when you’re willing:

  • @eraffoul: when it reproduces after a cold start, are the windows opening at roughly the same time, for example session restore opens both at once, or do you open them one after another? If it’s session restore, does disabling Restore windows in settings, or starting with --disable-workspace-trust, or opening a single window first and waiting for it to fully load before opening the second change the outcome?
  • @Nikola_Spiric: same question, plus, in 3.3.27, is it still specifically the 3rd instance, or does the 2nd one hang now too?

When there’s movement on the fix, I’ll post in the thread.

28

Usually I open one, then the another. I could give it a try to --disable-workspace-trust and see if it has any different outcome

29

@deanrie sometimes even opening the first instance hangs

As a side note, this is still reproducible for me in 3.3.30

Is there any ETA on the fix ?

30

Hey Nikola, thanks for the 3.3.30 datapoint. The fact that even the first instance hangs now is important. It widens the picture beyond the multi-window theory we had earlier. I’m adding that to the issue we’re tracking.

Honest status on ETA: I don’t have a date I can commit to. The investigation on our side is active, but I won’t promise a timeline I can’t hold. When there’s movement on the fix, I’ll post in this thread.

To strengthen the new single-instance angle, the most useful thing right now would be one fresh repro from a cold start with only one Cursor window:

  1. Fully quit Cursor and make sure no cursor processes are running.
  2. Start Cursor and open the workspace that hangs. Don’t open a second window.
  3. When it hangs, open Developer Tools Cmd+Ctrl+Shift+P → Developer: Toggle Developer Tools and copy the full Console output.
  4. Also export logs: Cmd+Ctrl+Shift+P → Developer: Open Logs Folder, zip main.log, renderer.log for the affected window, and sharedprocess.log.

A few quick questions:

  • Does it happen on any workspace, or only this one?
  • Is anything else changing between successful and failed cold starts, like a recently updated extension, a new MCP config, or a kernel update on the Linux host?
  • When the first instance hangs, does closing and reopening just that window fix it, the same as before with the second instance?

I know this has been disruptive for a month now, and I appreciate you sticking with it and sending repros. The logs are what keeps the issue moving on our side.

31

@deanrie

  1. Made sure no cursor instances are running
  2. Started cursor in the affected workspace
  3. Dumped and attached console and other logs as requeste

20260514T161732.zip (6.0 KB)

vscode-app-1778768330173.txt (29.2 KB)

  1. At the moment I have a single workspace where I can reliably reproduce this. But like i said this is not always the case. It reproduces randomly, the issue comes and goes away randomly
  2. Absolutely nothing changing
  3. Sometimes yes, sometimes no, like i said the behavior seems random
32

@deanrie Any updates from the logs?

I am seriously considering canceling my subscription at this point.

I am paying for a service that is completely non-functional for my setup.

The troubleshooting steps and questions so far do not give me confidence that this is actually being treated as a bug or that any development resources are allocated to fixing it.

34

i encountered the same issue just now, all exentions seem to be stuck with loading state in cursor v3.4.17
Upon investigation, the cause seem to be extensions all tried to activate at once on startup (onStartupFinished), and the extension host process would hang within 3-5 seconds. Once it hung, all webview-based extensions showed infinite loading spinners because they depend on the extension host to render their UI.

I did the following and now it works:

  1. Added extensions.experimental.affinity settings — this is the key fix. It isolates
    heavy extensions into their own separate extension host processes so they can’t block each
    other.

  2. Increased Node.js heap in

    ~/.cursor/argv.json(–max-old-space-size=8192).

  3. Cleared stale caches (workspace storage, GPU cache, old logs)

Please report if the above steps works for you as well.

36

Thanks for the cold-start repro on 3.3.30. The logs confirm what we suspected. The EH processes are spawning, I see 4 hosts started with PIDs in the log, but the auth-ready signal from cursor-always-local never fires. You also get an early extensionRecommendationNotification channel timeout in sharedProcess. That’s a useful new detail.

Two things stand out in the log that I’d like to isolate before we go further:

  1. Workspace-specific vs install-wide. You mentioned this reproduces reliably on one workspace. Can you try a cold start on a completely different folder, for example a fresh empty directory, mkdir /tmp/test-cursor && cursor /tmp/test-cursor? If that one loads fine, the trigger is something in the affected workspace’s storage or files.

  2. Extension involvement. You have a heavy mixed extension set, Anthropic.claude-code, github.copilot-chat, ms-azuretools.vscode-azure-github-copilot, python tools, java pack, gitlens. On the hanging workspace specifically, please try:

cursor --disable-extensions /path/to/affected/workspace

Cold start, no other instances. If auth-ready comes through and the window loads, we’ve narrowed it to a third-party extension racing cursor-always-local. Then we can bisect by re-enabling halves.

Both of these together should rule in or out workspace state and third-party extension involvement, which are the two remaining big unknowns now that the multi-window theory is no longer the whole story.

On ETA, there’s still no date I can commit to. The investigation is active and your logs feed it directly. When there’s movement, I’ll post here.

37
  1. Like I said the issue happens randomly, in some cases workspace opens fine, in others there’s a stubborn one where it fails almost always
  2. Issue is reproduced with cold start into affected workspace, with –disable-extensions

@deanrie looking at your responses and questions, it is clear we are no closer to a fix than we were when I opened this issue a month ago.

Because of this, I am canceling my subscription and moving to another provider.

For an “AI-first” company, the lack of progress and technical support on a core functionality issue is incredibly disappointing.

39

Hello, have you tried closing all the open files in the workspace (the one with the problem), closing the workspace, and then reopening it?
I often work with multiple Cursor windows across different workspaces, and I frequently encounter this error, this solution works pretty well for me.

41

Thank you! I tried this suggestion a few days now and it’s the only thing that actually works. I hope this is getting fixed soon.

42

Thanks for this.