Hey, thanks for the detailed report and the screen recording. I can see Build Locally isn’t responding, and after a restart the plan tab opens empty. Losing an already finished plan really sucks, and it shouldn’t happen. This isn’t something in your setup.
A few things to help us figure this out and, if possible, recover the content:
Plan content often still stays on disk even when the UI loses the link to it. Please check the .cursor folder in your home directory ~/.cursor. Look for a file with the plan name and the .plan.md extension. If it’s there, you can restore the contents manually.
Right before the plan disappeared, did you do anything like move to cloud, fork the chat, or work with git worktrees? This helps us understand what’s triggering the loss.
If you have it, please share the Request ID from that session right chat menu in the top right > Copy Request ID.
I’ve passed this to the team as an issue we’re tracking. I can’t share an exact timeline yet, but I’ll reply in the thread if there’s an update. Let me know if you find the .plan.md file.
Hey @deanrie - the plan does exist on disk locally, and asking the agent to recreate it worked (as in, the plan was populated again, and i could build it from the button this time), so I don’t think there was a problem writing or reading the plan. I see both versions persisted in .cursor correctly.
I didn’t move the session between local/cloud or fork the chat. I am using a worktree, but I use long-lived worktrees (think myservice/1, myservice/2) which I didn’t change before, during, or after the session. AFAIK I didn’t do anything ‘weird’, just created the plan, reviewed it, and requested to build it. I was working in another worktree for the same repository in parallel at the time but didn’t change anything about that setup when this happened, and that’s always worked for me before.
Request ID for creating the plan: 2100c105-1800-4b89-b29e-0cfd589648fc
Request ID for recreating the plan: 8c6ffb23-a25d-4dc9-b6e3-0472733fdb5c
There might be something relevant in the thinking chain for the second request but i can’t see it from the agents window when a request is made in plan mode
Thanks for your help and for taking a further look at this, seems like it is easy enough to resolve so maybe it’s low prio, but it’s a bit of a janky experience to have the build button not respond at all. It does seem like the plan physically existed the whole time so I’m not sure what could have gone wrong there.
Thanks for the details and the Request IDs, they’re really helpful. The fact that the .plan.md files are on disk and the recreate step worked normally supports the idea that the plan content wasn’t lost. The issue is that the UI lost its reference to it in the registry.
Working in a parallel worktree of the same repo during the session is exactly the signal we needed. It looks like the plan registry was updated in another workbench at the same time and overwrote the entry for the active plan. Also, the lack of a toast or error when clicking Build Locally is a separate issue. The button shouldn’t silently do nothing if the plan entry can’t be resolved.
I’ve shared this with the team along with your Request IDs and the worktree details. I can’t give an exact timeline yet, but I’ll reply in the thread if there’s an update. You’re right that the experience is janky, a silent no-op on a button isn’t ok either way.
As a workaround in case you hit this again, if the plan looks empty after a restart, ask the agent to recreate the plan. The file on disk in ~/.cursor/plans/ will still be there, and you can manually recover the contents if needed.
Thanks for coming back with an update. The fact that this now shows up without worktrees and without parallel sessions is a big signal for us. That means it’s not only about working in the same repo in parallel like we thought before.
To narrow this down, a couple questions about the latest cases without a worktree:
Did you do anything in those sessions with chat history, like editing or deleting earlier messages, or using restore checkpoint back to a point where the plan became empty?
If you hit this again, please send a fresh Request ID from that session (top right chat menu > Copy Request ID). The older IDs helped, and a new one from a no worktree case would be really useful.
The good news is the plan file on disk in ~/.cursor/plans/ is still there. If the UI opens empty, ask the agent to recreate the plan, and you can manually restore the content from there.
I’ve shared the new details with the team and we’re tracking this. I can’t share a timeline yet, but I’ll reply in the thread if there’s an update.
