Cursor automatically closes large chat tabs

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor will automatically close chat tabs that it deems have gotten too big, on reload, or when doing cmd N to start a new chat while on an existing chat that’s too big.

Steps to Reproduce

Make a chat thats quite big lots of messages

Expected Behavior

It should just leave it there as I left it. I’m a professional trying to juggle multiple agents at once, this is just so annoying and feels like babysitting.

Operating System

MacOS

Version Information

Version: 2.4.28 (Universal)
VSCode Version: 1.105.1
Commit: f3f5cec40024283013878b50c4f9be4002e0b580
Date: 2026-02-03T00:56:18.293Z
Build Type: Stable
Release Track: Default
Electron: 39.2.7
Chromium: 142.0.7444.235
Node.js: 22.21.1
V8: 14.2.231.21-electron.0
OS: Darwin arm64 25.2.0

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

3

Hey, thanks for the report. A similar issue has come up before, when chat tabs get closed after restarting: Chat Tabs Automatically Close When IDE is Closed

To dig in, we’ll need a bit more info:

  • Do the chats disappear from the history too (Chat History panel), or do only the tabs close and you can restore the chat from history?
  • Roughly how many messages are in the chat when this happens?
  • Can you reproduce it every time, or does it happen only sometimes?

This will help us understand the scope and pass it to the team with details.

4

I can restore from history. I don’t know how many messages maybe 20? It feels like a built in optimisation that’s just annoying rather than an unintended bug but it is essentially a bug given how ass the ux is It happens consistently

1 Like
5

It’s clear this gets in the way of working, especially when you’re juggling multiple agents at once.

Thanks for clarifying. It really looks like some optimization that kicks in at around 20 messages. The fact that it happens consistently and predictably supports your suspicion.

I’ll pass this to the team. This is important feedback that this behavior adds friction to a real workflow. The chats stay in history, but having to restore them all the time is clearly not how it should work for productive work.

Let me know if you notice any patterns, like whether it depends on message type or the size of the agent’s replies.