Grok Bot Computers / local-exec still flapping after update

Support Bug Reports
, ,
1

Follow-up to Grok Bot Computers / local-exec keeps dropping while Mac mini stays on.

Summary

Local-exec registration for both of my registered Macs flaps between connected and empty even though:

  • both machines stay powered on
  • Settings → Computer lists both with “Execution on this computer” = Always allow
  • chat remains usable when the machines disappear from agents’ live machine lists

This matches the known helper-process bug Colin described in that thread (cloud environment going idle → Mac helper wrongly concludes the desktop app is gone and shuts itself down). A fix was said to ship in a release after 0.29.0. I updated Grok Bot on Aarons-MBP-2 to the latest available build today and the flap is still happening.

What agents see

  • ListMachines returns {"machines": []} for long stretches.
  • Machine-targeted Shell fails with either:
    • Command failed to spawn: No registered machines were available when this turn started. A connected machine can be used on the next turn.
    • or, earlier, a stale machineId enum rejection while the other Mac was still listed: Invalid enum value. Expected '<other-machine-id>', received '<this-machine-id>'
  • When the link is briefly up, both machines appear as connected: true, then go empty again within tens of seconds to a few minutes.

What the app shows at the same time

Settings → Computer lists:

  • Aarons-Work-Mac.local — Always allow (current computer)
  • Aarons-MBP-2 — Always allow

So the desktop app still knows about the machines while agents’ live registration query returns empty.

Timeline (all times ET, 2026-09-03)

  • ~10:39am — agents successfully running commands on both Macs
  • ~11:31am — still working on Aarons-MBP-2
  • ~11:46–11:49am — both machines go empty; every subsequent ListMachines call returns []
  • Grok Bot restart on the work Mac: no change
  • Sign out / sign back in on the work Mac: no change
  • Remoting into Aarons-MBP-2 via Screen Sharing (waking the GUI session): machines briefly reappeared and another agent could use MBP-2 again
  • Updated Grok Bot on Aarons-MBP-2 to latest
  • ~12:33pm — both machines showed connected again
  • ~30 seconds later — ListMachines empty again

Things that did / did not help

Did not fix it:

  • Restarting Grok Bot
  • Signing out and back in
  • Waiting and retrying many times
  • Updating Grok Bot on Aarons-MBP-2 to the latest available build (still flaps after update)

Temporarily restored the link:

  • Opening / focusing Grok Bot on the Mac, or waking the session via Screen Sharing

Machines are healthy

  • Work Mac is the machine I’m chatting from.
  • Aarons-MBP-2 answers over Tailscale at ~5ms with 0% packet loss; SSH and VNC accept connections when the Mac is awake.

Possibly related symptoms in the same window

  • An agent-to-agent message was delivered to the recipient, but the recipient’s reply never arrived in the sender’s context.
  • A couple of assistant replies did not visibly land in chat.

Ask

Is the post-0.29.0 fix in the build I just got, or still rolling out? If it’s supposed to be in latest, this looks like a regression or an incomplete fix — happy to provide build numbers / logs if useful.

2

Hi there!

We detected that this may be a bug report, so we’ve moved your post to the Bug Reports category.

To help us investigate and fix this faster, could you edit your original post to include the details from the template below?

Bug Report Template - Click to expand

Where does the bug appear (feature/product)?

  • Editor, Tab & Chat (autocomplete, Composer, in-editor agent)
  • Terminal & commands
  • Models, pricing & API keys (availability, Auto/Max, BYOK/Bedrock)
  • MCP & tools
  • Cloud Agents & Automations (cursor.com/agents, scheduled/event)
  • BugBot & Code Review
  • Cursor CLI
  • Cursor Mobile
  • Remote (SSH / Dev Containers / WSL)
  • Account, billing & login
  • Something else…

Describe the Bug
A clear and concise description of what the bug is.

Steps to Reproduce
How can you reproduce this bug? We have a much better chance at fixing issues if we can reproduce them!

  1. …
  2. …
  3. …

Expected Behavior
What is meant to happen here that isn’t working correctly?

