Grok Bot 0.27.0 Windows – local host permanently “isn’t connected” after clean registration + new identity (server-side?)

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Grok Bot

Describe the Bug

The local machine shows “isn’t connected” from the agent side while chat works normally, and it persists through every documented client-side fix. Grok Bot 0.27.0, Windows 11 Pro (build 26200).

Original failure signature in ~/.grokbot/local-exec-daemon.log: a repeated desktop ownership lost, shutting down restart loop, with two local-exec-daemon instances alive concurrently, plus one [user-computer-provider] watch stream failed: ConnectError.

Remediations performed, each verified locally:

Full kill of all Grok processes → single relaunch → exactly one daemon, ownership held with no further ownership lost entries, connection.json re-sealed ~30s after start. Host still not visible to the agent.
Credential reset (daemon state files renamed aside, app relaunched) → a fresh registration identity was minted — new credential written, new connection sealed and accepted by the gateway. Host still not visible.

Network verified clean from the host: cursor.com 200, api2.cursor.sh 200, api.x.ai TLS connects; no proxy, VPN, or DNS filtering. Registration appears stuck server-side, keyed to the account — it survives a completely fresh machine identity. Requesting a staff-side reset. Pre-reset daemon state files are preserved locally if useful.

Steps to Reproduce

Open the Grok Bot desktop app on Windows; confirm chat works.
From the agent, ask: “Which computers do you currently see as available for local execution?” → no computer list; any spawn attempt returns “Your local machine isn’t connected right now (the Grok Bot desktop app must be open and online to run commands on it).”
Fully quit the app, kill all Grok processes, relaunch once, wait 60s → daemon registers cleanly (verified in local-exec-daemon.log / .json) → agent still reports not connected.
Quit again, rename local-exec-daemon-credential.json and local-exec-daemon-connection.json aside, relaunch → fresh credential and connection are minted and accepted → agent still reports not connected.

Expected Behavior

With the desktop app open, a single healthy daemon holding desktop ownership, and a gateway-accepted registration, the local machine should appear in the agent’s available-computers list and accept local execution — or, failing that, the agent side should surface why the host is excluded rather than a generic “isn’t connected.”

Operating System

Windows 10/11

Version Information

Grok Bot 0.27.0

Does this stop you from using Cursor

Mostly - I can’t connect to my local system, which is all I’m looking to use the product for at this time.

5

Hey, thanks for the detailed breakdown. Your diagnosis is correct. The local part daemon, registration, network looks fine, and this isn’t something you can fix on your side. The issue is on the service side, and it’s in a family of issues we’re already tracking.

What you can do right now is fully close Grok Bot, quit all its processes, then start it again once. After that, your local machine should show up as connected. If it’s still not visible, reply here and we’ll dig deeper.

I can’t share a timeline for a general fix yet, but I’ll update the thread if I hear anything.

8

It turns out it was the update process that kept nuking my local connection.
I re-installed Grok Bot, and it resolved the issue.

Quick note though - installed version 0.28, which worked. Version 0.29 was offered as an update, and once again killed my local connection yesterday.

I tried it again today, and for whatever reason, this time the update was successful in that I was still able to access my local system afterwards.

9

Great that reinstalling brought back the local connection, and that updating to 0.29 again kept it this time.

That’s a useful detail that the update process itself was what reset the local connection. This matches a family of issues we’re already tracking. I can’t share a timeline for a full fix yet, but I’ll post in the thread if there’s an update.

For next time, if the local machine disappears again after an update, first fully close Grok Bot and kill all its processes, then launch it once. If that doesn’t help, reinstalling like you did is a reliable way to restore the connection.

Let me know if you hit this again after an update and we’ll dig deeper.

10

Same symptom on Windows, and I think a variant worth separating from the
169821 case.

Grok Bot 0.30.0, Windows 11. Chat works, agent reports the PC is not attached,
session shows zero connected computers.

Colin described 169821 as the helper registering and then the connection
dropping right after. Mine does not appear to drop. Since a clean reinstall
the daemon log has exactly one line and no errors at all:

[sand-local-exec-daemon] started (pid 9628); serving local exec over the gateway

inflightCount: 0, generation: 0. The log mtime does not change when the agent
attempts local work — the request never arrives. So this looks registered but
unrouted rather than flapping. (Caveat: if the daemon only logs failures,
silent reconnects wouldn’t show.)

Before the reinstall I did have the flapping signature — poll failed:
DeadlineExceededError and repeated watch stream failed: ConnectError, with the
daemon respawning every ~30s. That stopped after reinstall; the “not attached”
state did not.

Both documented fixes performed, neither worked:

  1. Full process kill + single clean relaunch
  2. Full uninstall, deleted ~/.grokbot and %APPDATA%\Grok Bot, reboot, fresh
    install, fresh sign-in. New filesKeyId issued (f3dc8bbe60f708d6, previously
    fb02717e78182141), so the host re-registered locally.

Environment ruled out: TCP 443 to api.x.ai / grok.com / x.ai OK, no proxy, no
VPN, no firewall rules referencing grok, no duplicate daemon processes.

Two possibly useful details:

The break coincided with a staged auto-update (interrupted installer at
%LOCALAPPDATA%\Temp\sand-update-*), and autoUpdateWhenIdleOptIn is false so it
updates on launch — consistent with the update-resets-the-connection mechanism
noted above.

settings.json restores byte-identical after deletion, including
hasSeenOnboarding:true and an empty accountScopes {} next to a populated
activeAccountScope hash. Local state syncs down from the account, so deleting
local files isn’t a clean slate — a stale host binding account-side would
survive everything I did.

Given there’s no manual attach step, could you check whether this account’s
host registration is stuck server-side? Happy to provide account details.

11

Same issue on Windows. Chat works and the PC shows as connected, but local commands fail with “unavailable / isn’t connected.”

Cause is F-Secure. Excluding the Grok Bot folders did nothing. With F-Secure fully off and Grok Bot relaunched, local exec works. Turn F-Secure back on and it breaks again.

Please treat this as an F-Secure incompatibility and fix or document an allowlist for the local-exec channel.

12

Hey, thanks to both of you for the detailed reports.

@Jason_Chu: the F-Secure finding is really helpful. Since local exec starts working only when F-Secure is fully disabled, and folder excludes don’t help, it looks like F-Secure is intercepting the local-exec channel itself, not the files. So we can track this separately (it’s a different root cause than the original thread), please open a new thread just for F-Secure and include: your F-Secure version and which exact component is enabled (DeepGuard, firewall, browsing or DeepGuard protection). That’ll make it easier to confirm which module is blocking the connection and to suggest the right allowlist.

@brazofuerte: your case is different from the original one. The daemon registers and doesn’t flap, but the request never reaches it (registered but unrouted). That’s a separate case, and it’s best handled in its own thread. Please create a new one and include your account email (or say you’re ready to share details), and we’ll check your registration status for your account. Also noted your point that local state syncs from the account and deleting local files doesn’t give a clean start. That’s a useful detail for us to verify.

Both symptoms are in a group we’re tracking, but I can’t share an exact date for a general fix yet. Once we split this into separate threads, it’ll be easier to drive each one to closure. I’ll post an update if I have one.