Daily History Directory Bug - Past Chats Not Accessible

Bug Reports
1

Hello everyone,

I’ve been experiencing an issue with Cursor where I’m unable to access chats/composer from previous days. After some analysis, I discovered that the chat history is stored in the directory:
~/.config/Cursor/User/workspaceStorage

Inside this directory, a new folder is created for each project along with the date (the folder name is generated as an MD5 string based on the project and the date probably), which means that for the same project a different folder is generated every day. I verified that if I copy yesterday’s folder content into today’s folder, my expected chat history is correctly restored (at least it appears so).

Note: I’ve already searched the forum for a solution to this issue, but I haven’t found one.

I might have missed a configuration option or inadvertently enabled a setting that is causing this behavior. If there’s a valid reason behind it, please forgive me and explain how I can resolve or work around this problem.

Thanks!

For reference, here is my environment:

  • Version: 0.45.14
  • VSCode Version: 1.96.2
  • Commit: 906121b8c0bdf041c14a15dac228e66ab5505260
  • Date: 2025-02-19T20:36:48.096Z
  • Electron: 32.2.6
  • Chromium: 128.0.6613.186
  • Node.js: 20.18.1
  • V8: 12.8.374.38-electron.0
  • OS: Linux x64 6.8.0-52-generic
2

Resolved: Understanding workspaceStorage Directory Behavior

After thorough investigation, I’ve discovered that what appeared to be a bug is actually intentional behavior in VSCode (and thus Cursor).

Key findings:

  • Not date-related: The directories in ~/.config/Cursor/User/workspaceStorage are generated using an MD5 hash combining:

  • The absolute path of the project

  • The filesystem inode (on Linux)

  • My specific setup: I use aufs filesystem which gets remounted daily. This changes the inodes, causing a new storage directory to be generated each day.

  • By design: This behavior is intentional to ensure VSCode doesn’t reuse storage when a folder is deleted and recreated (which would have a new inode).

Workaround:

For those using filesystems like aufs that change inodes on remount:

  • Manually copy content from the previous directory to the new one

  • Or use a filesystem that maintains stable inodes

I apologize for the noise with this report. This isn’t a bug but designed behavior that has unexpected effects in particular setups like mine.

Thank you for your attention. This issue can be closed.