I was using plan mode + Claude Opus 4.6, and asked a few questions. After clicking the send button, it ran for a few seconds and then got stuck.
I tried force quitting and restarting several times, but it still ended up getting stuck.
Steps to Reproduce
Not sure if it’s because I’m using Xcode MCP and have already consumed around 70–80% of the context.
I just send a question, click the send button, and it gets stuck.
Sorry you’re running into this. The IDE freezing in plan mode is frustrating, especially when it persists after restarting.
Since the freeze continues even after force quitting and restarting, the most likely issue is that Cursor is restoring the problematic conversation on launch, which re-triggers the freeze. Here are a few things to try to get unblocked:
Start a fresh window without restoring the previous session: Open a new Cursor window (File > New Window), then close the frozen one. Avoid reopening the project that had the stuck conversation until Cursor is running clean.
Clear the stuck conversation: If you can briefly interact with Cursor before it freezes, try deleting the problematic conversation from the chat history panel. Alternatively, you can clear your composer state by removing files in ~/Library/Application Support/Cursor/User/workspaceStorage/ for the affected workspace.
Once you’re unblocked, to help us investigate the root cause:
Could you share the Request ID from the affected chat? (Right-click in the chat > Copy Request ID)
When it freezes, does your CPU spike significantly? (You can check Activity Monitor)
Thanks for the response. After switching different text, it works properly again now!
Here are some infos below Request ID: 510cd267-c8cb-4c46-9350-89c52104e558
And the CPU performance was normal and I didn’t notice any spike significantly at that time.
Glad switching to a different conversation got you unblocked!
I checked the request ID you shared and there’s no server-side error associated with it, which confirms the freeze was happening in the client’s plan rendering rather than a backend issue. The combination of plan mode, a large context window, and Opus 4.6’s verbose output can overwhelm the plan renderer when the generated plan is very large.
This is a known issue our team is tracking. In the meantime, if it happens again:
Start a new conversation before context gets too large rather than continuing in a deeply loaded session
Avoid reopening the frozen conversation – if Cursor restores it and freezes, use File > New Window to get a clean session first
Thanks for providing the request ID and CPU info. That helped confirm the issue is specifically in how large plans are rendered, not a server-side problem.