I’ve been a Grok Bot user (legacy Cursor Ultra) who developed directly inside its own cloud computer. Until tonight (Nov 8, 2026), I would hand a coding task to my bot, it would edit files, run tests, and return a finished result — all in its persistent cloud VM, no Cursor involved, no extra quota burned. It worked well.
Tonight, without any announcement, that stopped. My bot now refuses to touch the code itself and insists: “I can only do repository development through Cursor’s cloud.” So the flow became:
me → Grok Bot → (handoff) → Cursor Cloud Agent → (handoff) → Grok Bot → me
Even a one-line change now has to bounce through this chain. And the damage is real:
-
Wasted compute & tokens. Every tiny edit spawns a separate Cloud Agent run. Work that used to take one focused session in the VM now multiplies into relayed agent runs.
-
Wasted time. The handoff round-trips stack latency on top of latency. A simple fix that returned in minutes now takes far longer.
-
Context loss and distortion — the worst part. Per SpaceXSI’s own architecture docs, the bot “is not writing that code itself; it sends the prompt a person would have written to the coding harness inside Cursor.” So the rich context from my conversation with the bot — the constraints, the background, the exact intent — is NOT carried into the Cloud Agent. The agent gets a stripped prompt and produces error-riddled, off-target changes. I end up fixing what the bot “fixed.”
-
Quality regression. Simple modifications now come back broken because the agent never had the full picture. This is a clear step backward from direct in-VM editing.
This is not an isolated glitch. It’s the same playbook as the other silent changes this month:
-
Nov 1: weekly usage caps slashed with no warning (Musk: “cost… unsustainably high relative to revenue”).
-
Nov 6: Grok Bot started forcing the X connector and refusing browser posting (forum thread #177702), with users reporting the same “refuses direct execution” pattern across Slack, WhatsApp, Meta Ads, GoHighLevel.
-
Nov 8 (tonight): coding in the VM is now blocked and forced through Cursor Cloud Agent.
The common thread: Grok Bot is being silently rerouted so that any task with a “managed” path (connector / Cloud Agent) is no longer allowed to run directly — even when the direct path worked better. No changelog, no announcement, no “here’s what changed and why.”
I’m not opposed to Cursor Cloud Agent existing as an option. But making it the only path — while stripping the context that made the bot useful, and quietly, after users built workflows around direct execution — is a garbage silent change that disrespects users and degrades the product. It wastes compute, wastes tokens, wastes time, and drives the experience backward.
My asks:
-
Publish what changed and when. A changelog entry is the bare minimum.
-
Restore in-VM direct development, or at minimum let users opt out of the forced Cloud Agent handoff.
-
If context can’t survive the handoff, fix the handoff — don’t force a broken workflow on everyone.
Stop shipping regressions in the dark.
2) REPLY (post under the Nov 6 thread #177702)
+1, and the same pattern just hit coding tonight (Nov 8). My Grok Bot used to develop directly inside its own cloud computer with no Cursor involved. Tonight it suddenly refused and now forces every code change through Cursor Cloud Agent. Same mechanics you describe: the bot won’t do the task directly, insists on the “managed” path, and treats the VM as off-limits.
The damage is exactly what you’d expect from a forced handoff: wasted tokens/compute (every small edit spawns a relayed agent run), wasted time (round-trip latency), and — worst — context loss. Per SpaceXSI’s own docs the bot “sends the prompt a person would have written to the coding harness,” so the conversation context never reaches the agent. Simple changes come back error-riddled. It’s a clear step backward.
This looks like a staged rollout of “force the connector / Cloud Agent, refuse direct execution”: X/browser on Nov 6, coding on Nov 8. Please add coding to the list and ask for a real changelog + an opt-out.
3) ONE-LINER (quick reply to other complainers)
Same silent-change playbook here — forced reroute through the “managed” path, direct execution killed, context lost on handoff, zero announcement. Add coding to the list; we need a real changelog and an opt-out.