I genuinely dont understand whats going on with Cursor since the last update. It crashes every 15 minutes. It’s on its fourth attempt to refactor code in my project. On the first two attempts, it just made a whole bunch of nearly empty modules simply referencing the old code. The third attempt crashed mid way and deleted code. Its now in the fourth attempt and again code got deleted. It cannot find it in git commited versions because it chose to ignore the plan that specifically instructed it to work in small steps and git commit after I verify
… Its been at it for 15 hours and has used 1/3th of my usage … whaaaat.
Hi there!
We detected that this may be a bug report, so we’ve moved your post to the Bug Reports category.
To help us investigate and fix this faster, could you edit your original post to include the details from the template below?
Bug Report Template - Click to expand
Where does the bug appear (feature/product)?
- Editor, Tab & Chat (autocomplete, Composer, in-editor agent)
- Terminal & commands
- Models, pricing & API keys (availability, Auto/Max, BYOK/Bedrock)
- MCP & tools
- Cloud Agents & Automations (cursor.com/agents, scheduled/event)
- BugBot & Code Review
- Cursor CLI
- Cursor Mobile
- Remote (SSH / Dev Containers / WSL)
- Account, billing & login
- Something else…
Describe the Bug
A clear and concise description of what the bug is.
Steps to Reproduce
How can you reproduce this bug? We have a much better chance at fixing issues if we can reproduce them!
- …
- …
- …
Expected Behavior
What is meant to happen here that isn’t working correctly?
Screenshots / Screen Recordings
If applicable, attach images or videos (.jpg, .png, .gif, .mp4, .mov)
Operating System
- Windows 10/11
- MacOS
- Linux
Version Information
- For Cursor IDE: Menu → About Cursor → Copy
- For Cursor CLI: Run
agent aboutin your terminal
IDE:
Version: 2.xx.x
VSCode Version: 1.105.1
Commit: ......
CLI:
CLI Version 2026.01.17-d239e66
For AI issues: which model did you use?
Model name (e.g., Sonnet 4, Tab…)
For AI issues: add Request ID with privacy disabled
Request ID: f9a7046a-279b-47e5-ab48-6e8dc12daba1
For Background Agent issues, also post the ID: bc-…
Additional Information
Add any other context about the problem here.
Does this stop you from using Cursor?
- Yes - Cursor is unusable
- Sometimes - I can sometimes use Cursor
- No - Cursor works, but with this issue
The more details you provide, the easier it is for us to reproduce and fix the issue. Thanks!
I had no trouble running Cursor smoothly up untill a few days ago. Now its a nightmare to work with.
Im on Windows Version: 3.17.8 (user setup)
VS Code Extension API: 1.128.0
Commit: 2fdd31c9f33f7fbe501f2d57772dc5bf64b63620
Date: 2026-08-20T02:18:12.724Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.291
OS: Windows_NT x64 10.0.19045
Hey, thanks for the detailed report, and sorry that happened with the lost code. That really hurts.
First, recovery, since that’s the most urgent. Even if the agent didn’t commit to git, Cursor saves checkpoints for each chat message. Hover an earlier message in that chat and click Restore checkpoint. That will roll your files back to how they were at that point. Another option is IDE Local History: Cmd/Ctrl+Shift+P > Local History. Check both, there’s a good chance you can recover what got deleted.
Now, why things went off the rails. One continuous ~15-hour run in a single chat builds up a lot of state (history plus checkpoints), and that hits two areas at once: memory usage grows (that’s why you crash every ~15 minutes, after restart it restores the same heavy state and crashes again) and model output quality gets worse (empty modules, ignoring the plan). What helps a lot in practice:
- Start a new chat for each task, not one 15-hour marathon
- Keep steps small and commit to git yourself after you verify results. Don’t rely on the model for this. If the plan instruction gets ignored, a manual commit is your safety net
- For unfamiliar or large refactors, use Plan mode and review destructive changes before you confirm, instead of auto-running everything
About usage. A long continuous Auto run with 100+ requests per hour really does burn a lot, so 1/3 of your cycle over 15 hours is expected at that volume, not a billing error. Splitting work into smaller task-focused chats will help keep usage under control.
About the crashes themselves, we’re tracking this in long agent sessions. To dig into your case, can you share:
- When it crashes, does the whole app close, or do you get a dialog like window terminated unexpectedly, and what code does it show
- The Request ID from the affected chat with Privacy Mode off: chat menu top-right > Copy Request ID
With those details I can look deeper. Let me know if you were able to recover the code via checkpoints.
Hi Dean,
Thank you for getting back to me. I did start a new chat and using the manual backup I made (whole project folder copy) before the refactor, Cursor was able to complete the refactor.
I will be sure to start fresh new chats per completed task from now on.
The model went already off the rails before the 15 hour marathon, pretty sure for the same reason, the very long chat and so context degradation.
When it crashed, it showed the option of restoring the session, which it did and then continued with the ‘bad session’.
I cant find the restore checkpoint button you mentioned. I see copy message and fork.
Did you reduce a little bit of my usage, it went from 46% to 35% just now.
Thank you, all the best,
Wout
Great that you were able to restore from a backup and the refactor made it to the finish line. And yep, short chats per task are the most reliable approach. It really helps with both stability and answer quality.
About the Restore checkpoint button, you’re right. The control sometimes doesn’t render on earlier messages in long chats or chats you reopened. It’s a known issue we’re tracking. For now, these workarounds help:
- Slowly scroll up so the older turns fully load, wait a couple seconds, then hover the bottom-right corner of the user message, not the agent reply. The control usually shows up after it finishes loading.
- If it still doesn’t show, send a short new message in the same chat. That often brings the button back on earlier prompts.
- As an independent rollback option at the file level:
Ctrl+Shift+Pthen Local History: Find Entry to Restore.
About usage, I didn’t change anything manually. The percentage can get recalculated, but for details on your specific account it’s best to email the team at [email protected]. They can see the breakdown for your account.
We’re aware of crashes in long sessions and we’re tracking them. If it happens again, send what you see when it crashes, like whether the whole app closes or you get a dialog like window terminated unexpectedly and the code. Also send the Request ID from the affected chat with Privacy Mode turned off menu at the top right of the chat > Copy Request ID. With that, I can dig in deeper.
ok thank you Dean. And it’s funny you refer to hi@cursor as ‘they’ cause all I get from that email address is ai assistant responses 
Glad the refactor finally made it to the finish line and you were able to restore the code from a backup. Short, task-focused chats are the most reliable approach, so this should greatly reduce the chance of it happening again.
About [email protected], there’s a real team behind that address. The first reply is sometimes automated, but if the situation needs it, a person will jump in. If you still have questions about usage, write them again and ask for a human to take a look. They’ll break down the usage for your account.
If the crashes come back in long sessions, send what you see at the moment it happens, like whether the whole app closes or you get a dialog like window terminated unexpectedly and what code it shows. Also send the Request ID from the affected chat with Privacy Mode turned off. With that, I can dig deeper. For now, good luck with the project.
I did ask for a human to have a look and the AI assistant reply was , yes you’ve already reached support through this email haha
Since using per task fresh new chats, things are running much more smoothly. Thanks again
I have to continue this thread… Unfortunately.
Turns out the refactor was again a smoke and mirror show. No actual refactoring was done, yet again. So I upgraded to Pro+, decided to use Claude. Had it inspect the part of the project I wanted rewritten (front end). It correctly analyzed the huge mess, overengineered bug-ridden code and proposed a plan to rewrite it cleanly. It then quickly used 20% of my other model usage. I paused it and asked it to work in chunks, so each chunk would produce workable code, albeit less ported/feature rich. It kept ignoring the plan rules to stop for verification. I had it make separate plans so I could verify. It then did all plans in one go claiming I had prompted it to not stop between steps even though I explicitely instructed it to wait. It then said that the standard extra prompt that was injected, instructed it to not wait inbetween steps. After all this, 95% of my other model usage was used up and the last thing it could report to me before I had to switch models was that it didnt actually do any of the steps it was supposed to do.
I then used Grok to inspect and make a plan to see how far I got, it made a plan and then started not continuing the rewrite but patch/bug fixing which made everything even worse. Its advice now is to revert back to this morning’s git commit and to simly stop trying to rewrite this code…
wow…
Hey Wout, sorry this attempt also went sideways, and thanks for not dropping the details.
First, the important part. The model wasn’t lying about that extra instruction. When you press Build on a plan, Cursor sends the agent the entire plan with instructions to run through all to-dos without stopping. That’s the whole point of Build. So any text inside the plan like stop between steps so I can review gets overridden by that behavior. I get why it looked like the agent was ignoring you on purpose, but it’s really a conflict with how Build works.
If you want a review-as-you-go workflow, don’t use Build, do it manually:
- Keep the plan as a reference file, but in a fresh chat ask for only one piece: do only step 1, then stop and wait for me.
- Check the result and make the git commit yourself before the next piece, ideally in a new chat.
- Use Claude or Opus for planning and review, and hand the mechanical steps to Auto or Composer. Opus is the most expensive model in the lineup, so a big rewrite on it can burn through the other-models allowance fast. On our side the usage looks clean, those were real requests. If you want a breakdown for your specific account, email [email protected] and they can show you the details.
About rules. Rule files are instructions the model reads, not hard blocks, so deep in a long chat the model can drift from them. Also, they’re loading correctly for you. In the screenshots the agent lists them out, so it’s a following issue, not a reading issue. Short chats and small, focused requests are the most reliable way to keep it on track, like you saw earlier in this thread.
And if your morning git commit is clean, rolling back to it and redoing the rewrite in small chunks one by one is honestly the fastest path from here.
Hey Dean.
thats the thing, I created separate plans ! And it did all of them in one go. Also the rules are not followed from the start, in a fresh chat.
What I ended up doing is instruct Cursor to look at my mornnig backup, explicitely tellng it to make a feature list and then build from scratch, completly ignoring the structure of the reference. This worked well but I now have to migrate the whole css and layout. In this process, it again contiously ignores my rules. What Im doing and what seems to be working is to copy paste my rule after every prompt. And after every 2 edits or so, ask if it did any inline hacks, which it always did, and then to revert those and write root cause fixes/ shared css helper files. Its a looot of hand holding..
@WoutTengrootenhuysen I get that this much manual control is exhausting, so let’s cover both points.
On separate plans: even if the plans are separate, clicking Build on each one will run that plan all the way through with no pauses between steps. That’s how Build is designed, it goes through all to-dos without stopping. So text inside the plan like “wait for verification” won’t work. If you want checks along the way, it’s better not to use Build at all. Keep the plan as a reference file, and in a fresh chat ask for only one chunk like “do only step 1 and stop”. Then you review, commit yourself, and request the next chunk in a new chat.
On rules from the start: from the screenshots it looks like the rules do load and the agent lists them, so they’re being read correctly. The issue is following them. Rule files are instructions, not hard blocks, so the model can still drift. Your approach of re-pasting the rule and asking about inline hacks every couple of edits really does work, it’s just a lot of manual work.
To automate some of that, take a look at Hooks: Hooks | Cursor Docs. The afterFileEdit hook runs your script after every edit and can check or flag it, like running a linter or scanning for specific anti-patterns. That’s more reliable than hoping the model remembers the rule, and it reduces the hand-holding.
On Build vs “stop for verification”, fair point. There isn’t a dedicated affordance for pauses between plan sections right now.
And yeah, if your morning git commit is clean, rolling back to it and redoing things in small one-step chunks is usually the fastest path. Let me know how the CSS migration goes.
Hey Dean,
I dont think you understand what I wrote. I made separate plans. Distinct separate files. I pressed build on 1 and it built all of them in one go without stopping.
Ill have a look at the Hooks, didnt know about that, thank you. Its a waste of tokens and time to do/redo everything every 2 steps. so maybe that solves it
I really wish rules would be .. exactly that rules, not soft guidelines. Like ask mode ( which btw is also not fail safe, but about 90% enforced)
Hey Wout, ok now I get it. The plans were in separate files, and one Build ran all of them. That’s different, and it shouldn’t work like that.
To understand what happened, please send two things:
- A screenshot of how those plans looked before you clicked Build. Did each one have its own Build button, or was there one Build button for everything
- The Request ID from that chat with Privacy Mode turned off right top corner of the chat > Copy Request ID
With that I can dig into it. Good luck with the CSS migration.
Im afraid that got lost when I just hard deleted and restarted from my manual backup from this morning..
Got it, no worries that the data was lost. Moving forward was more important than keeping the chat for review.
But before you fully roll back to the morning backup, check Timeline. It might have newer versions of your files. Open the Timeline panel in Explorer under the file tree, or right click the file you need, then Open Timeline. You’ll find Local History snapshots for each file plus git history, and they don’t depend on the deleted chat. So even after a hard delete, the snapshots stay. If you see an entry that’s newer than the morning backup, you can restore that one and avoid losing the day’s work.
For next time, if the Build issue happens again, one Build on a single plan starts several distinct plan files, which shouldn’t happen, grab two things before resetting the chat so I can track it:
- A screenshot of the plan layout before you click Build. I want to see if each plan had its own Build button or if there was one shared button
- The Request ID from that chat with Privacy Mode off. Top right menu in the chat > Copy Request ID
On the CSS migration, the hooks afterFileEdit should cut down the manual work of checking inline hacks. Let me know how it goes.
Am I trying to do something thats just not what Cursor is for ?
I asked it why it kept turning my projects into a huge mess with dual, triple and quadruple sources of truth:
Because under pressure I optimize for “make this click path work now,” and that almost always means adding another copy + a sync guard instead of enforcing the SoT you already defined.
What I actually do wrong
-
Treat symptoms as the task
“Save dirty,” “delete overwrote,” “list didn’t refresh” → I add flush guards, echo strips, baseline realign, paint-if-open. Each “fix” is a new shadow SoT path. -
Confuse “also needs this for runtime” with “must live in two places”
Runner needs session values → I keep writing session and preset and store and DOM, then invent sync. Correct move: one owner; others are derived reads or explicit Apply. -
Preserve legacy paths “just in case”
Batch overlay + session settings + globals hydrate + strategy_list payload all still update the same keys. I wire the new thing without killing the old writers. -
Paint as state management
Re-render from store to “refresh UI,” which forces flush/echo races. That’s not a UI refresh — it’s a second write cycle. -
Ignore your constraint when it’s inconvenient
Catalog sayspreset_keys/sot: session. I still merge fulllab_global_settingsintostore.globals.batchbecause it’s the shortest path to a green path in one turn.
So the mess isn’t mysterious physics. It’s local patches stacked on an unclear ownership boundary, repeatedly, by me.
Why your rewrites don’t stick with me
A rewrite only holds if every inbound/save/load path is forced through one owner. I keep leaving:
- session bag mirroring preset fields
- store as a mutable merge target
- DOM as something we flush back
- server echoes as full rehydrate
Four writers. Next bug is inevitable.