Agent sidebar: reopened workspace bumps thread “last updated” time when editing-session tab restores

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

（日本語話者で英語があまり分からないため、Composer2に翻訳/Translateを手伝ってもらっています）
When I reopen a workspace, an Agent/Composer thread that was left open from a previous session (especially one where the Agent edited files) shows an updated sidebar timestamp / “Today” grouping at the reopen time, even though I did not send any new messages.

This seems tied to the conversation tab being restored on startup (UI restore), not to new chat activity.

Impact: I cannot use Git in this environment, so overwriting “when this consultation happened” metadata in the sidebar is a real workflow problem.

Steps to Reproduce

  1. Open a local folder workspace in Cursor via Open Folder (my shortcut: Ctrl+M+O). No SSH/WSL.
  2. Open the Agent sidebar and start/switch to an Agent conversation.
  3. Ask the Agent to modify source files in the workspace so edits/checkpoints occur.
  4. Leave that Agent/Composer conversation tab open.
  5. Close Cursor completely or close the workspace normally.
  6. Reopen the same workspace without typing/sending anything new in that thread.
  7. Check the Agent sidebar list: the restored thread moves to ~now / “Today” even though nothing new was sent.

Expected Behavior

Sidebar timestamps/grouping should reflect real conversation activity (last actual message/editing turn), not “workspace reopened / tab restored”.

Operating System

Windows 10/11

Version Information

Cursor Version: 3.2.11 (system setup)
VS Code Version: 1.105.1
Commit: e9ee1339915a927dfb2df4a836dd9c8337e17cc0
Date: 2026-04-24T14:36:47.933Z
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: Windows_NT x64 10.0.26200

For AI issues: which model did you use?

Any / not model-specific

Additional Information

Repo contains .claude/settings.json (Claude tooling) only; unrelated to Cursor window restore. I’m not knowingly customizing Cursor window.restoreWindows-adjacent settings in User settings.
Git is unavailable in my environment (cannot substitute commit timestamps for workflow tracking).

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey, thanks for the detailed report. The repro steps, version, and description of the workflow impact really help.

This looks like an issue with how the sidebar updates a thread timestamp when restoring a tab on workspace startup, especially for threads where Agent has already edited files.

A few quick questions while I’m digging in:

  1. If you start Cursor with extensions disabled using cursor --disable-extensions in Terminal and repeat the steps, does the sidebar timestamp still shift?
  2. Do you have any custom values in User Settings for window.restoreWindows or workbench.editor.*? If you’re not sure, you can share your settings.json with any secrets removed.
  3. If you open the same thread manually after reopen, not via the auto-restored tab, does the timestamp bump, or only when the thread is restored automatically?

Let me know on these and we’ll figure out next steps.

8

（この文章はComposer2を使って日本語->Englishに翻訳/Translateしています）

Hi Dean,

Thanks again for the follow-up questions. Here’s a consolidated update with everything on one page.

  1. cursor --disable-extensions

I reproduced the issue with cursor --disable-extensions. The sidebar timestamp / “Today” grouping behavior still mis-updates on workspace reopen — so it does not appear to be explained by third-party extensions alone.

I also see the same kind of unexpected filesystem “last modified” behavior (see section 5) under --disable-extensions.

  1. User settings (window.restoreWindows, workbench.editor.*)

I do not have custom values for window.restoreWindows nor keys starting with workbench.editor.*.

My User/settings.json currently contains only the following (no secrets):

{
“window.commandCenter”: true,
“files.associations”: {
“.tpl": “html”,
".cls”: “php”,
“*.inc”: “php”
},
“workbench.colorTheme”: “Solarized Light”,
“claudeCode.preferredLocation”: “sidebar”,
“claudeCode.selectedModel”: “default”
}

(Repo-level .claude/settings.json exists for Claude tooling only; unrelated to Cursor window restore.)

  1. Restored tab hypothesis

My earlier mental model was “only when an Agent/Composer tab is auto-restored”, but in practice I’m also seeing misleading recency when a thread was not left open at quit (e.g. used yesterday, kept closed afterward, then reopened the workspace). So it doesn’t look strictly limited to “restored tab hydration” only.

  1. Environment / version

Cursor Version: 3.2.11 (system setup)
VS Code Version: 1.105.1
Commit: e9ee1339915a927dfb2df4a836dd9c8337e17cc0
Date: 2026-04-24T14:36:47.933Z
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: Windows_NT x64 10.0.26200

