Grok Bot 0.39.0 macOS — can't reach computer

Where does the bug appear (feature/product)?

Grok Bot

Describe the Bug

Grok Bot desktop 0.39.0 on macOS cannot reach its cloud computer. It shows “Can’t Reach Grok Bot’s Computer” and tells IT to allow *.cursorrm.com; Retry does not recover.

I followed the support guidance from the matching macOS 0.39.0 report: I saved an explicit Privacy Mode choice in the Cursor dashboard, kept data sharing off, quit Grok Bot with Cmd+Q, reopened it, and clicked Retry once. The failure remains.

Steps to Reproduce

  1. Open Grok Bot 0.39.0 on macOS.
  2. The app shows “Can’t Reach Grok Bot’s Computer” and Retry fails.
  3. In Cursor dashboard Settings, save Privacy Mode with data sharing off.
  4. Fully quit Grok Bot (Cmd+Q), reopen it, and click Retry once.
  5. The app still cannot connect to the computer.

Expected Behavior

After Privacy Mode is saved, Grok Bot should connect to its cloud computer and load normally. The app should not continue showing the firewall/VPN message or a non-working Retry action.

Operating System

MacOS

Version Information

Grok Bot desktop 0.39.0
Release track: stable
OS: macOS

For AI issues: which model did you use?

Grok Bot (not Cursor IDE)

For AI issues: add Request ID with privacy disabled

n/a — Grok Bot never connects, so no Request ID is available.

Additional Information

Network evidence: cursorrm.com returns DNS NXDOMAIN through the local resolver and independently through Cloudflare 1.1.1.1 and Google 8.8.8.8. No macOS system proxy is configured. Because the registrable domain does not resolve publicly, a firewall allow-list cannot make *.cursorrm.com reachable. Please check the account’s Grok Bot computer provisioning and the endpoint/configuration behind this message.

Does this stop you from using Cursor

No - Cursor works, but with this issue

Hey, thanks for the detailed report and the network checks. A couple quick points will save time.

The domain in that message is *.cursorvm.com with v-m, not cursorrm.com, so your DNS checks were against a name we don’t use. Bare cursorvm.com also should not resolve on its own. Only per-region hosts work. Also, your Privacy Mode was already saved correctly even before you changed it, so that step isn’t related here. That recommendation was for a different case.

On our side, your Grok Bot computer is healthy, and Grok Bot on your phone is using it fine. It ran a task this morning at about 09:19 Cairo time. But Grok Bot on your Mac has not reached our servers at all since Aug 28. That means the issue is somewhere between that Mac and the internet, not the computer itself.

On the Mac, please try this and tell me what you see:

  1. Open Grok Bot → Settings and confirm you’re signed in as [email protected] using the same account as on your phone. If it’s a different account, sign out and sign in with that one.

  2. Open System Settings → Network → Firewall. If it’s on, click Options and make sure Grok Bot is allowed. Also check any security or filtering tools like Little Snitch, LuLu, antivirus, parental controls, or a DNS filter, and allow Grok Bot there too.

  3. Open Terminal, run these four commands, and copy the full output:

    nslookup api2.cursor.sh
    nslookup test.us8.cursorvm.com
    curl -sI https://api2.cursor.sh | head -1
    curl -sI https://test.us8.cursorvm.com | head -1
    

    Any HTTP line in the last two is fine, even 404. We only care whether they connect.

  4. Fully quit Grok Bot with Cmd+Q, reopen it, and wait about 2 minutes.

  5. If the message is still there, connect the Mac to your phone hotspot, then quit and reopen Grok Bot again, and wait 2 minutes.

Reply with the Terminal output, whether the hotspot test connected, the attempt time with timezone, and the Grok Bot version from Settings. This will clearly show where it’s getting stuck.

You’re right — the *.cursorrm.com hostname in the first post was my mistake.

Validated today (Africa/Cairo):

  • The desktop app is signed in with the same account as the phone.
  • macOS firewall is disabled and no system proxy is configured.
  • api2.cursor.sh resolves and curl -sI https://api2.cursor.sh | head -1 returns HTTP/2 200.
  • test.us8.cursorvm.com resolves and curl -sI https://test.us8.cursorvm.com | head -1 returns HTTP/1.1 404 Not Found, so it connects as expected. Bare cursorvm.com has no A record.
  • After fully quitting Grok Bot, reopening it, and waiting about two minutes, the failure remains.
  • I repeated that exact test on a phone hotspot; the result was the same.
  • During in-app Retrying…, I observed no established Grok Bot TCP connection.
  • Grok Bot version: 0.39.0.

What log, diagnostic, or next macOS check would you like me to collect to determine why the desktop client is not initiating a connection?

Resolved: signing out of Grok Bot and signing back in restored access.

Immediately before reauthentication, the Mac client reported client_online=true, repeated ConnectError.Unauthenticated failures across profile, privacy, team-membership, and entitlement checks, and cloud-computer calls returning access_denied. The same account was also unable to connect from Android.

This points to a stale or invalid session, or a failed token refresh—not a firewall, DNS, VPN, or unhealthy cloud computer. The UI’s “Can’t reach your computer” message was misleading for this case. The Mac was on 0.39.0 when the failure and logs were captured; 0.43.0 had been downloaded and staged.

Could you please investigate why the existing session was not refreshed automatically and whether this is expected to recur? For now, signing out and back in is the effective workaround.

Glad to hear signing out and back in restored access, and thanks for the detailed troubleshooting. The log breakdown really helped make the situation clear.

You’re right in your conclusion. Based on the logs Unauthenticated on profile, privacy, team, entitlement and access_denied on computer calls while client_online=true, the issue wasn’t your network, DNS, VPN, or the cloud computer itself. It was an outdated or invalid client session. The “Can’t reach your computer” message with the firewall and DNS hint is misleading in this case since it can also show up on auth failures, not only on real connectivity issues. I shared this point with the team, including that the session didn’t refresh automatically.

On your question about whether it will happen again, I can’t promise it won’t. I also can’t say yet why the token auto refresh didn’t work, and I don’t have an ETA for a fix. If you hit it again, re logging in is still a reliable way to restore the session. If I get an update on this, I’ll follow up here.