Since around Nov 8, my Grok Bot has stopped performing any development work directly inside its own cloud computer. It will not:
edit/modify code in the repo on its VM
run git commits or any repo operations
do any development task locally on its computer
Instead, it insists on launching a Cursor Cloud Agent to do the work. If I deny/block the use of Cursor Cloud, the bot simply says it “cannot work” and provides no explanation or reason at all.
This is a major regression for me: I’m a legacy Cursor Ultra subscriber who previously used Grok Bot to code directly in its cloud computer without consuming Cursor quota. The forced Cloud Agent handoff wastes tokens/time and loses context in the handoff.
Please clarify:
Is this an intentional change or a bug?
Do personal accounts have any opt-out / setting to restore “Grok Bot coding directly in its cloud computer”?
Why does it refuse with no reason when Cursor Cloud is disallowed?
Hoping for an official response. Thanks.
Steps to Reproduce
Open a code repository inside Grok Bot’s cloud computer (ensure the repo is accessible on its VM).
Ask Grok Bot to perform a development task, e.g. “edit this function in file X”, “commit the current changes to git”, or “create a new function in the repo”.
Observe: instead of executing directly in its cloud computer’s terminal/editor, the bot tries to launch a Cursor Cloud Agent to do the work.
When you deny/block the use of Cursor Cloud Agent, the bot replies “I cannot work / I can’t proceed” with no explanation or reason given.
Expected Behavior
Grok Bot should be able to perform development operations directly inside its own cloud computer (VM) — editing code, running git commits, operating the repo, etc. — without being forced to route through a Cursor Cloud Agent, as it did before ~Nov 8. And when it genuinely cannot perform a task, it should state a clear reason rather than refusing without explanation.
Hey @matrees! Handing repo work to a Cursor cloud agent is Grok Bot’s intended default right now, but refusing outright when you explicitly ask it to work on its own computer (with no reason) isn’t. Others have hit this since around Nov 6 and it’s an issue we’re tracking.
As a stopgap, ask for the local work explicitly in the same message with a reason, e.g. “Make this change directly in the repo on your own computer, since it depends on files only there, and don’t use a cloud agent.” It doesn’t land reliably for everyone yet. There’s no opt-out setting for the handoff today, though it’s a request we’ve seen from others.
For anyone else who lands here with the same symptom (Grok Bot refusing to do dev work on its own computer and silently forcing everything through a Cursor Cloud Agent, with no reason given): here’s the resolution and a reusable pattern.
What was happening:
As Mohit explained, handing repo work to a Cursor Cloud Agent is currently Grok Bot’s intended default — but the bot outright refusing when you explicitly ask it to work on its own computer, with no reason, is a bug they’ve been tracking since around Nov 6. In my case I’d been asking the bot to develop while also instructing it not to use Cursor, which fed straight into that buggy refusal path.
The fix that worked (verbatim from the team’s stopgap):
Ask for the local work explicitly, in the same message, with a reason, and tell it not to use a cloud agent, e.g.:
“Make this change directly in the repo on your own computer, since it depends on files only there, and don’t use a cloud agent.”
Two things that mattered for me:
The instruction has to be in the same message as the task (not just a standing rule buried somewhere).
You must give a reason (“since it depends on files only there”). Without the reason it didn’t stick.
Caveats (straight from the team):
This stopgap “doesn’t land reliably for everyone yet.”
There’s no opt-out setting for the cloud-agent handoff today, though they’ve seen that request from others.
So if you’re hitting this: don’t assume you misconfigured something — it’s a known issue. Try the explicit-with-reason prompt above, and hopefully a proper fix or an opt-out follows. Thanks again to the team for tracking it and merging into the main thread.