Workspace: local folder opened via Cursor “Open Folder” (shortcut: Ctrl+M+O). No SSH/WSL.

Workflow impact: Git is not available in my environment, so I can’t substitute commit history for “when something was last touched,” which makes accurate UI metadata and trustworthy file mtimes important.

  1. Additional observation: extra restored tabs + file mtimes

In at least one repro, before quitting I tried to leave only one Agent-side context, but after restart Cursor reopened several Agent/Composer tabs (~4) that I did not expect.

Also, some source files associated with threads I did not intend to have “active” showed updated Windows “last modified” times after restart. On quick comparison, the file contents looked unchanged (no obvious substantive diff to me) — mainly the mtime looked suspicious.

Happy to provide a redacted short screen recording / redacted relative paths if helpful.

  1. “Copy Request ID” IDs (per thread)

All UUIDs below were obtained via “Copy Request ID” from the thread while that tab was open, except where noted.

Shown / foreground threads:

  • “Cursorでのタイムスタンプ変更問題”: fa7d408a-56c7-4071-9369-50a677b859a0
  • “New Agent”: No request ID found
  • “Vinurse4 TPL known bug investigation”: 73e71f2e-f3e2-4306-9cb3-7cec69897b9f
  • “Copy button behavior with temporary save”: 8d717eff-630f-47e8-aa08-0cca999fcc6d

The thread where I observe the timestamp / recency issue (including when it isn’t the focused tab) is:

  • “得意先売上のバリデーション実装状況”: 8d5418e5-fdcc-47bf-aacd-d5add9ea422a

Let me know what you’d like next (logs, recording, or a tighter repro script). Happy to help narrow it down.

Best regards,
■■■■■■■■■ T

9

Thanks for the detailed follow-up. Reproducing with --disable-extensions and a clean settings.json helps a lot. That rules out extensions and your custom settings as the cause, which really narrows things down.

It also helps that you expanded the scope. If the timestamp is also updating for threads that were not left open when you quit, then this is not just about hydration of restored tabs. I’ll add that to the internal report so the investigation looks beyond the tab restore code path.

One small request about item 5 (extra restored tabs plus file mtime changes with no content differences). This looks like it could be a separate issue with a different root cause. To avoid mixing tracking and to make sure it gets proper attention, could you file a separate bug report for that? Ideally include:

  • A short description of the extra tabs behavior, like how many tabs you expected vs how many you got, and whether they were pinned or unpinned when you quit
  • A few examples of relative paths where mtime changed but the content did not
  • A short screen recording if it’s easy to capture

A recording or paths that include edits is also fine, whatever is more comfortable for you.

For the sidebar timestamp issue, you don’t need to send anything else for now. What you’ve shared is enough. If the team needs anything more specific, I’ll message you here. No ETA yet, but we’ll reply in this thread as soon as we have an update.

10

Hi Dean,

Quick update:

Last night I was still seeing the odd behavior where Agent/Composer tabs I hadn’t interacted with appeared on reopen, sometimes alongside suspicious filesystem mtime changes despite content looking unchanged.

This morning when I reopened Cursor, it came back exactly to last night’s layout (same tab set + Claude Code extension in the sidebar) and everything looked normal — the unexpected extra tabs didn’t reproduce, and I also didn’t see the mtime-only file timestamp issue.

Given that it seems intermittent/flaky on my machine, I don’t think I’ll file the separate forum thread for item 5 right now. If/when it happens again under clearer conditions (expected vs restored tab counts + a few reproducible paths), I’ll open a dedicated bug report and include the specifics you outlined.

Separately — thanks again for escalating the sidebar timestamp investigation; that part was very helpful context for us.

Thanks Again.
■■■■■■■■■ T

11

Hey, thanks for the update, and no worries about pausing the item 5 report. Intermittent issues that don’t reproduce reliably are tough to act on, so starting a dedicated thread later with clear repro steps is the right move. If it shows up again, please capture whatever you can at the time like expected vs actual tab counts, a few relative paths with mtime-only changes, and a short recording if it’s easy, then open a new thread. I’ll take it from there.

For the sidebar timestamp issue, it’s logged on our side with all the context you shared. No ETA yet, but I’ll reply here when there’s an update.