Archiving chats overwrites last-updated timestamp and breaks archive order

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Where does the bug appear (feature/product)?

  • Editor, Tab & Chat (Agent sidebar / chat archive)

Describe the Bug
Archiving a chat (or bulk-archiving many chats) overwrites the chat’s last-updated / recency timestamp with the time of the archive action.

The archive list then no longer sorts by last real conversation activity (last user or assistant message). After a bulk archive, dozens or hundreds of chats share the same timestamp, so the archive order becomes effectively random / meaningless. Finding the chats you actually used recently is hard.

This is not just a UI sort quirk. The stored recency fields (lastUpdatedAt / recency in composer headers, and updated_at in the conversation search index) are rewritten. The last-message checkpoint (conversationCheckpointLastUpdatedAt / last bubble time) stays correct — only the “freshness” used for sidebar/archive ordering is mutated.

Related (different trigger, same class of bug):

Steps to Reproduce

  1. Open a workspace with a long Agent chat history (many chats from different days).
  2. Note a chat whose last real message is several days old.
  3. Archive that chat (or select many chats and archive them together).
  4. Open Archived.
  5. Observe that the archived chats now sort as if they were updated at the archive moment, not at the last message.
  6. Optional check: after a bulk archive, many unrelated chats share the exact same last-updated timestamp (same second).

Expected Behavior
Archiving / unarchiving should change only the archived flag.
Last-updated / recency used for sidebar and archive ordering should stay equal to the last real message (user or assistant), not the time the chat was moved to archive.

Screenshots / Screen Recording
N/A. Repro is the archive sort order after a bulk archive.

Operating System & Cursor Version
Version: 3.17.8
VSCode Version: 1.128.0
Commit: 2fdd31c9f33f7fbe501f2d57772dc5bf64b63620
Date: 2026-08-20T02:18:12.724Z
OS: Windows_NT x64 10.0.20348

Additional context

  • Reproduced on a local Windows workspace with ~100 archived Agent chats.
  • After one bulk archive, lastUpdatedAt and recency for those chats were all set to the same archive timestamp (2026-08-21 11:34:22 local), while last-message checkpoints still ranged from July through the same morning.
  • Request ID: not applicable (no model request; this is local sidebar/metadata behavior).

Steps to Reproduce

  1. Open a workspace in Cursor Agents (desktop app, not CLI / not Cloud Agent) that already has many Agent chats from different days.
  2. Note one chat whose last real message is several days old. Remember its place in the list / its recency.
  3. Archive that chat. Or select many chats and archive them together.
  4. Open the Archived section in the Agents sidebar.
  5. The archived chats now sort as if they were updated at the archive time, not at the last user/assistant message.
  6. After a bulk archive, many unrelated chats share the exact same last-updated timestamp (same second), so archive order becomes meaningless.

Operating System

Windows 10/11

Version Information

Version: 3.17.8 (user setup)
VS Code Extension API: 1.128.0
Commit: 2fdd31c9f33f7fbe501f2d57772dc5bf64b63620
Date: 2026-08-20T02:18:12.724Z
Layout: Agent Window
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: Windows_NT x64 10.0.20348

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey, thanks for the super detailed report. You described the behavior exactly, down to the fact that the last-message checkpoint conversationCheckpointLastUpdatedAt stays correct, and only the freshness field gets overwritten, which is what the Archived list is sorted by.

I can confirm that’s what’s happening. When you archive a chat, the chat’s last-updated field gets updated, and Archived is sorted by that, so the order becomes the time you archived things. After a bulk archive, chats can also end up with the same timestamp. The key point is this doesn’t affect the actual time of the last message. That’s stored separately, so nothing is lost. What we need to fix is the sorting.

I’ve passed this to the team. I can’t share a timeline yet, but I’ll post here when there’s an update.