Chats show "Chat Too Old" / "Conversation Corrupted" after update — conversationState lost, no migration performed

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

After updating Cursor (from January 2026 build in C:\Program Files\cursor\ to March 2026 build in AppData\Local\Programs\cursor\), existing chats show either “Conversation has corrupted data” or “Chat Too Old — this chat was created in an older version of Cursor and is no longer supported.”

New chats created after the update work fine.

Root Cause Analysis (done manually via sqlite3 + PowerShell):

Both state.vscdb files (globalStorage and workspaceStorage) pass PRAGMA integrity_check = OK. All message data is intact (41,349 bubble entries, 291 chat headers, 359 composerData records).

Finding 1: Schema version mismatch — no migration

Three different _v format versions coexist in cursorDiskKV.composerData:

  • _v:10 — 75 entries (oldest, no conversationState field at all)

  • _v:11 — 272 entries

  • _v:14 — 11 entries (newest)

No migration from _v:10/_v:11 → _v:14 was performed on update.

Finding 2: worktreeStartedReadOnly causes “Corrupted” label

In workspace ItemTable.composer.composerData, exactly 4 chats had an extra field "worktreeStartedReadOnly":false in their headers. These were the only 4 showing “Conversation Corrupted”. The remaining 287 chats did not have this field. Removing it from the JSON resolved the “Corrupted” label — but revealed the next issue.

Finding 3: conversationState lost — server rejects as “Too Old”

After fixing the corrupted label, chats now return a server error:

{“error”:“ERROR_CUSTOM”,“details”:{“title”:“Chat Too Old”,“detail”:“This chat was created in an older version of Cursor and is no longer supported.”}}

Analysis of composerData entries in globalStorage shows:

  • Working chats (created after update): conversationState contains a valid base64 token (~200 chars)

  • Broken chats (pre-update): conversationState is either "~" (empty) or missing entirely

  • Some broken chats also have hasCorruptedCheckpoints: true

The conversationState is a server-side session token. Without it, the API rejects the chat. It cannot be reconstructed client-side.

Steps to Reproduce

Have Cursor installed (January 2026 build)
Install a new version manually (March 2026 build) — both versions may have briefly run simultaneously
Restart Cursor
All pre-existing chats show “Conversation Corrupted”

Expected Behavior

Cursor should migrate older composerData entries (_v:10, _v:11) to the current schema (_v:14) on startup, preserving chat history.

Operating System

Windows 10/11

Version Information

Version: 2.6.19 (user setup)
VSCode Version: 1.105.1
Commit: 224838f96445be37e3db643a163a817c15b36060
Date: 2026-03-12T04:07:27.435Z
Build Type: Stable
Release Track: Default
Electron: 39.4.0
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200

For AI issues: add Request ID with privacy disabled

Request ID: 88f049b6-8568-453b-9c6a-fcec403937fe
This conversation has corrupted data. You can view and export it, but new messages cannot be sent. Please start a new conversation to continue.

Does this stop you from using Cursor

No - Cursor works, but with this issue

3

Hey, thanks for the report.

Yep, I can confirm this is a known issue and the team is aware. Your analysis matches what we’re seeing. When updating between major versions, the composerData schema migration doesn’t run, so conversationState gets lost for older chats.

Unfortunately, as you correctly found, conversationState is a server token and can’t be restored on the client. You can export old chats via view and export, but you won’t be able to continue the conversation in them.

Also, good catch on worktreeStartedReadOnly, I’ll pass that along to the team.

I’ve shared your report with the full analysis details so we can prioritize it. For now, the only workaround is starting new chats. There’s no ETA for a fix yet, but your report will definitely help with prioritization.