App boot freeze: IPC timeout (McpProcess/ptyHost) paired with Chromium net::ERR_TIMED_OUT and GPU Virtualization Failure

Support Bug Reports
, , , ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I am completely locked out of using or authenticating Cursor due to a catastrophic failure loop occurring immediately upon application startup. Running --trace-deprecation and capturing terminal outputs shows two deep, concurrent issues within the application’s core infrastructure:

  1. Internal Engine Death (IPC & Pseudoterminal Timeout)
    On boot, the application consistently logs a 10-second failure to initialize the local loopback channel, followed immediately by a terminal subsystem flatline:

[McpProcess] timed out waiting for ipcReady after 10000ms

No ptyHost heartbeat after 6 seconds

This is completely isolating the UI layer, preventing it from processing deep-link callbacks (cursor://authenticator/callback) or reading manual tokens injected into globalStorage/storage.json.

  1. Hardware & Network Isolation (kFatalFailure)
    Simultaneously, the Chromium engine logs major rendering context issues when executing on machines with local hypervisor layers active (Core Isolation / Windows Sandbox environment):

ERROR:gpu\ipc\service\gpu_channel_manager.cc] ContextResult::kFatalFailure: Failed to create shared context for virtualization.

error undefined net::ERR_TIMED_OUT

Even when local firewalls are completely lowered and standard OS-level DNS resolution (nslookup api2.cursor.sh) works perfectly, the internal SimpleURLLoaderWrapper within Cursor is uniquely blinded, dropping all outbound connections and failing update checks.

Steps to Reproduce

Steps Taken That Failed:
Full directory cleanup (AppData\Local / AppData\Roaming).

Transitioning from User Installer to full administrative System Installer (C:\Program Files).

Disabling hardware sandboxing (–no-sandbox --disable-gpu).

Overriding local network adapter DNS routing.

Manually injecting storage.json tokens (the app still freezes up on the ptyHost 6-second heartbeat checkpoint before parsing the file).

Expected Behavior

Please look into how the modern 3.5.x Electron/Chromium pipeline initializes its internal shared virtualization context and handles IPC loopbacks on Windows machines running active low-level security mitigations.

Operating System

Windows 10/11

Version Information

Cursor Version: 3.5.38 (System Installer)

Does this stop you from using Cursor

Yes - Cursor is unusable

5

Hey, thanks for the detailed report, the symptoms match a known pattern. This combo of Chromium kFatalFailure: shared context for virtualization plus McpProcess ipcReady timeout plus ptyHost heartbeat is a known cascade on Windows machines where Core Isolation HVCI, Windows Sandbox, or an aggressive AV or EDR blocks Chromium from creating a shared GPU context. Then IPC fails, then ptyHost fails, and the UI layer doesn’t have time to handle the deep link auth callback. We’re tracking this on our side, but there’s no ETA for a fix yet.

Since you’ve already tried the basic steps, here’s what usually helps in this type of case, and what you might not have tried yet:

  1. Core Isolation → Memory Integrity = Off: Windows Security → Device Security → Core Isolation details → turn off Memory Integrity, then reboot. This is the most common cause of kFatalFailure in your logs.

  2. Add exclusions in Microsoft Defender or your EDR: add these to Real time Protection exclusions:

    • %LOCALAPPDATA%\Programs\cursor\ (or the System Installer path)
    • %APPDATA%\Cursor\
    • %USERPROFILE%\.cursor\
    • Processes: Cursor.exe, CursorHelper.exe

    If you have a corporate EDR like CrowdStrike, SentinelOne, or Defender for Endpoint, check whether Cursor shows up in block or quarantine logs.

  3. Clean extensions dir plus a separate GPU sandbox flag:

    cursor --extensions-dir C:\cursor-extensions --disable-gpu-sandbox

    --disable-gpu-sandbox on its own, not --disable-gpu, sometimes avoids the virtualization context failure without killing the rest of the GPU pipeline. If it doesn’t help, try the more aggressive option:

    cursor --extensions-dir C:\cursor-extensions --no-sandbox

    --no-sandbox disables sandboxing completely, including GPU and renderer processes. It’s less safe, but it helps confirm whether the issue is in the sandboxing layer.

  4. Windows Sandbox, WSL, Hyper-V: if Windows Sandbox is enabled

    Get-WindowsOptionalFeature -Online -FeatureName Containers-DisposableClientVM

    try disabling it and rebooting. It can compete for the hypervisor context.

If any of this gets you to the UI, let me know which step worked, it’ll help narrow down the root cause. If nothing helps, share the output of cursor --status if it runs, plus a screenshot of Windows Security → Device Security, and we can dig deeper.