Lost Chat History after saving new workspace

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I think I’ve hit a chat-history/workspace-migration bug.

What happened:

  1. I started working in a multi-folder workspace in Cursor before officially saving it as a .code-workspace.
  2. During that time, I had multiple chats/agent sessions and made real progress in them.
  3. Later, I saved the workspace and then added another folder to it.
  4. After reopening the saved workspace, the old chats no longer appeared in the chat history/sidebar for the current workspace.

Important details:

  • The old chats are NOT actually gone.
  • They still exist locally on disk.
  • They can be opened directly by transcript ID/link in Cursor.
  • Once opened, I can even continue the chat.
  • But they still do not show up in the normal history/sidebar for this saved workspace.

So the issue seems to be:

  • transcript data still exists and is readable
  • direct-open works
  • but the workspace history/sidebar does not associate or surface those chats after the workspace was saved / changed

Why I think this is a Cursor bug:

  • I did not do anything unusual besides saving the workspace later than when I started chatting.
  • I would expect the chat history from the unsaved/temp workspace to migrate or remain visible after saving the workspace.

What I tried:

  • I located the old transcript files locally.
  • I copied them into the saved workspace’s transcript folder.
  • Cursor can open the old chats directly by ID/link.
  • However, the chats still do not appear in the current workspace history/sidebar.

Environment:

  • macOS 15 / Darwin 25.3.0
  • Multi-root workspace
  • Original folders involved:
    • jfm-be-services
    • jfm-irrs-batch-task
  • Later I saved the workspace and added:
    • jfm-frontend

Examples of recovered transcript IDs that open but do not appear in the sidebar:

  • 3d85aa2b-25d2-4833-a002-13f3d1dd2cb6
  • 059f98ee-3c64-4df1-a6e9-37ba3efc3601
  • 31c1cba9-34ac-4783-b067-4d9a4b8c7528
  • 2fc060b6-f38c-4012-ac1c-73e464dcc0f4

Question:
Is there an official way to:

  1. reattach those chats to the current saved workspace history/sidebar, or
  2. migrate chat history from the original unsaved/temp workspace identity into the saved workspace?

I can provide transcript exports or screenshots if helpful.

Steps to Reproduce

  1. Open a folder and use add folder to workspace
  2. Start some Chats and Agents
  3. Save workspaces and close.
  4. Reboot machine, open saved workspace.
  5. (Optional) Add another folder to workspace
  6. Inspect agent history

Expected Behavior

Workspace agent and chat history should appaer.

Operating System

MacOS

Version Information

Version: 2.6.13
VSCode Version: 1.105.1
Commit: 60faf7b51077ed1df1db718157bbfed740d2e160
Date: 2026-03-06T06:17:49.499Z
Build Type: Stable
Release Track: Default
Electron: 39.6.0
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Darwin arm64 25.3.0

Does this stop you from using Cursor

No - Cursor works, but with this issue

Hey, great bug report. You explained everything clearly.

This is a known issue with multi-root workspaces. Here’s what’s happening: Cursor stores the chat list in the sidebar in a SQLite file called state.vscdb, and it’s tied to the workspace ID. When you switch from an unsaved multi-folder workspace to a saved .code-workspace, the workspace ID changes, so the new workspace doesn’t know about the old chats.

The transcript data, like you already found, stays on disk and is still fine. But there isn’t a built-in way to reattach it to the new workspace yet.

What you can do:

  1. To access old chats, you already found the transcript IDs and can open them directly. You can also point the agent at the transcripts folder so it can help you find the right ones.

  2. To avoid this going forward, save the workspace as a .code-workspace before you start using chats. Always open the workspace through the same .code-workspace file, and that will keep the workspace ID stable.

The team is aware of the persistence issue in multi-root workspaces.

Let me know if you want help restoring specific sessions.