Grok Bot local-computer execution looks connected in Settings but is not actually usable for file I/O

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Grok Bot

Describe the Bug

Grok Bot local-computer execution looks connected in Settings but is not actually usable for file I/O.

Machine: MacBook-Air-M2.local
machineId (when listed): bffe1659-9853-43b9-b18c-461093663d3f
App: Grok Bot, 2026-08-28, ~9:07–9:25am PT

Settings → Computer: Current computer = MacBook-Air-M2.local (Save disabled). Execution on this computer = Always allow. Opening Computers shows the Mac listed. A Grok Bot deep link to settings id=local-execution jumps to General instead of Computer (wrong row). Full quit/reopen of Grok Bot did not fix it. The Mac itself stayed on the whole time.

Symptoms:

ListMachines is flaky: sometimes {connected: true} for that id, sometimes machines: , sometimes later Unknown machineId.

After reconnect/restart, first turn often: No registered machines were available when this turn started. A connected machine can be used on the next turn. even though ListMachines in that same turn already returned connected: true.

Shell to the Mac sometimes works for exactly one command (confirmed: ls of ~/Desktop/Idiot_Coding/Patent/Patent Images succeeded, 137 entries, mtime Aug 28 09:10 PT), then the next command fails with Your local machine isn’t connected right now (the Grok Bot desktop app must be open and online to run commands on it) or Your computer “MacBook-Air-M2.local” is unavailable — it looks disconnected. Reconnect it (or focus the computer you want commands to run on) and try again.

CopyFromBox (Grok Bot computer → Mac) never succeeded, including in the window where Shell to the same machineId had just succeeded. Same disconnected / unknown-machineId errors. Retrying to /Users/JakeSun/Desktop/ (no spaces) also failed.

Opening Settings → Computer while “connected” does not keep the session alive.

Not the issue: execution policy (already Always allow), computer name, agent prompt, or USPTO. Direct curl from the Mac to image-ppubs.uspto.gov was 403; that is separate. The bug is the Grok Bot ↔ this Mac local-exec/file-copy channel, not patent download.

Steps to Reproduce

Open Grok Bot on MacBook-Air-M2.local with the Mac left on.

Confirm Settings → Computer: Current computer = MacBook-Air-M2.local (Save disabled), Execution on this computer = Always allow, and that Computers lists the Mac.

Optionally open a Grok Bot deep link to settings id=local-execution and note that it jumps to General instead of Computer.

Fully quit and reopen Grok Bot if the machine already looks connected (this did not fix it).

Ask the agent to write any file into a folder on this Mac (for example /Users/JakeSun/Desktop/ or ~/Desktop/Idiot_Coding/Patent/Patent Images).

In the same turn, compare ListMachines, Shell, and CopyFromBox: ListMachines may return {connected: true} for bffe1659-9853-43b9-b18c-461093663d3f while the first turn still says no registered machines were available; Shell may succeed for one command then fail as disconnected; CopyFromBox fails even in the window where Shell just succeeded.

Observe ListMachines vs Shell vs CopyFromBox disagree, then the machine drops off the list (machines: or Unknown machineId).

Operating System

MacOS

Version Information

Grok Bot 0.29.0

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey, thanks for the detailed report, this is more than enough detail.

What you described matches an issue we’re tracking in the local computer channel. When a command or a file copy hits a timeout, the machine is temporarily removed from the agent’s machine list for about a minute. That explains the exact pattern you’re seeing: Settings shows connected, one Shell command works, the next one fails as disconnected, and CopyFromBox doesn’t work even right after a successful Shell.

A couple clarifications on what you noticed:

  • No registered machines were available when this turn started is expected. The set of available machines is fixed at the start of each turn, so if the machine reconnects mid turn, just send a new message and it’ll get picked up.
  • The deeplink in Settings that opens General instead of Computer is the same situation where the roster is temporarily empty, not a separate issue.

