Windows 3.21.18: theme, recent folders and chats appear reset after full exit/restart

[xin_the (thexin7)]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

After the automatic update from 3.21.16 to 3.21.18, reopening Cursor after closing all windows intermittently looked like a fresh installation: my custom dark/purple theme and layout were missing or substantially different, earlier recent folders were missing from the Windows taskbar jump list, and previous chats were not visible as expected.

Restarting temporarily restored the old state, but the problem recurred after another full close/reopen. This interrupted work and looked like data loss.

Local investigation found that settings.json still contained the original color settings, and the existing database still contained six recent-project entries and previous conversation bodies. SQLite PRAGMA quick_check returned “ok”. A before/after recovery comparison found no missing records among 596 existing conversation-related records (25 composerData records, including possible drafts, and 571 bubbleId records), with no changes to those 571 existing bubble records.

Therefore this is apparent data loss / state loading or restoration failure; permanent deletion of those records was not established. The root cause remains unresolved.

Steps to Reproduce

Observed sequence on September 23, 2026:

1. Use Cursor 3.21.16 with multiple local project windows, existing chats and custom workbench colors.
2. Let the automatic update download in the background.
3. Close all Cursor windows, then reopen Cursor after the update to 3.21.18 applies.
4. The UI/theme and recent-project/chat presentation appear reset.
5. Restarting can temporarily restore them, but another full close/reopen can trigger the problem again.

This is not a guaranteed minimal reproduction: some controlled exit/relaunch tests on 3.21.18 succeeded. The issue is intermittent or depends on startup conditions that have not been isolated.

Expected Behavior

Retain the existing theme/layout, recent projects, and chat history consistently across updates and full restarts, without making the installation look reset while the original data remains on disk.

Operating System

Windows 10/11

Version Information

Windows x64, version 24H2, OS build 26100.8457. Cursor stable per-user installation. Previously working: 3.21.16. Affected automatic update: 3.21.18. Current workaround: rolled back to signed 3.21.16 installer.

Additional Information

Update timeline (September 23, UTC+08:00): download started around 01:27; silent installer prepared the update around 01:28-01:29; application replacement completed after Cursor exited around 09:50.

Shutdown log clue, with the personal path redacted:
CodeExpectedError: ENOPRO: No file system provider found for resource ‘file:///REDACTED_USER_PROFILE/AppData/Roaming/Cursor/User/globalStorage/storage.json’

The same error also appeared before a successful recovery, so it is not proof of the cause.

Workaround after backing up current data:

• Reinstalled the signed 3.21.16 application while retaining current user data (did not restore an old user database).
• Set update.mode=“manual” and update.enableWindowsBackgroundUpdates=false.
• Set window.restoreWindows=“all” and startup preference to last-used project windows instead of default.

The theme and old chats, including chats created on the incident day, returned. One full exit/cold-relaunch cycle was visually verified. A second full exit/relaunch was initiated and data/settings checks passed, but its visual inspection was not completed. Normal use currently appears restored. Since the version and startup preferences changed together, the exact cause is not isolated; I have not re-upgraded to deliberately reproduce it again.

Please investigate the Windows update / first-window / profile and workspace restoration path. Is this a known 3.21.18 issue? Please provide a fixed version or supported recovery procedure preserving current data, and advise which targeted diagnostics are needed. I would like to resume updates safely instead of staying on an older version with automatic updates disabled.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

[deanrie]

Hey, thanks for the detailed report and for checking the database before panicking. The data is indeed there, nothing was lost.

What you saw was most likely not a reset IDE, but the Agents Window. When Startup is set to Default, if you quit Cursor while there are no editor windows open, the next launch opens the Agents Window instead of restoring your project windows. On Windows, closing all windows one by one is exactly that case. The Agents Window has its own theme and UI, plus a different view for chats and projects, so it can look like a fresh install even though settings.json and state.vscdb were not touched. This is not related to 3.21.18 either. This startup behavior existed in earlier versions too.

The change you already made is the right fix. Cursor Settings > General > Startup > Window Restoration > Last Used Windows makes Cursor restore your previous project windows every time. With that setting, you can safely update to the latest version and turn auto-updates back on. window.restoreWindows="all" is already the default, so you can keep it or remove it.

