When using Claude Opus 5, the AI clears local storage, causing the cursor to restart. After restarting, the model re-enters the beginning of the loop, resulting in an infinite loop.
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!
Hey @rrr_Sheldon! Thanks for the report.
To stop the loop: open Cursor Settings → General and turn off the option to automatically resume/continue agents after a reload or restart (or just archive that agent in the Agents Window). Then fully quit Cursor and reopen. What’s happening is that Cursor auto-picks the interrupted agent back up on relaunch, so it keeps re-running the step that triggered the restart. This is an issue we’re tracking, and it isn’t specific to Opus 5.
One thing that would help us pin it down: what was the exact step the agent ran right before Cursor restarted (a screenshot of that tool call is perfect)?
I’m having trouble pinpointing the exact scenario. My recollection is roughly this: The Model determines that it needs to clear the local cache of the current Cursor project before restarting the Cursor. However, in reality, when the local cache is cleared, the dialogue history and current progress are also cleared, causing the Model to fall back into the task’s initial state: “I need to clear the local cache and restart the Cursor.” This is the main logic causing the infinite loop. I think the key issue might be how to prompt the Model to persistently store previous operation history before clearing the local cache, or provide a productized method, such as returning restart logs to the Model. Otherwise, the Model cannot effectively determine whether to restart, thus continuing to fall into the infinite loop.
Besides this, I encountered another problem today, which I believe is also caused by this feature.
Yesterday, before closing the Cursor, I tried requesting a plan, but then I manually stopped the task. After restarting Cursor, the task was reactivated without a stop option. This was likely triggered by a new request being sent. At startup, the Model didn’t receive a clear indication that the previous task had stopped (I don’t know why clicking stop was ineffective; I simply exited Cursor, and when I exited, it prompted “Stop current progress?”, which I clicked “Yes,” but that might actually be ineffective). This caused the task to re-enter a resumed state, and at this point, the stop button’s status capture also failed.
I suspect that the automatic resume function lacked testing and troubleshooting for extreme cases. I hope this can be identified and fixed as soon as possible.
Hey @rrr_Sheldon, sorry about the loop. This isn’t intended behavior and isn’t specific to Opus 5: when an agent’s turn is interrupted by a restart, Cursor auto-resumes that same agent on the next launch, so the step that caused the restart just replays. It’s an issue we’re tracking.
To break it now, in the Agents Window open Cursor Settings > General and, under Startup, turn off Continue Interrupted Agents (or archive that agent), then fully quit and reopen. One caution: avoid clearing Cursor’s own app data, since that also wipes your chat history and settings; back the folder up first if you ever need to.
To help us pin down the trigger: what exact step did the agent run right before the restart (a screenshot of that tool call is ideal), and your OS and Cursor version? If you can turn off Privacy Mode and reproduce once, a Request ID from that chat lets us look at the run directly.