Grok Bot 0.29.0 on Mac (Apple silicon, Johns-MacBook-Air-M2).
Chat works. Local execution does not.
Exact error from the agent:
Your local machine isn’t connected right now
(and: “Your local Mac is not connected, so I have no computer available for local execution.”)
Time: 2026-08-27, ~1:11pm–2:48pm Pacific.
Already tried:
App open and online (chat fine)
Mac restart, app reopen
Hard quit + kill leftover local-exec-daemon processes
Moved aside local-exec-daemon-credential.json and local-exec-daemon-connection.json; fresh files minted at 14:44/14:45
Execution policy is not the blocker (agent never reached an approval prompt)
Current local state:
One app process + one daemon pid 12006
After “started (pid 12006); serving local exec over the gateway” there are no further log lines
This is a different issue from the one fixed earlier in the other thread so I split it off.
It looks like your helper process is starting fine, but its connection to our servers keeps dropping right after it registers, which is why your Mac shows as offline while chat still works. There’s no manual attach step, the registration happens automatically once that connection holds, so there’s nothing account-side to reset (and your cloud computer is untouched).
Some components on our side were updated since you posted. Could you fully quit and reopen the app, then let us know if local commands still fail? If they do, the most recent lines of ~/.grokbot/local-exec-daemon.log from right after the relaunch would help us narrow down where the connection is failing.
Same issue here. Grok Bot desktop on Mac. Chat works. Local execution does not.
Already tried: fully quit and reopen the app, no leftover Grok or local-exec-daemon processes, Computer set to this Mac with Ask every time. Agent never reaches an approval card. Error is still: “Your local machine isn’t connected right now (the Grok Bot desktop app must be open and online to run commands on it).”
~/.grokbot/local-exec-daemon.log after relaunch:
[sand-local-exec-daemon] started (pid 95041); serving local exec over the gateway
[sand-local-exec-daemon] started (pid 95042); serving local exec over the gateway
[sand-local-exec-daemon] received SIGTERM, shutting down
[sand-local-exec-daemon] started (pid 95804); serving local exec over the gateway
[sand-local-exec-daemon] received SIGTERM, shutting down
[sand-local-exec-daemon] started (pid 95811); serving local exec over the gateway
[sand-local-exec-daemon] received SIGTERM, shutting down
[sand-local-exec-daemon] started (pid 96110); serving local exec over the gateway
[sand-local-exec-daemon] received SIGTERM, shutting down
[sand-local-exec-daemon] started (pid 2083); serving local exec over the gateway
[local-exec-provider] dropping 1-frame response batch after 3 failed POSTs: Error (http_417)
[local-exec-provider] dropping 1-frame response batch after 3 failed POSTs: Error (http_417)
[local-exec-provider] dropping 1-frame response batch after 3 failed POSTs: Error (http_417)
[sand-local-exec-daemon] started (pid 44133); serving local exec over the gateway
[local-exec-provider] dropping 1-frame response batch after 3 failed POSTs: Error
[sand-local-exec-daemon] received SIGTERM, shutting down
{"error":"cli_unknown_command"}
[sand-local-exec-daemon] started (pid 44376); serving local exec over the gateway
[sand-local-exec-daemon] received SIGTERM, shutting down
{"error":"cli_unknown_command"}
[sand-local-exec-daemon] started (pid 50639); serving local exec over the gateway
[sand-local-exec-daemon] received SIGTERM, shutting down
{"error":"cli_unknown_command"}
[sand-local-exec-daemon] started (pid 50797); serving local exec over the gateway
[sand-local-exec-daemon] received SIGTERM, shutting down
{"error":"cli_unknown_command"}
[sand-local-exec-daemon] started (pid 51097); serving local exec over the gateway
[sand-local-exec-daemon] received SIGTERM, shutting down
{"error":"cli_unknown_command"}
[sand-local-exec-daemon] started (pid 53465); serving local exec over the gateway
Helper starts, gateway POSTs fail with http_417, then cli_unknown_command, then SIGTERM, then it loops. Never stays registered.
Same issue here on Grok Bot 0.30.0, macOS (Apple silicon). Chat and the cloud computer work, but every Bot reports that the desktop is not connected as a local-exec provider.
I’ve verified this is not the usual client/process/network case:
One healthy local-exec daemon; inflightCount: 0, generation: 0
Two established TLS connections to api2.cursor.sh
The gateway negotiates TLS 1.3 successfully and the certificate verifies
api2.cursor.sh negotiates HTTP/2 and returns HTTP 200
No macOS system proxy; Cloudflare WARP is installed but disconnected; normal en0 route
Settings → Computer identifies this Mac as Current computer; Always allow is enabled
I changed and saved the label to Jacos-MacBook-Pro-reconnect; the local connection record was resealed immediately, confirming the machine-record update completed
A subsequent printf grok-local-ok request still never reached the daemon; inflightCount remained 0
Already tried fully quitting/reopening, restarting the Mac, reinstalling Grok Bot, killing leftover daemons, and moving aside the credential/connection files so fresh identities were minted.
This now looks registered but unrouted, rather than a local connectivity issue. Could Cursor staff please inspect and repair this account’s local-exec host/provider mapping or routing index? Please don’t reset the cloud Grok Bot computer; that side works.
It shows two things at once: the helper on your Mac being restarted repeatedly (the SIGTERM lines), and its uploads being rejected while your cloud computer was briefly asleep (the http_417 lines). Both of those are on our side, and Grok Bot 0.30.0 includes a change that addresses the restart loop.
Could you check your version in Settings, update to 0.30.0 if you’re not on it yet, then fully quit and reopen the app and try a local command again? (also relevant to you @John_Richerson)
If it still fails on 0.30.0, please post the last ~20 lines of ~/.grokbot/local-exec-daemon.log from right after the relaunch, plus the rough time you tried, and we’ll take it from there.
@jacoprawinda There’s no manual attach or mapping repair step on our side. Registration happens automatically once the helper’s connection holds, so there’s nothing account-side for us to reset (and your cloud computer stays untouched).
Since you’re already on 0.30.0 and it still fails, we’d like to line your attempt up with what we see on our side. Right after a fresh relaunch, try one local command, note the exact time (with timezone), and paste the last ~20 lines of ~/.grokbot/local-exec-daemon.log from that attempt.