If you want to confirm it, temporarily set Window Restoration back to Default and try this:

1. Open one of your projects in the editor.
2. Close that window with the X so no Cursor windows are left open.
3. Launch Cursor again from the Start menu or taskbar.
4. You should land in the Agents Window. Then go to File > Open IDE or use Ctrl+Shift+N. Your theme, recent folders, and chats should still be there.

If you ever see a reset while Last Used Windows is enabled, or inside a normal editor window, post your Cursor version from Help > About and a screenshot of that window and we can dig deeper.

[xin_the (thexin7)]

Thanks for the explanation. There has been another recurrence today, so I need to correct the earlier impression that the rollback had resolved it.

The reset-looking state recurred on 3.21.16 after the rollback. At the time of inspection, the installed version was still 3.21.16, and these settings remained on disk:

{
  "update.mode": "manual",
  "update.enableWindowsBackgroundUpdates": false,
  "window.restoreWindows": "all"
}

The application database also still contained:

• cursor/userWindowRestorationPreference = lastUsedWindows
• Six original recent-project entries
• 25 composerData records and 571 bubbleId records; PRAGMA quick_check returned ok

For transparency: the restoration preference was written to the existing application database while Cursor was stopped, using the keys/values found in the installed application’s setter. I have not yet captured what the Startup settings UI showed in the abnormal window, so I cannot claim that its runtime had loaded the same value. That discrepancy may be important.

New diagnostic difference (September 23, UTC+08:00):
The affected session’s main.log identifies version 3.21.16 and records:

17:09:45.984 [info] update#setState checking for updates
17:09:46.227 [info] update#setState downloading

However, the settings.json above still existed unchanged from 15:30. By comparison, a subsequent explicit launch using --classic --user-data-dir="[existing %APPDATA%\Cursor directory]" --log trace recorded:

17:11:11.523 [info] update#ctor - manual checks only; automatic updates are disabled by user preference

That explicit launch reopened the four original project windows, and the UI accessibility tree showed the prior chat tabs and the previous day’s conversation. No older database was copied back. The abnormal session had already been closed before inspection, so I do not have a screenshot of its window type or its runtime configuration.

Your Agents Window explanation is a useful lead, but could you please clarify whether it uses a different configuration/profile scope for startup and update preferences? How can we verify why the normal and abnormal launches appear to honor different settings while the existing files remain intact?

As an additional temporary measure, the normal shortcuts now explicitly pass --classic, the existing user-data directory, and --disable-updates. This is not yet proven to prevent recurrence. I am not marking the issue solved or re-enabling automatic updates at this point. Please advise the exact targeted diagnostics needed if it happens again; repeated apparent data loss is still disrupting normal use.

[xin_the (thexin7)]

Clarification: the scope is the entire user environment appearing reset, not just a missing Agent chat list or a different window theme. During the failure, it feels as though all my user data and account/user context are gone, as if this were a fresh installation. Personal settings, theme, project history and conversations become unavailable together. Even the Windows taskbar right-click Recent Folders list loses the previous projects. Please investigate this as a profile-wide state problem, rather than assuming it is only unfamiliarity with the Agents Window.

Finding some intact database records afterwards does not prove that every piece of user/account state was intact or loaded correctly during the failed session. I am describing the user-visible loss of the whole environment; I am not asserting that the server-side account was deleted. A failure-time screenshot of the account panel has not yet been captured, so actual sign-out is not independently verified.

Additional controlled tests on 3.21.16 today (UTC+08:00):

1. At 17:31, a normal launch with only extra trace logging also succeeded. In the live General settings UI, the account offered Log Out, and Window Restoration = Last Used Windows. Thus this preference is now verified in the running, recovered application, not only in SQLite.
2. I deliberately opened a separate Agents Window for comparison. It still showed my account name, original repositories and several previous conversations. That normal Agents Window did not reproduce the profile-wide disappearance I am reporting. This does not rule out a startup-specific Agents Window problem, but the ordinary layout difference alone is not a sufficient explanation.
3. I fully quit Cursor, confirmed zero Cursor processes, then relaunched through the taskbar shortcut with --classic --user-data-dir="[original user data directory]" --disable-updates. The actual process arguments matched, and the 17:36 session logged update#setState disabled and updates are disabled by the environment.
4. After that cold launch, the account’s Log Out button, Last Used Windows, old conversation tabs and a message from the previous day were still present. Six recent folders and all 571 previously counted bubble records remained in the database; the structural check passed. The composerData count increased from 25 to 27 during testing, which may include new empty-window drafts.