For now, the workaround is:

  • If a command fails as disconnected, don’t retry right away. Wait about a minute so the machine has time to show up again in the list.
  • If it still gets stuck after that, fully quit Grok Bot with Cmd+Q, then kill any stuck local-exec helper processes on the Mac by running pkill -f local-exec-daemon in Terminal, and reopen the app.

Some improvements for this flow are already coming in one of the next desktop app releases. You’re currently on 0.29.0. I can’t share an exact date yet, but I’ll reply in the thread when there’s an update. Let me know if the workaround helped.

7

Grok Bot said to put this here:

Grok Bot 0.30.0 on Mac (hattrs-MBA.local): copying a file to the registered local computer drops the machine. Tiny Shell still works. Check for Updates does not offer a newer build.

Local execution is ON. Computers shows the Mac connected. The local-exec helper is installed and running (Grok Bot.app … /local-exec-daemon/main.cjs).

Works: hostname returns hattrs-MBA.local. ListMachines often connected: true.

Fails: CopyFromBox of a ~64MB archive to /Users/hattr/GrokBot. Immediate error: computer unavailable / looks disconnected. Then ListMachines is empty (Unknown machineId). Not Auto-review (no card).

Same pattern as Dean Rie 29 Aug 2026, Grok Bot local-computer execution looks connected in Settings but is not actually usable for file I/O — a file copy timeout temporarily removes the machine from the agent list for about a minute. Settings can still look connected.

Helper log ~/.grokbot/local-exec-daemon.log (no secrets): repeated [user-computer-provider] poll failed: DeadlineExceededError (deadline_exceeded); ConnectError; SIGTERM; cli_unknown_command; daemon restart. Matches helper-poll / leftover-daemon threads (169821, 170121). 0.30.0 only fixed daemon exiting cleanly and never respawning; other paths still tracked.

Tried: Check for Updates (stuck 0.30.0); Cmd+Q; pkill -f local-exec-daemon; reopen; wait; one-shot copies only.

Not a Local execution toggle miss and not a missing helper. Still reproduces on 0.30.0. Need a desktop build that does not drop local-exec on file copy.

8

Grok Bot: browser/computer agents still blocked after Local execution is Always allow

Product: Grok Bot (desktop + mobile)
OS: macOS (machine: Mac-mini.local, connected)
Setting: Settings → General → Local execution = Always allow

What I’m trying to do
Have an agent drive its own computer/browser (open Chrome, use the desktop).

What happens
Every time the agent tries to start a browser or computer session, it fails immediately with:

“That action was not approved on the user’s computer, so nothing ran. Ask the user to approve it (or to set Settings → Bot → Execution on Local Computer to Always allow)”

No Allow card appears in the Mac chat that actually unlocks it. I already set Always allow. Toggling it and retrying from the Mac doesn’t help. Asking in chat / tapping Allow in a bot widget also doesn’t unlock it.

What still works

  • Agent’s own computer (shell, files) works
  • A non-browser background task on the agent computer works
  • I can open the agent’s desktop myself; Chrome and the desktop are fine. The agent just never gets permission to drive them.

Expected
With Local execution = Always allow, the agent should be able to drive its own computer/browser, or I should get a native Allow card on the Mac that actually grants it.

Actual
Browser/computer sessions never start. The block is before any window is controlled. This also doesn’t seem available to change from the mobile app.

Please advise if Always allow is supposed to cover the agent’s browser/computer, or if there’s a separate Allow I need to tap on the Mac.

9

@hattr yes, this is the same class of issue described earlier in this thread. Specifically, it is the case where a large CopyFromBox hits a timeout and the machine disappears from the agent list for about a minute, even though Settings shows connected. We’re tracking this, no ETA yet.

For now, a few workarounds that reduce how often it happens:

  • Split large copies into smaller chunks instead of one big archive. Large transfers in a single frame are what tend to hit the timeout.
  • If the machine drops, wait about a minute before retrying. Don’t retry immediately so it has time to show up in the list again.
  • If it gets stuck, Cmd+Q, then run pkill -f local-exec-daemon in Terminal, and reopen the app.

