Work history auto-collapse (v 3.14+)

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

New Cursor version broke the chat history: “Worked for ..” auto collapses on follow up prompts. This happens in any Cursor Settings → General → Layout → Conversation Density settings.

It is a major productivity killer because the agents cannot get anything done at the first try and I always have to follow up with fixes just to loose the work and then have to scroll up and down just to hit the scroll bug. So, please just remove the new mandatory auto-collapse feature.

Steps to Reproduce

  1. Ask agent to do any work.
  2. Once agent finishes work you can observer the diffs in the Chat.
  3. Ask a follow up questions or any prompt for that matter.
  4. All diffs and work disappear under the “Worked for …”

Expected Behavior

Old Cursor behavior was great: no auto-collapse.

Screenshots / Screen Recordings

Operating System

MacOS

Version Information

Version: 3.14.7
VS Code Extension API: 1.128.0
Commit: a758f2241ca99fecf380180b6cbdbbce0f1f42c0
Date: 2026-07-30T06:41:34.009Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.291
OS: Darwin arm64 25.5.0

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

Hi @Adnan_Boz, Thanks for the forum post! This is a deliberate change as agents do more work for users and work for longer, and we are looking to make it easier for users to review their output. That being said, prior work isn’t gone. It’s just one click away.

After a follow-up, the previous turn folds under the “Worked for …” header. Click that header to expand it. It stays open for the rest of the session.

Conversation Density only changes how edits and terminal output group inside a turn. It does not stop completed turns from folding. Similar post here but essentially covers the same topic: Not being able to see what the agent is doing is making me nervous

Hi Kevin, thank for the follow up.
I think the core issue here is working memory and context relevance. Recent chat history should be treated as active working context.

There is actually research that maps fairly well to this. Nelson Cowan’s paper, “The Magical Number 4 in Short-Term Memory,” argues that the active capacity of short-term memory is roughly four chunks. In a coding session, the last few interactions are therefore often not really “history.” They are still part of the current unit of thought.

There is also Pirolli and Card’s Information Foraging Theory, which essentially says that people trade off the value of information against the cost of retrieving it.

That suggests a pretty simple design principle:

access cost should increase as expected relevance decreases.

The last 3 to 4 interactions should be immediately visible. Older history can be progressively compressed. After roughly 10 interactions, compact it. After roughly 30, collapse it further. If I’m digging through something from 30 commands ago, clicking around is perfectly reasonable.

But making me navigate to see something from two interactions ago is backwards. That is still active context.

In a coding environment, the conversation is effectively part of the developer’s external working memory. So recent context should be effortless to access, while older context can progressively require more effort.

Thanks,

Adnan

please fix the UI and UX for this its main reason we use IDE and not your weird codex clone