Where does the bug appear (feature/product)?
Somewhere else…
Describe the Bug
Deleting a conversation (from either the IDE chat panel or the Agents Window) is a
soft delete. It removes the message bubbles but leaves the composerHeaders row and
the composerData body behind in globalStorage/state.vscdb. These empty “zombie”
headers are hidden from the UI (0-bubble chats are not listed), so the chat looks
gone, but the records persist indefinitely. There is no garbage collection or
cleanup pass that ever reclaims them.
The delete path is also internally inconsistent: sometimes the header outlives the
body, and separately there are composerData bodies with no matching header at all.
Empty-draft chats (a tab opened but never used) are likewise never reclaimed.
Steps to Reproduce
- Create a new chat and send at least one message.
- Delete the chat from the UI (IDE panel or Agents Window).
- Inspect globalStorage/state.vscdb:
- composerHeaders still contains the row for that chat.
- cursorDiskKV still contains composerData:.
- Only the bubbleId::* rows are gone.
Expected Behavior
Deleting a chat removes its header and its composerData body (a cascade delete), or
a periodic background pass garbage-collects headers/bodies that have zero bubbles
(with a short grace period). Empty drafts should also be reclaimed.
Operating System
Windows 10/11
Version Information
3.12.17, also reproduced in 3.12.29
Verified on 3.12.29 (latest at time of filing):
- Fresh UI-only repro: created a new chat, then deleted it from the UI. Result:
its composerHeaders row and composerData body remained, only the bubbleId rows
were removed. The row was left with isArchived=1, so “delete” appears to be
implemented as archive-plus-strip-bubbles rather than a true delete. - Updating to 3.12.29 did not reclaim any pre-existing empty headers/orphaned
bodies, so there is no cleanup migration either.
Additional Information
Actual Behavior
Header and body remain forever. Measured on my install:
- 22 of 42 chat headers (52%) are empty zombies with 0 bubbles.
- 6 composerData bodies are orphaned with no matching header.
- state.vscdb is 483 MB, inflated in part by this accumulation.
Impact
Unbounded growth of state.vscdb over time, user confusion that “deleted”
chats are not truly removed, and no way to clean up empty drafts from the UI.
Suggested fix
Cascade delete to composerData and related keys; add a periodic GC for zero-bubble headers/bodies; ship a one-time migration to clean existing orphans.
How I found this
I stumbled onto this while investigating a separate issue. I believe that after
migrating my Cursor conversation data across a Windows reinstall, the same project
folder ended up associated with two different workspace IDs. As a result, the
Agents Window and the IDE started creating new conversations under different IDs,
so each surface showed an inconsistent slice of my history.
While tracking that down (I ultimately got the two to converge by moving
the project to a fresh directory, then reconciling the existing history), I
inspected globalStorage/state.vscdb directly and found a large amount of hidden,
never-reclaimed data behind the scenes – which is what this report is about.
Important: the zombie-header behavior does not depend on any of that history. It
reproduces on a clean install with UI actions only: create a chat, send one
message, delete it from the UI, and its composerHeaders row plus composerData body
remain (only the bubbleId rows are removed).
Does this stop you from using Cursor
No - Cursor works, but with this issue