Agent/Chat window is disappearing quickly after showing up

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Agent/Chat window is disappearing quickly after showing up. Whether I try to open it via the chat button in the top-right or via cmd+i on the keyboard.
See the attached video recording for more context.

Context: I recently purchased the yearly pro plan and this happened :frowning:

Steps to Reproduce

  1. Open Cursor
  2. Try to open the chat window

Expected Behavior

Chat window should open and I should be able to type something.

Screenshots / Screen Recordings

Operating System

MacOS

Version Information

Version: 3.0.16 (Universal)
VSCode Version: 1.105.1
Commit: 475871d112608994deb2e3065dfb7c6b0baa0c50
Date: 2026-04-09T05:33:51.767Z
Layout: editor
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: Darwin arm64 24.6.0

Does this stop you from using Cursor

Yes - Cursor is unusable

Hey, thanks for the detailed report and the video. This looks like a bug related to updating to v3.0.16, the team is already aware of similar issues with the chat panel on this version.

Try this:

  1. Open the Command Palette with Cmd+Shift+P and run Developer: Reload Window
  2. Last option, delete the ~/.cursor folder after making a backup, then restart Cursor. This will reset all settings, but it should clear any corrupted chat state

If none of these steps help, let me know and I’ll pass it to the engineers to investigate with your account info.

Thanks for the prompt response, Dean!

I tried both the steps, but no luck :frowning: - still the chat window is crashing after opening up.

Please let me know the next steps, and if any details are needed from my side.

Also, recently (one-two days back) I am seeing Cursor is sticking too much and not smooth as before. It also constantly occupies so much of CPU usage in via “Activity Monitor“ [screenshot attached]

Earlier, my total CPU usage was well below 5% constantly. Now, it’s ~20% constantly. Notice how CPU usage goes below 5% after quitting Cursor [screenshot attached]

I think this is something to do with some bug in IDE.

CPU usage After quitting Cursor:

Thanks for the heads-up. Let’s try a couple more things to diagnose this:

  1. Run Cursor from the terminal with the --disable-extensions flag. This rules out an extension conflict:
cursor --disable-extensions
  1. If the issue is still there, open Developer Tools: Help > Toggle Developer Tools, go to the Console tab, try opening chat, and paste any errors (the red lines) that show up in the console at that moment.

This info will help us figure out if it’s a client-side bug or something related to the chat state.

Thanks Dean for providing the next steps.

  1. cursor --disable-extensions did not work. Tried opening Cursor via that, and the issue is there.

  2. However, in “Developer Tools” I found something interesting. After triggering the “bug“ by opening the chat window - I see a lot of warning logs like, [storage] Item exceeds IPC threshold: key=“composer.composerHeaders…” size=5,255,287 bytes in Console and the size is constantly increasing every second. See the attached screenshots. I am also attaching screenshot with expanded view. I think this is the reason. Let me know if more details are needed from my side.

Sharing the screen recording of reproducing this bug and showing what the “Console” looks like at the same time.

Also tried quitting Cursor to show the errors which comes up at the very end, and the CPU usage spike in Activity Monitor.

Great catch with DevTools, that’s super helpful. The issue is very clear: the composer.composerHeaders key is growing out of control in storage (5+ MB and still growing). That goes over the IPC threshold and crashes the chat panel. That also explains the high CPU.

Try this workaround to clear that state:

  1. Fully quit Cursor
  2. Open Terminal and run:
cd ~/Library/Application\ Support/Cursor/User
  1. Find and delete files related to the composer state. Specifically check files in globalStorage and workspaceStorage. You can back up the folder before deleting:
cp -r globalStorage globalStorage_backup
  1. Start Cursor again

If that doesn’t help, you can try a full reset by renaming the whole ~/.cursor folder:

mv ~/.cursor ~/.cursor_backup

I’ve passed this to the team along with your screenshots. The constantly growing composerHeaders key is clearly a bug on our side, likely related to the update to v3.0.16. I don’t have an exact ETA for a fix yet, but your report and DevTools logs really help us prioritize it.

Let me know if the workaround helped.

Seems like deleting state.vscdb.backup and state.vscdb from globalStorage helped. After I deleted them, and deleting the recently updated folders (ls -lht) from workspaceStorage, I see I needed to re-login in Cursor and all of my previous chat histories, code files opened, etc. were gone - but the issue is now gone. Or at least, I can not reproduce it now.

Just curious - is there any way to downgrade from v3.0.16 and then bring back globalStorage and ~/.cursor from the backup? And then once you guys fix the bug in the next version, I update the Cursor again?

Glad the workaround helped!

About downgrading, sadly there’s no official way to roll back to a previous version. Cursor updates automatically, and even if you install an older build manually, it’ll update again.

But the main point is that if you restore globalStorage from a backup, the issue will come back, because that composer.composerHeaders key in storage is what causes the bug. So a downgrade won’t help here, the data was already corrupted.

Chat history is tied to the same files we had to delete, so there’s no way to restore it separately without bringing back the broken state.

We’ve logged the bug about unlimited composerHeaders growth, the team is aware. No ETA yet, but your report and the DevTools logs really help with prioritization. We’ll update the thread if there’s news.

While the bug is gone, I can not use Cursor as before anymore, as I deleted state.vscdb and state.vscdb.backup files from globalStorage - the extensions and other stuff is gone, so a lot of friction while using Cursor.

Is there any way I can delete specific part of the files/folders to get it working like before? For e.g. if I delete all the chat histories, then it may work as before? Or any other specific files/folders to delete?

My goal is to get Cursor working as before, while deleting the problematic part - instead of deleting everything.

Hey, state.vscdb is a SQLite database, so you can delete just the problematic key without touching anything else.

composer.composerHeaders in the ItemTable table is the chat history index that Cursor uses for the sidebar. That’s what grows over time and crashes the chat panel. The actual chat data is stored separately in the cursorDiskKV table and won’t be affected.

If you still have a state.vscdb backup (you ran cp -r globalStorage globalStorage_backup), you can restore it and surgically remove only that key:

# Fully quit Cursor

# Restore the backup (if the backup is in ~/Library/Application Support/Cursor/User/globalStorage_backup/)
cp ~/Library/Application\ Support/Cursor/User/globalStorage_backup/state.vscdb \
   ~/Library/Application\ Support/Cursor/User/globalStorage/state.vscdb

# Delete only the problematic key
sqlite3 ~/Library/Application\ Support/Cursor/User/globalStorage/state.vscdb \
  "DELETE FROM ItemTable WHERE key = 'composer.composerHeaders';"

After that, your extensions and settings should come back. The chat history in the sidebar will be empty because the index is deleted, but the actual chat data will still be on disk in cursorDiskKV.

If the backup is already deleted or overwritten, then unfortunately there’s nothing to restore. For next time, this approach is very useful until the bug is fixed.

Let me know if it worked.

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When clicking on the recovery record created in the chat, the cursor chat window will crash and then it will never open again.

Steps to Reproduce

First, click on the chat window, then click on the chat history record. The chat window will crash and close. After that, you won’t be able to use the chat window anymore.

Operating System

Windows 10/11

Version Information

lastest
lastest

Does this stop you from using Cursor

Yes - Cursor is unusable