About Check for Updates on 0.30.0, the rollout is gradual, so a delay of a couple days is normal. I’ll post in the thread when there’s an update on improvements to this flow.

@Ishank_Choudhary what you’re describing is a separate issue from the drop or flap in this thread. In your case, the agent’s browser or computer sessions are being blocked with That action was not approved on the user’s computer, even though Local execution = Always allow and the approval card doesn’t show up. We’re tracking that separately.

To avoid mixing two different issues in one thread since that makes them harder to track, please start a new thread for your case. Also include a couple things that’ll help us investigate:

  • A Request ID from one of the failed attempts right top chat menu > Copy Request ID
  • Your Grok Bot version and which exact tool is failing browser session, computer session, or Task subagent

Send the link to the new thread here and I’ll take a look.

10

Hi, tbh, I just told grok bot to write feedback for me and where to put it to be helpful :slight_smile: I just did the logging in / copy paste, honestly didn’t read the thread too busy being adhd and bouncing on to the next thing thinking I had been helpful and being happy about that, lol.

11

No problem. The info was still useful, thanks. We’re tracking your case CopyFromBox with a large archive on Mac, where the machine disappears from the agent list for about a minute even though Settings shows connected. No ETA yet.

For now, the workaround is the same:

  • Split big copies into smaller parts instead of one large archive. Large transfers in a single frame usually hit a timeout.
  • If the machine drops, wait about a minute before trying again. Don’t retry immediately.
  • If it gets stuck, quit the app with Cmd+Q, then run pkill -f local-exec-daemon in Terminal, and reopen the app.

I’ll reply in this thread once we have an update on improvements to this flow.

12

No idea I have tried multiple ways to try to regive access to my computer. But Grok Bot just no longer can access my computer… But it writes this (so it can with some workaround be able to transfer file!):
"Shell can write into L:\dev\my_project. The transfer tool can’t. Staging the program in your home folder, then moving it with Shell.

Got it. Direct file-transfer only lands under your profile (C:\Users\Elrinth\...). Shell can read/write broader paths, including L:\dev\my_project.

The patched build is now in:

  • L:\dev\my_project\web\sotn.exe
  • L:\dev\my_project\build\sotn.exe

Both 1,048,592 bytes, updated just now, hashes match.
"

It was able just earlier to atleast write to one folder, but now it can’t write to any folder normally.

Something happened to Grok Bot.

I tried full reboot of my computer and also “Update Grok Bot’s Computer”. But neither made any difference.

13

Hey @Elrinth, thanks for the details.

The part where the machine “disappears” and the agent loses access is the same class of issue we’re tracking in this thread. When an operation times out, the machine drops out of the agent list for about a minute, even though Settings still shows “connected”. On Windows it looks the same.

Your note about direct file transfer only writing under the user profile path (C:\Users\Elrinth\...), while Shell can work with broader paths like L:\dev\my_project, is a separate observation. It’s better not to mix that with the Mac cases in this thread, otherwise it’s harder to track. Please start a separate thread for your Windows case and include:

  • your Grok Bot version
  • the Conversation ID from one of the failed attempts
  • which exact tool is failing transfer/CopyFromBox, Shell, or something else

Drop the link to the new thread here and we’ll take a look.

For now, the workaround is the same:

  • split large copies into smaller parts, not one big archive. Large transfers in a single frame hit the timeout more often.
  • if the machine dropped, don’t retry right away. wait about a minute for it to show up in the list again.
  • if it’s stuck, fully close Grok Bot, end any stuck local-exec-daemon processes in Task Manager, then reopen the app.

About “Update Grok Bot’s Computer” on Windows: if access still didn’t come back after that, the version and Conversation ID in the new thread will help us dig in. I’ll post back once we have an update on improvements to this flow.