Cursor shows stale workspace scopes in Customize / Tools dropdown. They are not MCP servers and Worktrees is empty, but Cursor keeps recreating extension-host processes for them.
I tried:
disabling window.restoreWindows
removing workspaceStorage entries
removing active entries from globalStorage/state.vscdb
adding entries to cursor/glass.removedProjects
checking project .cursor/mcp.json and .mcp.json
The stale scopes still return after restart. This causes Cursor Helper (Plugin): extension-host processes to be spawned and consume memory.
Where is the supported UI or state location to permanently remove stale Customize / Tools workspace scopes?
Steps to Reproduce
Open Cursor on macOS.
Open Settings → Customize / Tools & MCPs.
The workspace scope dropdown shows stale workspace scopes, for example workspace-a / workspace-b, even after those workspaces were removed or are no longer active.
Try to remove/hide them from the UI. There is no visible remove option.
Quit and reopen Cursor.
The stale scopes return and Cursor starts extension-host processes for those old scopes again.
I also checked that these are not MCP servers from user mcp.json; the issue appears to be stale Cursor workspace/customize state.
Expected Behavior
Cursor should provide a supported way to remove stale Customize / Tools workspace scopes. Removed or inactive workspace scopes should not reappear after restart and should not spawn extension-host processes.
This looks related to these confirmed Cursor MCP lifecycle/cache bugs:
In my case, the stale entries are workspace scopes in Customize / Tools & MCPs, not active MCP server configs. They reappear after restart and spawn Cursor Helper extension-host processes. It looks like stale internal workspace/tool state is being rehydrated from Cursor’s internal cache.
Can Cursor provide the supported cleanup path for stale Customize workspace scopes? Is deleting globalStorage/state.vscdb still the recommended workaround for this case?
Hey there,
That scope selector in Customize / Tools & MCPs isn’t a saved list you can edit or delete from. It’s generated on the fly from your recently-opened and currently-open workspaces (capped at about 6, sorted alphabetically), so it’s rebuilt from your recents on every launch. That’s exactly why editing workspaceStorage, state.vscdb, glass.removedProjects, or window.restoreWindows doesn’t stick, and there’s no per-scope “remove” control today.
What actually helps:
Let them cycle out. The list is most-recently-used and capped, so a stale scope drops off once you open other workspaces and it ages out of your recents. Closing a workspace in the Agents Window also removes it from the active set.
Skip deleting state.vscdb here. That workaround is for a different problem (stale MCP server configs, like the threads you linked). It won’t remove these scopes (they regenerate from your recents), and that file holds your chat history and settings, so you’d lose those for no benefit.
On the extension-host processes: each workspace open in the Agents Window runs its own extension host by design (that’s how the multi-workspace window works), not stale state being rehydrated. The two threads you linked are a separate issue (MCP server child processes not terminating), which is why it looked similar but those fixes don’t apply here. To keep memory in check, keep fewer workspaces open at once, and reloading or closing the window releases the hosts. Recent versions also added cleanup that stops idle extension hosts to reclaim memory, so make sure you’re on the latest.
The one genuine gap is that there’s no supported way to manually remove a scope from that dropdown today. We’ll track interest in adding one. Let me know if the memory side is still rough after updating and trimming your open workspaces.
Partial cleanup of state.vscdb (for example workspaceMetadata, removedProjects, and worktree.metadata) did not stick. The stale scopes came back because they were resurrected from saved composerData agent chats still bound to those workspace URIs.
In my case, one stale scope kept its extension-host running for hours after restart, while the other stale scopes did not spawn hosts at all. That suggests this is not only an MRU dropdown issue. The MRU explanation may explain the capped Customize / Tools list, but it does not fully explain chat-bound scope resurrection or long-lived orphan extension hosts.