Recovery procedure: back up the current state; keep the existing database rather than overwrite it with an older backup; explicitly load the original user-data directory/editor mode; then verify the running UI, launch arguments and database. This has restored access temporarily. A successful test does not establish a permanent fix, especially given the repeated recurrences.

The failure itself is still not reliably reproduced during these controlled tests. Please advise how to capture the effective runtime profile/data directory, account state and loaded settings during the next failure, ideally before closing or restarting anything. I need a reliable root-cause investigation, not repeated resets or reinstalls. The earlier difference between configured manual updates and an abnormal session automatically downloading an update also remains unexplained.

Installation/path cross-check: there is only one registered Cursor installation (3.21.16, per-user), and the taskbar/Desktop/Start menu shortcuts plus the cursor CLI point to that same executable. An older application directory and an older user-data directory are backups; no observed process was launched from them. The known project associations all use the default profile, and no User/profiles subdirectory was found. Both abnormal and successful sessions wrote logs under the same Cursor user-data root. This does not establish whether the abnormal runtime loaded the same effective settings/account state, but there is currently no evidence of two active installed copies causing the problem.

[deanrie]

Thanks for the detailed correction, got it. You’re right that a simple explanation like “it’s just the Agents Window” doesn’t cover what you described. If an explicitly opened Agents Window shows the account, repositories, and old chats, and the profile-wide disappearance can’t be reproduced at the same time, then it can’t be explained by a layout difference alone. So I’m not treating that as the final answer anymore.

The problem is that we, like you, still don’t have data from the actual failing session. All successful and recovered launches show Last Used Windows and a complete database, but we didn’t capture what the runtime actually loaded at the moment of the anomaly. Without that, we can’t isolate the root cause. So the most valuable thing now is to capture diagnostics right at the next failure, before closing anything or restarting.

If it happens again, in the broken window, without closing anything:

1. Take a screenshot of the full window. It’s important to see the window type, normal IDE or Agents Window, and the account panel, whether it shows Log In or Log Out, and whether the account name is visible.
2. Open Cursor Settings (not VS Code settings) > General > Startup and screenshot what Window Restoration is actually set to in that session, Default or Last Used Windows. This will answer your question about different effective settings.
3. In Task Manager > Details, find the Cursor process, enable the Command line column, and screenshot the full launch argument, including the actual --user-data-dir.
4. Save main.log from that session before closing it. Help > Toggle Developer Tools also works, but the log is the priority.
5. Help > About, record the version.

This will give us the effective runtime profile and data-dir, the account state, and the settings that were actually loaded at failure time. That’s exactly what we’re missing right now to tell “state load issue” apart from “routing into a different window.”

On the point that 3.21.16 downloaded an update while update.mode="manual" and background updates were disabled, that’s a separate symptom. It’s better to track it separately so it doesn’t get mixed with the reset issue. If you want, open a separate thread for it, or tell me here and I’ll help split it out, along with the two lines from main.log and the contents of settings.json from that time.

Once you have failure-time materials, post them here and we’ll dig in with real data.

[rennokki]

Can Cursor just stop overriding shortcuts after updates? My ^ + Space shortcut for toggling suggestions moved to ⌥ + Space after latest update.

[deanrie]

@rennokki, this is a separate issue from what’s being discussed in this thread (that one is about restoring windows and state), so let’s move it into its own thread. That makes it easier to track and avoids mixing two different symptoms. Can you create a new one in Bug Reports? I’ll pick it up.

Quick workaround for now: open Keyboard Shortcuts Ctrl/Cmd+K, Ctrl/Cmd+S, find the toggle suggestions command, and reassign it back to Ctrl+Space. Manual bindings are stored in keybindings.json and persist across updates, so the default shouldn’t overwrite them anymore.

In the new thread, please include your OS, your Cursor version (Help > About), and whether this shortcut was custom or the default before the update. That’ll help narrow down what changed.