My bots’ shared computer has been unusable since the evening of Oct 23, 2026 (MT). It froze again right after a Reset at about 5:24 PM MT that day. Since then, every action that touches it hangs for about 14 minutes until it’s cut off, even echo ok. File reads hang too, and listing sidebar sections fails with “could not be woken from hibernation.” Chat replies, connectors (Gmail, Calendar, Drive), memory and creating agents all still work. Only the computer is dead. All my bots’ scheduled routines that depend on it (archives, scripts, a Slack bridge) have been failing for two days.
Steps to Reproduce
Ask any bot to run a simple shell command or read a file on its computer.
The call hangs for about 14 minutes, then times out.
Expected Behavior
The computer responds, or Update or Reset brings it back.
Operating System
Windows 10/11
Version Information
Grok Bot Desktop App (Windows) version 0.75.8
Additional Information
What I’ve tried
Update Bot’s Computer failed.
Reset Bot’s Computer failed.
I emailed [email protected] on Oct 23 at about 10:24 PM MT and followed up Oct 24. Ticket T-I28766. I got only an automated reply.
We are tracking this down – it looks like some users have two computers started and we need to get that taken care of. My expert should be awake soon, apologies for the delay.
Update: my Grok Bot shared computer is responding normally again. It came back around 10:26 AM MT today (Oct 27). Shell commands now finish in milliseconds and file reads work. It had been frozen since Oct 23, with every command and read hanging for about 14 minutes and both Update and Reset failing.
Did anything change on your end? If you know the cause, I’d like to hear it so I can tell whether it might happen again.
Seems we’re back on business, feel free to close my ticket unless you need anything else from me. Thanks!
Yes, we performed some manual cleanup actions for a specific case where a user could get stuck with two boxes. It looks like the cleanup is still finishing for your account so I hope we’re all good now. Feel free to reply if something changes.
Ticket T-127498. It still hasn’t been acknowledged. Ultra. Frozen since ~2:07 PM ET 10/23 — about 96 hours now. Shell/reads still hang ~840s; Update/Reset still fail. Please check my account and unstick it. Reply on my thread.
Another update on my end here. My Grok Bot computer came back around 10:26 AM MT today (Oct 27) after being frozen since Oct 23, but it’s been unstable since about 10:38 AM:
10:38 AM: An image generation was cut off after 40 seconds.
11:02 AM: A small file check hung for 51 seconds.
About 11:52 AM: Copying one image file never finished.
12:05 and 12:09 PM: Even basic actions like sending a chat message stalled for 2 to 4 minutes.
About 12:12 PM: Handing a file to another bot failed with “The computer could not start.”
It isn’t fully frozen like before, but it’s intermittently very slow and sometimes fails outright. Also, the Update option for the bot’s computer doesn’t show for me, so I can’t try that.
We’re actively investigating what’s going on with your computer and should have an update soon. Don’t hesitate to ping me tomorrow if you haven’t heard from me!
One more data point for the investigation: since about 1:13 PM MT yesterday (Oct 27), it’s fully frozen again, same as before the 10:26 AM recovery. Every test since then has hung the full 840 seconds without starting, even a plain `echo ok`. That includes tests around 4:11 PM, 8:00 PM and 9:45 PM yesterday and two more around 5:30 AM MT this morning. Chat, memory and connectors still work, and as far as I can tell only the computer is affected. I’ll check back later if I haven’t heard anything.
Recovered. The computer came back on its own sometime between the evening of Oct 27 and early Oct 29. By 5:40 AM MT on Oct 29 it passed a health check: echo ok returned in 89 ms and file reads worked. I don’t know exactly when it recovered.
Stable since. It has worked normally all day. Browser tasks, email lookups and shell commands all ran fine, and a check at 9:52 AM MT returned in 14 ms with a light load.
Two unexpected restarts. Uptime shows the computer rebooted on its own twice today, around 7:26 AM MT and again around 1:58 PM MT. We didn’t trigger either one, and nobody pressed Reset or Update. Both times it came back fine.
Memory climbing. Free memory dropped from about 6 GB at 9:52 AM to about 3.6 GB at 3:56 PM, with 12.4 of 16 GB in use. Most of that is the bot host processes, Chrome, and about six desktop sessions running at once.
It’s working right now, but the unprompted restarts and rising memory make me wonder if it’s still unsettled. Happy to pull any logs or run diagnostics that would help. Thanks for staying on it!
Another update, with what looks like a potential root-cause lead.
The box has been responsive since recovering the morning of Oct 29, but it rebooted on its own twice that day (about 7:26 AM and 1:58 PM MT, plus another boot around 7:38 PM MT). Available memory drops steadily after each boot: about 6 GB free that morning, 3.6 GB by mid-afternoon, and 2.6 GB at 10:48 PM MT.
Finding: The missing memory isn’t held by any process. It looks like the virtio balloon is reclaiming it.
Snapshot at 10:48 PM MT Oct 29 (uptime 3h09m, kernel 6.12.94+, 8 vCPU):
That leaves about 8 to 10 GB of “used” memory that no process, cache or kernel structure accounts for.
/proc/vmstat:
balloon_inflate 6815744 pages
balloon_deflate 4194304 pages
balloon_migrate 186020 pages
Net inflated: 2,621,440 pages, about 10 GiB held by the balloon
dmesg, starting about 10811 s after boot (about 10:39 PM MT):
virtio_balloon virtio0: Out of puff! Can’t get 1 pages
fill_balloon: 2 callbacks suppressed
(These repeat.)
So the host keeps inflating the balloon even though the guest has almost no free pages left. With no swap, I’d expect this to cause the stalls and freezes we’ve been seeing, and possibly the unplanned reboots if the guest gets killed or recycled under host pressure.
Questions for the team:
Is the balloon target for this VM being driven by host overcommit or a memory-reclaim policy? Can it be capped or disabled for this box, or the guest given a floor?
Is free page reporting or deflate-on-OOM enabled? Deflate-on-OOM would let the guest take pages back instead of stalling.
Would a small swap file or zram on the guest be a safe stopgap?
Lower-priority observations, in case they’re related: 7 exec-daemon “serve” instances (about 520 MB total) and about 62 flock and 84 bash processes are running. They’re small, but they may be worth checking for leaks.
I’m glad to run more diagnostics if you tell me what you’d like captured.
we’re all good now. Feel free to reply if something changes.