Chats migrated to a phantom workspace

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor version: 3.9.16 (win32-x64)
OS: Windows 10/11

Summary

After a Cursor 3.x update, my agent chat history for one repo stopped
appearing under the folder workspace in the Agents/history UI. The chats are
now grouped under a phantom “workspace.json” (UNTITLED) workspace that I never
created. The chats still OPEN fine when clicked — this is a grouping/visibility
problem, not data loss. It did NOT start from any folder rename/move on my side;
it appeared after the update (possibly related to the new Agents Window).

Identities involved

  • Folder workspace hash (correct): f8ca2bb6cf4d2515eeeef273efe12e0d
  • Phantom workspace hash (deleted): a427552b975e79373b0a9b1dd8c83389
    (its workspaceStorage folder mapped to a multi-root config file
    …\Cursor\Workspaces\1782197364166\workspace.json)
  • Folder: D:\DAGroup\DAPPs\OSFACN\Git\OSFACN

What I verified (Cursor fully closed, read-only SQLite)

All local stores already point at the correct folder workspace:

  • composer.composerHeaders: 691/691 OSFACN chats have
    workspaceIdentifier.id = f8ca2bb6…; ZERO reference the phantom hash;
    no secondary workspace field exists on the headers.
  • glass.localAgentProjects.v1: only the correct OSFACN project
    (workspace f8ca2bb6…); no phantom project.
  • glass.localAgentProjectMembership.v1: 691 chats → OSFACN project; 0 phantom.
  • workspaceMetadata.entries: no phantom entry.
  • Target workspace state.vscdb: no phantom reference anywhere.
  • The phantom workspaceStorage\a427552b… folder was removed; storage.json
    restores only the folder (no phantom window / profile association).
  • The ONLY residual phantom strings are inside message payloads
    (bubbleId/agentKv/checkpointId) of two chats whose CONTENT discusses this
    very issue — i.e. text, not bindings.

What still happens

  • The Agents “Workspaces” sidebar still renders a “workspace.json” group
    containing the old chats, in BOTH “workspace” and “repository” grouping modes.
  • More importantly, the folder’s Agents/chat history does not surface these
    chats as belonging to the folder.
  • cursor/glassSidebarSettings.sectionOrderByGroupBy.repository still lists a
    leftover “workspace:a427552b…” section entry, even though no data binds to it.

What I tried (no effect)

  • Reparenting all bindings to the folder hash.
  • Removing the phantom workspaceStorage folder + all phantom-hashed DB keys.
  • Setting composer.composerData.hasMigratedComposerData=false and
    hasMigratedMultipleComposers=false in the workspace DB to force a re-migration
    (confirmed applied with Cursor closed) — grouping did not rebuild.
  • Toggling group-by workspace/repository.

Conclusion / request

Since every local store is already correct but the UI still groups chats under a
deleted workspace identity across restarts, this looks like either (a) a
server-synced grouping that re-hydrates the phantom identity, or (b) a UI/query
regression in 3.x. Please advise how to force the Agents history to re-derive
grouping from composer.composerHeaders.workspaceIdentifier, or fix the stale
section resolution. Happy to provide the (already-taken) DB backups and exact
key dumps.

Steps to Reproduce

Happened post update on relaunch, most likely not even directly, I cant exactly tell the timeline, but last week, Cursor worked normally even after the instalation of the update.
But this week, when I started the appliaction, the problem occured

Operating System

Windows 10/11

Version Information

Cursor version: 3.9.16 (win32-x64)
OS: Windows 10/11

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

This is really annoiyng it keeps moving the chats into Repos and random name change and folders and is killing the workflow efficiency and eating free tokens… they really need to fix this asap

6

I have had to add enforeced rules and ensure that cursor can’t do this as part of normal chat onboarding… same with MCP corruptions where it keeps requesting Gitlab instead of using the token and then once granted MCP it fails to actually do any action.

8

Hey there,
This is a known grouping/visibility bug on our side, not data loss (as you found, the chats still open fine).

The key thing that explains why your DB edits didn’t stick: the Agents sidebar decides grouping at render time from each chat’s live workspace/repo metadata, not from the stores you reparented (composer.composerHeaders / glass.localAgentProjects). Your 691 chats predate repo tracking, so they carry no repo metadata and fall back to that untitled multi-root identity, which renders as workspace.json. Editing the local stores can’t re-home them, and forcing re-migration won’t rebuild it.

Quickest way to get them all back in one place: at the top of the Agents sidebar, open the grouping control (it’s set to Repository) and switch it to Updated or Status. That drops the workspace/repo grouping entirely and lists every chat in one recency/status-ordered view, so all 691 surface together. Switching to Workspace grouping won’t help here - these older chats fall back to the same phantom group in both Repository and Workspace modes.

This is a known issue we’re aware of and improving, but I want to be straight with you: the improvements won’t retroactively re-home chats that were created before the workspace tracking existed, so the grouping toggle above is the reliable way to reach them for now. Nothing’s lost. Let me know if switching the grouping mode surfaces everything for you.