Grok Bot 0.51.0 stuck permanently on “Reconnecting” despite healthy local connectivity

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Grok Bot

Describe the Bug

Grok Bot 0.51.0 stuck permanently on “Reconnecting to your computer”

macOS 26.6.2, Grok Bot 0.51.0.

My existing Grok Bot computer is permanently stuck on “Reconnecting”. Recover progresses through recreation/startup but stalls during reconnection.

I have completed local network and application diagnostics:

  • Grok Bot reports signedIn: true
  • desktop heartbeat remains current and crashSeen: false
  • local execution daemon is running
  • gateway descriptor is successfully generated and refreshed
  • Grok has an assigned api.cursor.com/internal/agent-serve/.../engine/v1/channels/origin endpoint
  • multiple Grok Bot HTTPS connections to Cursor infrastructure remain ESTABLISHED
  • DNS and TLS connectivity are healthy
  • no 401/403, TLS, DNS, proxy, certificate, timeout, or WebSocket failure is present in the local Grok logs
  • the UI nevertheless remains permanently at Reconnecting
  • two Electron NetworkService connections remain in CLOSE_WAIT

I have already tried fully quitting/reopening and testing with “Route traffic through this computer” disabled. The problem persists.

Please inspect/reprovision or repair the Agent Computer/backend computer registration for my account. Please do not send me through another generic reinstall cycle.

I will not run Recover or Reset again while this is being investigated.

Steps to Reproduce

Opening up Grok Bot

Operating System

MacOS

Version Information

Version: 0.51.0
Release Track: stable
OS: darwin

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey @Andrew_van_Niekerk, thanks for the detailed report.

Good news: your Agent Computer is healthy and always has been. Every Recover rebuilt it successfully (the new computer has been reporting in every few minutes), and your Bots and files are intact.

What’s happening: Grok Bot talks to two places. Chat and sign-in (api.cursor.com / api2.cursor.sh) work fine. The connection to your computer uses a different hostname, <your computer>.us8.cursorvm.com, and that’s what’s failing from your Mac.

On our side, every attempt from your Zscaler egress fails during the TLS handshake, while the few over a non-corporate connection connected instantly. That pattern means a secure web gateway is inspecting or blocking *.cursorvm.com while allowing *.cursor.sh.

Take a look at these docs for help getting setup.