Chat history missing but local state and transcripts present

[cloaked1 (J)]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Chat history missing/inaccessible despite local state and transcripts present (Linux)

Steps to Reproduce

1. Open IDE
2. Start chat (agent)
3. Interact. Ask questions. Do whatever.
4. Close IDE
5. Open IDE
6. Observe…no chat history

Expected Behavior

I expect chat history to be present on re-open of IDE

Operating System

Linux

Version Information

Version: 2.6.22
VSCode Version: 1.105.1
Commit: c6285feaba0ad62603f7c22e72f0a170dc8415a0
Date: 2026-03-27T15:59:31.561Z
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Linux x64 6.17.0-19-generic

For AI issues: which model did you use?

Auto

For AI issues: add Request ID with privacy disabled

upon request if required

Additional Information

Note that “xxxxxxxxxx” is used to obfuscate the actual name.

Where does the bug appear?
Cursor IDE (chat/composer history UI)

Cursor version:
2.6.22

Operating system:
Linux 6.17.0-19-generic

Workspace:
file:///home/xxxxxxxxxxxxx

Problem summary:
Previous chats are not visible/recoverable in the Cursor chat UI, even though local Cursor state appears present and agent transcripts exist on disk.

Expected behavior:
Previously created chats should be listed and open normally in Cursor.

Actual behavior:
Chat history appears missing/inaccessible in the UI.

What I already verified locally:

1. User settings do not disable history:
   ~/.config/Cursor/User/settings.json
   (only basic window/editor settings present)
2. Workspace mapping exists:
   ~/.config/Cursor/User/workspaceStorage/b005c3e8c2da28e008045e640f776c66/workspace.json
   contains:
   {
   “folder”: “file:///home/xxxxxxxxx”
   }
3. Global state DB exists and is populated:
   ~/.config/Cursor/User/globalStorage/state.vscdb (~42MB)
   • ItemTable row count: 131
   • contains Cursor/composer/auth/privacy keys
4. Privacy mode is no-training, not no-storage:
   • cursorai/donotchange/privacyMode = true
   • cursorai/donotchange/newPrivacyMode2 = {“privacyMode”:“PRIVACY_MODE_NO_TRAINING”}
   • cursorai/donotchange/partnerDataShare = false
5. Local agent transcript files exist:
   ~/.cursor/projects/home-xxxxxxxxx/agent-transcripts/*.jsonl
   (multiple transcript files present)
6. Quick log scan did not show obvious sqlite/corruption/load-history errors:
   ~/.config/Cursor/logs/**

Impact:
High. Prior chat context is unavailable, disrupting active work and trust in chat persistence.

Request:
Please investigate chat history indexing/loading for this account/workspace and advise recovery steps. If this is a known regression in current versions, please share workaround/ETA.

Does this stop you from using Cursor

No - Cursor works, but with this issue

[Colin]

Thank you for the detailed report!

Chat history is tied to a workspace ID (a hash computed from your folder path). On Linux, this hash also incorporates the folder’s inode number as a salt. Chat history can become disconnected in a few situations:

• Chats were created without a folder open. Looking at your repro steps (open IDE → chat → close → reopen), if you’re not opening a specific folder before chatting, those chats are stored under a special transient workspace. They won’t appear when you later open Cursor with a folder, and vice versa. This is the most common cause of this symptom.
• The folder was renamed or moved. Even /home/oldname → /home/newname produces a completely different workspace ID, orphaning your old chats in their original storage location.
• The folder’s inode changed. This can occur if the folder was deleted and recreated, the filesystem was reformatted, or you restored from a backup. Certain filesystem configurations (such as btrfs subvolumes or bind mounts) can also trigger this.

A couple of questions to help narrow this down:

1. In your repro steps, when you “Open IDE” — are you opening a specific folder (File → Open Folder), or just launching Cursor without opening anything?
2. Does the path in your workspace.json (file:///home/xxxxxxxxx) still match the exact folder you’re currently opening?
3. Does this happen consistently for every session, or only for specific folders?

Hopefully, this is just a renamed folder, but if the path hasn’t changed, your answers to the above questions will help us dig further.

[cloaked1 (J)]

1. I’ve only ever opened cursor under my $HOME, which has never been moved or migrated.
2. Yes
3. This consistently occurs over every restart.

[cloaked1 (J)]

Hi @Colin - just wondering if you’ve had a chance to look into this more given my responses to your questions.

[Colin]

Hey @cloaked1!

Sorry for the delayed response here.

Since the folder hasn’t moved and this happens on every restart, I’d like to rule out one last thing under pretty controlled conditions!

First, please make sure you’re using Cursor 3.0 (downloads)!

Test 1 — quit and reopen:

mkdir $HOME/cursor-history-test
echo hi > $HOME/cursor-history-test/README.md
stat -c '%n  inode=%i  device=%D' $HOME/cursor-history-test   # inode BEFORE
cursor $HOME/cursor-history-test

Start a new chat, send a message, wait for a reply. Then fully quit Cursor.

pgrep -af cursor                                               # should print nothing
stat -c '%n  inode=%i  device=%D' $HOME/cursor-history-test    # inode AFTER
cursor $HOME/cursor-history-test                                # reopen

Check the chat history sidebar — is the chat still there?

Test 2 — full system reboot:

If the chat survived test 1, do a full system reboot and reopen the same folder:

stat -c '%n  inode=%i  device=%D' $HOME/cursor-history-test    # inode AFTER reboot
cursor $HOME/cursor-history-test

Check the history sidebar again. Are the chats still there?

Please share back:

• All the stat outputs
• Whether the chat persisted after test 1 (yes/no)
• Whether the chat persisted after test 2 (yes/no)

The goal here is to understand exactly why this is happening on your machine — and to see if there are specific circumstances (e.g. a reboot vs. a quit, or a particular folder path) where it doesn’t happen. Thanks!