Starting Aug 20, 2026, Grok Bot users began reporting failures mid-turn — Bots stopping partway through work already in progress. A Cursor community thread titled "Is Grok Bot Down Currently?" collected the reports. Cursor staff pointed people to Reset Grok Bot's Computer, under Settings > Updates, as the initial workaround while the underlying issue was investigated.
That is the whole confirmed record. We have no official incident duration, no affected-user count, and no published postmortem. What the incident is useful for is not its size but its shape: the fix was to reset a computer.
Why the workaround is the interesting part
Grok Bot's model is one named Bot, one shared cloud computer per user. Every Bot on your account works on that same machine, with the same logins. Isolation is per user, not per Bot. Individual features assume this: the Aug 18 update that grouped mobile notifications by Bot and used each Bot's icon exists precisely because several Bots run on the shared computer at once and you need to tell which one needs you.
So when staff say "reset the computer," they are describing the blast radius. There is one stateful thing underneath your whole Bot roster, and the supported remedy when it goes wrong is to throw it away and let it come back. That is a reasonable operational answer. It is also a statement about where state lives, and it is the same statement the security critique makes from the other direction.
The same architecture, read as a risk
A review published Aug 27 examining Grok Bot's cost and credential risk found that the one shared computer model is not a security boundary between a user's own Bots, that Auto-review of agent actions is best-effort rather than guaranteed, and that xAI's public documentation does not mention prompt injection as a risk. The community reading is blunter: a forum thread titled "Bots are not a security boundary" is described as the top community complaint in our source notes, and the vendor's own framing is that the shared computer is not one.
Read those two facts together. The shared computer is a single failure domain for reliability — reset it and every Bot's session goes with it — and a single trust domain for credentials, since a Bot that goes wrong is working inside the same logins as every other Bot you run. One property, two consequences. You do not get to fix one without addressing the other.
What a builder should take from it
Three things, none of them dramatic.
First, if you are handing a Bot work that must not be interrupted, assume the turn can die and the recovery is a computer reset. Design tasks so a resumed Bot can tell what it already did, and prefer routines that check state before acting over routines that assume they are continuing.
Second, credential blast radius is a design input, not a footnote. All Bots share the logins. If one Bot needs a payments credential and another scrapes untrusted web pages, those are on the same machine by design. The Stripe Link purchasing feature that shipped Aug 28 requires explicit per-spend approval and uses a single-use card, which is a real mitigation — but it is a mitigation at the money layer, not the machine layer.
Third, this is the gap the alternatives are aimed at. Per-Bot isolated VMs are a differentiator no hosted product had shipped as of the end of August. rakazo's pitch is Bots in Docker on your own hardware behind your firewall. That only matters if the shared-computer trade-off is real, and Aug 20 was the week it became legible to everyone rather than just to people reading the docs closely.