I feel disappointed after switching back to Cursor after using Codex for a while. There might be a sense of expectation gap, but the debugging experience has become far less reliable.
I asked the Grok model to troubleshoot a backend issue:
My existing system works fine historically. Recently, after object data changes, the API still returns stale data even though nodemon is watching file updates. This is the only problem I wanted to resolve.
However, the conversation went completely off track:
Instead of investigating cache, hot-reload or nodemon watch logic, the model suggested moving the target object to another file and rewriting a brand-new API as a workaround;
It generated extra scripts to kill processes occupying specific ports;
Without understanding my project logic or CSS specificity rules, it recommended commenting out the top property of class selectors, trying to force inline style top to take effect.
All these suggestions are irrelevant to the backend stale-data issue I raised. The model lost track of my core goal entirely.
Even after repeatedly restating my requirements, it failed to follow instructions accurately, kept diverging to unrelated changes, and only replied with generic apologies without actionable debugging steps.
It wastes lots of context and time when debugging complex existing projects. I hope the team can improve instruction following and prevent unnecessary scope creep during troubleshooting.
Hey, thanks for the detailed feedback, it’s genuinely helpful. I’ll pass it to the model quality team.
A couple practical things that usually help with scope creep during debugging:
Plan mode: before the agent starts changing anything, it first explores the codebase and drafts a plan you can edit. This helps keep the model focused and avoids unrelated changes: Plan Mode | Cursor Docs
Switch the model for the task. Grok isn’t always the best choice for debugging complex existing projects. For this, try Claude Sonnet, GPT, or Composer. The list and details are here: Models & Pricing | Cursor Docs
If auto-run is enabled, it’s worth turning it off for unfamiliar tasks and reviewing each proposed change before applying it, so the model doesn’t wander into extra scripts or CSS edits.
If you want us to look deeper into this specific case, send the Request ID from that chat right top corner menu > Copy Request ID and your Cursor version. Note that if Privacy Mode is enabled, the Request ID may not be available.
Thanks for your reply. I ran additional tests today: I opened a brand new chat to troubleshoot the issue again to avoid messy context from the previous conversation. Unfortunately, the model still suggested replacing nodemon entirely with a custom handwritten script.
I appreciate that the model is capable of building such solutions, but as I kept emphasizing: avoid reinventing the wheel by default.
The preferred debugging workflow should be:
First verify whether the existing tool is used correctly;
Try multiple solutions within the official documentation scope;
Only propose custom alternatives after confirming the existing approach cannot fix the problem.
My original code worked properly, this was just a recent sporadic issue. To put it casually, a Windows restart might even resolve it.
I hope my feedback based on real development workflows can help your team adjust the model behaviour.
I will grab the Request ID and send it to you tomorrow when I get back to work. Sorry that I can’t provide it now — my computer is at the office and I’m off work.
Thanks for clarifying the workflow you want. The idea of first checking that the existing tool is being used correctly, and only then looking at custom solutions makes total sense. I’ll pass that to the model quality team along with the initial feedback.
It’s also a useful observation that the pattern repeated in a plain chat. Please send the Request ID tomorrow when you’re back, plus your Cursor version, and we’ll take a closer look at the specific case.
While we wait, a couple things that can help keep the model scoped to the task:
Try adding a hard constraint directly in the prompt, like “do not replace nodemon or introduce custom scripts, only diagnose why the existing setup returns stale data”. Clear boundaries help reduce scope creep.
For debugging complex existing projects, Grok isn’t always the best choice. It’s worth trying Claude Sonnet, GPT, or Composer on the same task: Models & Pricing | Cursor Docs