Files zeroed + Local History rewritten empty on startup — 3.23.12, macOS, no force-quit (25 events, 5016 empty snapshots sourced "Undo Create Diff")

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Following @deanrie’s guidance in
“Files are overwritten with zero length at startup”
(Files are overwritten with zero length at startup)
to open a new thread for the separate, still-tracked case: files zeroed and
Local History snapshots rewritten as empty, on a version newer than 3.15.6.

Environment

  • Cursor: 3.23.12 (stable), auto-update on
  • OS: macOS, Darwin 25.6.0, Apple Silicon (arm64)
  • 2 affected workspaces (both multi-package repos):
    • ~/code/NuanxinjiaProjects/nanochap-flutter
    • ~/code/architecture-templates
  • No enterprise hooks. Only notification-only user hooks in ~/.cursor/hooks.json
    (they make an HTTP call to a local port and do not write workspace files).

Answering the 3 questions

  1. Right after updating, or a normal cold start?
    Both. The update restart v3.22.12 → v3.23.12 at 2026-10-02 21:20 was followed by a
    363-file wipe. It then also fired on plain cold starts with no update at all:
    2026-10-03 12:51 (406 files) and 2026-10-03 17:09 (209 files).
    The update to 3.22.12 at 2026-09-29 10:50 was likewise followed by a 208-file wipe.

  2. Was there a freeze/hang on startup that forced a force-quit?
    No. Zero crash / SIGKILL / force-quit markers in the session logs, and no equivalent
    of Task Manager was used. This is unattended destruction during a normal startup.
    It therefore looks distinct from the original #166244 scenario, which required
    killing the process during the save storm.

  3. Unresolved agent edits pending when closing?
    I cannot prove this directly from logs, but the Local History attribution is strong
    indirect evidence: of 5016 empty snapshots, 4575 are tagged
    "source": "Undo Create Diff". No agent Write/Delete tool call and no shell
    truncate command can be attributed to any of these events.

Evidence 1: Local History is written with empty revisions, sourced “Undo Create Diff”

