Cursor IDE + Agents window (Glass), multi-root workspace
Describe the Bug
When building a multi-root workspace by adding folders one-by-one, Cursor creates a temporary workspace named workspace.json. Agent chat history is bound to that temporary workspace identity.
Later, if I Save Workspace As to a readable name on Desktop (e.g. MyProject.code-workspace), Cursor creates a second workspace identity:
New named workspace: shows in Repositories, often No agents yet
Old workspace.json: still holds all previous Agent chats
Problems:
Save As does not migrate Agent chats to the new workspace (feels like data loss).
Temporary workspace always displays as generic workspace.json, hard to identify; renaming it breaks the binding.
After Save As / path changes, Agent → Open IDE may fail to resolve folders (especially with relative paths); folders appear missing even though repos still exist on disk.
Removing one of the twin workspaces from Repositories makes both look gone until reopen; then both reappear. Confusing and risky.
Expected:
Save As / rename workspace should either migrate chats + keep folder binding, or clearly warn that this creates a new identity and will orphan chats.
Repositories should show a human-readable project name for temporary multi-root workspaces, not only workspace.json.
Agent and IDE should share one stable workspace identity for the same folder set.
Steps to Reproduce
Open Folder A, then Add Folder B/C (unsaved multi-root) → chats accumulate under workspace.json
File → Save Workspace As… to Desktop MyProject.code-workspace
Reopen / check Agents Repositories
Observe twin entries: named workspace empty (or new chats only), old chats remain under workspace.json
Rename workspace / Save As again / remove one entry → chats/folders become hard to find or Agent cannot move root (“Cannot pull a multi-repo cloud agent into a workspace with different repositories”)
Expected Behavior
One workspace identity for one folder set
Save As migrates Agent history OR warns and offers “move chats”
Readable display name without requiring dangerous rename of the workspace file
Absolute/relative folder paths remain valid across Agent ↔ IDE
Actual Behavior
Twin workspaces; chats orphaned on workspace.json
Rename/Save As breaks usability
Folder resolution failures between Agent and IDE
Operating System
macOS (darwin)
Additional context
Chats still exist in local DB / conversation-search; not deleted, just unbound from the new workspace ID
Workaround today: never Save As after chatting; or Save As immediately when adding 2nd folder, then only open that file forever; never rename workspace file
This is painful for multi-repo teams who need a Desktop .code-workspace for convenience
Steps to Reproduce
In Cursor, open Folder A, then use Add Folder to Workspace to add Folder B and Folder C (do not save a .code-workspace yet).
Create several Agent chats and work in them. In Agents → Repositories, chats appear under a temporary workspace labeled workspace.json.
Use File → Save Workspace As… and save to Desktop as MyProject.code-workspace.
Reopen / check Agents → Repositories.
Observe two workspace entries:
MyProject (new identity, often “No agents yet” or only new chats)
workspace.json (old identity, still holding the previous Agent chats)
Try renaming the workspace, Save As again to another path, or remove one of the twin entries.
Result: chats stay orphaned on workspace.json; Agent → Open IDE may fail to resolve folders; removing one entry can make both disappear until reopen, then both come back.
Expected Behavior
Saving or renaming a multi-root workspace should keep a single stable workspace identity for the same folder set.
Agent chat history should migrate with Save Workspace As / rename, or Cursor should clearly warn that a new identity will be created and offer to move chats.
Temporary multi-root workspaces should show a human-readable name in Repositories, not only generic workspace.json.
Agent and IDE should resolve the same folders after Save As / reopen; folder paths should remain valid across Agent ↔ Open IDE.
Removing or reopening a workspace should not create confusing twin entries or make existing chats appear lost.
Hey, thanks for the detailed report. I went through it point by point.
You read the behavior correctly. When you use Save Workspace As, the saved .code-workspace gets a new workspace identity, and chats created in the unsaved temporary workspace stay linked to the old id. Important: nothing gets deleted, so they still show up in the Agents Window under the workspace.json section. This isn’t data loss, the chats are still there.
This is a known issue we’re tracking, along with the generic workspace.json label for unsaved workspaces. I can’t share an exact timeline yet.
For now, two things help:
After Save Workspace As, keep working in the same IDE window by sending one message in an existing chat or starting a new agent before you close or reopen the window. On your current version, this is what moves the chat list to the saved workspace. Closing the window right after saving is what leaves them behind.
Your existing chats are still available under workspace.json in the Agents Window, and you can keep using them from there.
If you try step 1 on a clean test workspace and the chats still stay under workspace.json, let me know whether the Agents Window was open at the same time, and share the contents of the saved .code-workspace file. That should help us nail down the remaining case.
Thanks for the clear explanation — that matches what I observed.
I’ll try step 1 on a clean test multi-root workspace: Save Workspace As, then send a message in an existing chat / start a new agent in the same IDE window before closing. I’ll report back if the chat list still stays under workspace.json, including whether the Agents Window was open and the contents of the saved .code-workspace file.
Same failure, with a close-time save that the workaround in the staff reply cannot cover.
Cursor 3.21.16, Ubuntu 24.04.5.
I did not use File → Save Workspace As while the window stayed open. I opened one repo, started agent chats, then added more folders to the same window and kept chatting. On close, Cursor asked me to save the workspace. I saved a .code-workspace outside ~/.config/Cursor/Workspaces/. Reopening that file shows the folders and an empty agent sidebar.
Two things differ from this report and from the suggested workaround:
The save is part of closing the window, so I cannot send one more message in that window before close. That step is the close.
The untitled file ~/.config/Cursor/Workspaces/<id>/workspace.json is deleted from disk. The Agents window still groups the old chats under an entry named workspace.json. That entry is not a file anymore: right-click → Open in IDE reports “Path does not exist”.
The chats are still in globalStorage/state.vscdb. Each composerHeaders row still has workspaceIdentifier pointed at the deleted workspace.json. Changing only the workspaceId column is reverted on the next launch: Cursor rebuilds it from that JSON and from composer.composerData in the old workspaceStorage directory, and the chats attach to the deleted workspace again.
Expected for this close-time save: either move the existing chats onto the saved .code-workspace, or warn that they stay bound to a file that is about to be deleted.
Hey, thanks for the detailed report. You correctly pointed out that your flow is different from what was discussed above.
You’re right. When the save happens at window close time, the workaround “send one more message before closing” doesn’t apply, because the save is the close. This is a separate case we track on its own, and the current workaround really doesn’t cover it.
The key thing is that there is no data loss. The chats are still stored in state.vscdb. They just stay linked to the ID of the removed workspace.json and keep getting grouped under that entry in the Agents Window. Even if the file is already gone from disk, that is why you see “Path does not exist” when you try Open in IDE.
About manual edits. Changing the workspaceId column directly isn’t useful. Like you noticed, on the next launch it gets rebuilt from the JSON and the data in the old workspaceStorage, so your change gets reverted. I wouldn’t recommend going down that path.
I shared your notes with the team, especially that it’s reproducible on 3.21.16 and on Linux, and that close-time save is still not covered. I can’t share an exact timeline yet, but I’ll reply in the thread when we have an update.
Just in case, for current versions, if you’re adding folders to a window and you plan to save a .code-workspace later, it’s more reliable to save the workspace file right away while the window is still open and before you build up chats. Then always open that file. This way chats are linked to the saved ID from the start.