Stale host bundle blocks local-exec, update control unresponsive

Support Help
1

Same failure on 0.44.0 (Stable, “You’re up to date”), macOS 26.6, Mac mini — but the leftover-process workaround in this thread does not apply here, because the helper is healthy and connected and the assistant still cannot reach the machine.

What the app reports. The helper restarts in a loop, each instance killed immediately after start:

[sand-local-exec-daemon] started (pid 11047); serving local exec over the gateway
    [sand-local-exec-daemon] received SIGTERM, shutting down {"error":"cli_unknown_command"}
    [sand-local-exec-daemon] started (pid 11222); serving local exec over the gateway
    [sand-local-exec-daemon] received SIGTERM, shutting down {"error":"cli_unknown_command"}
    ... repeats for pids 11305, 11318, 11419 ...

A 401 against the gateway was also reported before a reboot.

The cli_unknown_command seems worth attention: the app bundle ships no cursor or sand CLI binary (only cursor_proclist.node), and there is no cursor/sand/grok executable anywhere on PATH. So nothing local can be shadowing or answering that command.

**Ruled out on this machine.** Each checked directly rather than assumed:

* Full Disk Access — granted (kTCCServiceSystemPolicyAllFiles, auth 2, in the system TCC database)
* Code signature — valid and unmodified, Developer ID Anysphere (DCNK4UB866)
* App location — /Applications, not translocated or quarantined
* Settings > Computer > Execution — Always allow
* Settings > Computer > Current computer — matches hostname exactly
* Conflicting CLI on PATH — none
* macOS firewall — disabled
* Proxy / PAC — none configured
* VPN interception — a VPN client is installed but not routing; default route is the ordinary LAN
* MTU — 1472-byte payloads pass, so no fragmentation black hole
* DNS — clean, no interception
* Endpoints — api2.cursor.sh 200, cursor.com 200, api.cursor.com 200

**Current state.** After a reboot the helper stopped flapping: one process, stable for 17+ minutes, holding an established TLS connection to the gateway, with crashSeen false in sand-session-marker.json. It is healthy and connected, and the assistant still reports it cannot see the machine — so this looks like a registration or authorisation failure at the gateway rather than local process cleanup.

Separately, attaching a 12 kB .md file and sending it fails with a network error, while ordinary chat messages send fine over the same connection.

Three questions that would help:

1. What does cli_unknown_command correspond to server-side on 0.44.0?
2. Does the 401 mean the daemon's registration token is rejected independently of the app session, which is signed in and working?
3. Is the attachment upload failure the same authorisation path?

Happy to supply more detail if useful.
4

Hey @Maaz_Kazi, thanks for the detailed report, and you were right to rule out the local side. Your helper is connected fine on our end. What is out of date is Grok Bot’s cloud computer: it came back up on an older internal build that does not know how to see the helper, so the assistant keeps reporting your Mac as unavailable even though everything on the Mac is healthy. Attaching files fails for the same reason, since that older build does not understand how the current app uploads them.

The fix is on the cloud side and takes a minute:

  1. In Grok Bot, open Settings, then Updates.
  2. Click “Update Grok Bot’s Computer” and wait for it to finish (your bots, files, and logins are kept).
  3. Send your bot a quick test like “run hostname on my Mac”, and try the .md attachment again.
5

Thanks Colin, that matches what I see, and the stale build is confirmed: I asked the bot to run uname -a on its cloud computer and it returned a kernel dated Tue Jul 28 2026.

The problem is that I cannot follow step 2. “Update Grok Bot’s Computer” is greyed out and does nothing.

What I have checked:

  • The cloud computer is running, not asleep. It executed uname -a and returned output while the button was still disabled.
    • A Bot chat is open, so the hint under Reset (“Open a Bot to reset the shared computer”) appears to be satisfied. Reset is greyed too.
      • Hovering the Update button shows no tooltip or reason; clicking it does nothing at all.
        • Same after a full quit, killing every leftover local-exec-daemon, and relaunching, so the helper had to re-register from scratch. It came back as a single stable process with a live connection to the gateway.
          • Client is 0.44.0 on Stable, reporting “You’re up to date”. Stable is the only entry in the Update Track dropdown, so there is no earlier track to switch to.
        • Is there another condition that gates that button, or can the cloud computer be updated from your side? Happy to run anything that would help narrow it.
6

Hi @Maaz_Kazi!

I’ve tweaked some knobs in the backend. Can you try restarting Grok Bot (the app) and let me know if it’s working again?

7

restarted the app and local-exec is working:

  • hostname on my Mac returns the correct machine name, and the bot confirms the Mac is reachable.

Thanks for turning this around quickly.