Scanning ~/Library/Application Support/Cursor/User/History/*/entries.json:

  • total Local History entries … 12295
  • entries with size <= 1 byte … 5016
  • of those, source = "Undo Create Diff" . 4575 (91%)
  • of those, exactly 0 bytes … 1426
  • of those, exactly 1 byte … 3590

Evidence 2: 25 mass-wipe events over 17 days

Same-minute clusters of >= 5 wiped files. The wiped set is ~208-210 files, and the
same files get re-emptied across many startups:

    2026-09-17 22:52     6
    2026-09-18 10:53     6
    2026-09-19 20:59     6
    2026-09-19 21:03     6
    2026-09-20 10:41   412
    2026-09-20 11:00   222
    2026-09-21 10:26   222
    2026-09-22 10:26   222
    2026-09-23 11:47   210
    2026-09-23 22:11   210
    2026-09-24 10:04   210
    2026-09-24 21:58   210
    2026-09-24 23:40   210
    2026-09-26 15:12   209
    2026-09-26 15:29   209
    2026-09-29 10:45   210
    2026-09-29 10:50   208
    2026-09-30 10:56   210
    2026-09-30 22:08   210
    2026-10-01 02:42   210
    2026-10-01 17:11   210
    2026-10-02 21:13   210
    2026-10-02 21:20   363
    2026-10-03 12:51   406
    2026-10-03 17:09   209

Version context: these span 3.22.12 and 3.23.12 (updated 2026-09-29 10:50 and
2026-10-02 21:20 respectively). Two of the events sit exactly at update-restart time;
the rest are ordinary cold starts.

Evidence 3: it happens ~1-2s after the window is ready, with no user action

Session logs/20261003T170919, main.log (UTC), affected files mtime (local, +08:00):

main.log:
  17:09:19.578  [RendererPing] enabled
  17:09:19.585  updateURL ... cursor/3.23.12
  17:09:20.250  [LocalAgentStorage] Scanned 2 recent databases ...
  17:09:21.121  [Tray] Menu bar visibility: unknown -> visible
filesystem:
  104 files -> 2026-10-03 17:09:22
   10 files -> 2026-10-03 17:09:23

Same on 2026-10-03 12:51 (logs/20261003T125117): window ready 12:51:19.043,
damaged files mtime 12:51:19.

Measured damage

  • 2026-10-03 17:09 (architecture-templates, main): 107 tracked files damaged
    (23 at 0 byte, 84 at 1 byte). No uncommitted work lost — all recoverable from HEAD.
  • Earlier event (nanochap-flutter): 87 tracked files emptied; diff was +4 / -59254 lines.

Why this is a problem

  • git restore fixes files on disk but does NOT clear the pending diff state that
    re-triggers the wipe, so the same ~208-file set gets zeroed again on a later launch.
  • Files not yet committed, and their Local History, are both destroyed; recovery can
    depend entirely on Local History still holding a non-empty revision.
  • Silent, unattended, no confirmation, no undo.

Ask

  1. Is this the “separate issue” you mentioned, and is there any ETA or tracking ID?
  2. Is there a setting/flag to disable the startup re-save / undo of pending edits
    as a stopgap?
  3. I can provide the full Local History archive and session log dirs on request —
    please tell me where to upload.

Steps to Reproduce

open The Cursor IDE

Operating System

MacOS

Version Information

Version: 3.23.12
VS Code Extension API: 1.128.0
Commit: 2d29876d567da1607532b23bbf2cd5ddbca496f0
Date: 2026-10-01T04:41:16.627Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 42.10.0
Chromium: 148.0.7778.280
Node.js: 24.18.1
V8: 14.8.178.38-electron.0
xterm.js: 6.1.0-beta.291
OS: Darwin arm64 25.6.0

Does this stop you from using Cursor

No - Cursor works, but with this issue

6

Hey, thanks for such a detailed write-up. The logs, timestamps, and event-by-event breakdown really help.

Yep, this is the separate issue Dean mentioned. It’s known, we’re tracking it, and I’ve added your report plus the timeline, including that it triggers on normal cold starts and not only after updates, and that it reproduces on 3.23.12 without a force-quit. I can’t share an ETA yet. There’s currently no separate setting to disable this startup restore, and files.autoSave / files.hotExit don’t affect it.

What’s happening is Cursor stores “pending review” records for agent edits that were never accepted or rejected. Those records live in Cursor’s own storage, not in git. That’s why git restore fixes the files on disk, but the records remain and get re-applied on the next launch. That’s also why you see the same roughly 210-file set on every startup.

To break the loop:

  • Open Review Changes in both workspaces and click Keep All, not Undo All. Wait until the list is empty.
  • Quit Cursor via Cmd+Q and make sure no Cursor processes are still running.
  • Back up the storage file:
    cp ~/Library/Application\ Support/Cursor/User/globalStorage/state.vscdb* ~/Desktop/
  • Delete the remaining pending review records:
    sqlite3 ~/Library/Application\ Support/Cursor/User/globalStorage/state.vscdb "DELETE FROM cursorDiskKV WHERE key LIKE 'inlineDiff%';"
  • Run git restore . in both repos.
  • Launch Cursor, wait about 10 seconds, then run git status. The files should stay untouched.

Step 4 clears all pending agent reviews across all workspaces. Your on-disk files stay as-is. You only lose the Keep/Undo overlay state. Keep the backup from step 3 in case anything looks off.

Optional, but it would really help. Before step 4, run this and send back the number it prints. It only counts records and won’t show any code:

sqlite3 ~/Library/Application\ Support/Cursor/User/globalStorage/state.vscdb "SELECT COUNT(*) FROM cursorDiskKV WHERE key LIKE 'inlineDiff:%' AND (value LIKE '%\"originalTextLines\":[]%' OR value LIKE '%\"originalTextLines\":[\"\"]%' OR value LIKE '%\"originalTextLines\":[\"\",\"\"]%');"

For now, please hold off on sharing the Local History archive and session logs here since they contain your code. If the team needs them, we’ll reach out privately and share where to upload.

This shouldn’t happen, and it’s not caused by anything in your settings. Let me know how the loop-breaker goes.