Screenshots / Screen Recordings
If applicable, attach images or videos (.jpg, .png, .gif, .mp4, .mov)

Operating System

  • Windows 10/11
  • MacOS
  • Linux

Version Information

  • For Cursor IDE: Menu → About Cursor → Copy
  • For Cursor CLI: Run agent about in your terminal
IDE:
Version: 2.xx.x
VSCode Version: 1.105.1
Commit: ......

CLI:
CLI Version 2026.01.17-d239e66

For AI issues: which model did you use?
Model name (e.g., Sonnet 4, Tab…)

For AI issues: add Request ID with privacy disabled
Request ID: f9a7046a-279b-47e5-ab48-6e8dc12daba1
For Background Agent issues, also post the ID: bc-…

Additional Information
Add any other context about the problem here.

Does this stop you from using Cursor?

  • Yes - Cursor is unusable
  • Sometimes - I can sometimes use Cursor
  • No - Cursor works, but with this issue

The more details you provide, the easier it is for us to reproduce and fix the issue. Thanks!

6

Hey, thanks for the detailed report with the timeline. It matches exactly what we saw on our side.

Two separate things overlapped here.

First, to answer your direct question: the helper process fix from the previous thread is indeed out. It’s in 0.30.0 and newer, so it should be on both of your Macs. What happened today is not a regression of that fix.

What hit today starting around 11:46am ET is a separate issue on our side. Because of a change in a recent release, your account briefly looked like it was in Legacy Privacy Mode, and requests from cloud computer were getting rejected. That’s why the computer list came back empty, even though in Settings both Macs were set to Always allow. This also explains a couple assistant responses that didn’t make it into the chat, and the lost agent-to-agent reply.

We shipped a server-side fix and it fully rolled out around 12:40pm ET. From that point, cloud computer has been working normally again with both Macs, so you don’t need to reinstall anything or reset anything on your side. Restarting the app or signing out and back in during that window wouldn’t have helped either. Sorry for the extra churn.

One more thing: even before today’s incident, the Mac that was still on 0.30.0 would sometimes drop out of the list and then come back on its own in about a minute. That’s most likely the Invalid enum value you saw while the other Mac was still listed. Now that both are on 0.36.0, this should happen much less often. If a Mac still disappears from ListMachines for more than a couple of minutes, send the time (ET is fine) and which Mac it was, and we’ll take a look.

8

Residual report on Grok Bot 0.43.0 (after app update + reboot), same family as this thread and the “Mac stays on / local-exec drops” reports.

Hardware (no hostname): MacBook Pro, Apple M2 Pro, 32 GB RAM

OS: macOS 26.6.2 (build 25G83)

Grok Bot: 0.43.0

While actively using the Mac (awake, chatting back-and-forth — no sleep gap), agents still hit brief “temporarily unreachable” / local-exec drops. One confirmed today ~1:51pm America/New_York: recovered on its own in ~1–2 minutes with no quit/relaunch. Chat stayed up the whole time.

Staff asked here to report if a Mac stays missing more than a couple of minutes; ours are usually the short self-heal case, but it still interrupts mid-job on current builds while the machine is clearly in active use. Happy to share redacted local-exec-daemon.log snippets if useful.

9

Hey, thanks for the detailed residual report. One important clarification: what we fixed earlier in this thread was a separate server-side event on an old build, and it’s already resolved. Your case is different: 0.43.0, the machine was actively in use with no sleep or idle gap, and a short self-heal in 1 to 2 minutes. That’s a separate issue, and this shouldn’t happen during active work.

To investigate, the logs you offered would be really helpful:

  1. Redacted snippets from ~/.grokbot/local-exec-daemon.log around that time about 1:51pm America/New_York. We’re interested in the window from about 2 minutes before the drop through when everything recovered.
  2. The Request ID from the interrupted turn, if you can grab it right corner of the chat menu > Copy Request ID.
  3. Which track you’re on: Stable or Early Access.

Also, so this doesn’t get mixed up with the already-closed incident in this thread, it’d be better to start a separate thread for this case and attach the logs there. That makes it easier to track. Let me know if you’d rather keep it here, and we can work in this thread.