Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
Mass file truncation to 0 bytes on first launch after auto-update (macOS)
Summary
On the first launch following a Cursor auto-update, ~200 recently-modified files
across my workspace trees were truncated to 0 bytes, roughly 3 seconds after
startup. This has now happened twice, on two consecutive updates. Files that were
NOT open in any editor were destroyed. There is no user action involved — it
happens unattended during startup.
Environment
- macOS 26.5.2 (darwin 25.5.0), Apple Silicon, darwin-universal build
- Cursor versions involved: 3.14.7 → 3.14.27 → 3.15.6 (stable channel)
- Auto-update enabled (default;
update.modenot set) - Workspace roots include
~/agentic-dev(multi-repo),~/SecondBrain,~/.cursor
Impact
| Incident | Session start | Version at launch | Files zeroed | Wipe timestamps |
|---|---|---|---|---|
| 1 | 2026-08-06 08:54:55 | 3.14.27 (was 3.14.7) | 208 | 08:54:58 and 08:54:59 |
| 2 | 2026-08-07 13:11:14 | 3.15.6 (was 3.14.27) | 213 | 13:11:17 and 13:11:19 |
159 files were hit in both incidents. Files were destroyed in two waves about two
seconds apart. 43 of the affected files were not committed to git and existed only
in Cursor’s local history — had that history rotated, the data would be
unrecoverable.
Reproduction correlation
The trigger is specifically a version change between sessions, not startup in
general. Across six consecutive sessions:
| Session start | Version | Outcome |
|---|---|---|
| Aug 3 08:33 | 3.14.7 | clean |
| Aug 6 08:44 | 3.14.7 | clean |
| Aug 6 08:52 | 3.14.7 | clean |
| Aug 6 08:54 | 3.14.27 (changed) | 208 files zeroed |
| Aug 7 08:18 | 3.14.27 | clean |
| Aug 7 13:11 | 3.15.6 (changed) | 213 files zeroed |
2/2 post-update launches caused damage. 4/4 same-version launches did not.
Forensic detail
- Truncated in place: affected files retain their original inode and birth
time;mtime==ctime== the wipe second. Consistent withopen(O_TRUNC)
followed by close with no write, not a delete-and-recreate. - Not open in editors: I extracted the persisted editor list from
workspaceStorage/<id>/state.vscdb
(memento/workbench.editors.files.textFileEditor) and cross-referenced it
against the 213 victims. Zero overlap. These were not open tabs, so this is not
hot exit, backup restore, or autosave of an empty buffer. - Victims skew to recently-modified files: median 0 days since last
modification, versus 84 days for the ~900 other files Cursor tracks local
history for and did not touch. This suggests a startup path that enumerates
recently-changed files. - Scoped to workspace trees: all 213 files were under
~/agentic-dev,
~/SecondBrain, or~/.cursor. Nothing elsewhere in the home directory was
affected, despite~itself being a known workspace root. - Cursor’s own local history recorded the 0-byte state, producing empty
snapshot entries timestamped at the wipe second.
Ruled out
- System crash / power loss / APFS unflushed writes — the machine had been
continuously up since Aug 6 08:46, so the Aug 7 incident involved no reboot.
No kernel panic reports exist. - Hot exit / tab restore / autosave — see editor-state cross-reference above.
- User hooks, scripts, or scheduled jobs — audited; nothing writes arbitrary
file lists, and no job ran near either timestamp. - The
composer-header-tablemigration — it logs in every session including
all four clean ones. - Endpoint security software (Defender/Purview DLP, Cylance, Arctic Wolf are
installed) — none of these correlate with Cursor version changes, and device
control is in audit-only mode.
Relevant log excerpt
From logs/20260807T131114/window1/renderer.log, immediately surrounding the
first truncation wave at 13:11:17:
13:11:16.590 [info] [composer-header-table] migrate gate=on claimed=false blob=1547 table=2325 missing=0 extra=778
13:11:17.058 [info] Started local extension host with pid 64308.
13:11:17.162 [error] [002] potential listener LEAK detected, having 200 listeners already.
13:11:17.175 [error] [002] potential listener LEAK detected, having 300 listeners already.
The Backups/<workspace-hash>/file/ directory mtime also updated to 13:11.
What I have not established
I could not capture the write syscall itself — the macOS unified log requires
root and was not being captured at the time. So this is a perfect correlation
across six sessions plus consistent filesystem forensics, rather than a captured
trace naming the writing process. I’m happy to run a controlled reproduction
under fs_usage on the next update if that would help.
Severity
This is silent, unattended data destruction of user source files with no
confirmation and no undo. In my case 43 files were recoverable only because
Cursor’s local history happened to still hold them.
Steps to Reproduce
Auto Update, reopen Cursor
Expected Behavior
I do not expect it to mass truncate my files
Screenshots / Screen Recordings
Operating System
MacOS
Version Information
Version: 3.15.6 (Universal)
VS Code Extension API: 1.128.0
Commit: a1f686545fd0ce8917bbd2449f733551a9bce420
Date: 2026-08-06T01:41:03.876Z
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: Darwin arm64 25.5.0
For AI issues: which model did you use?
Auto Balanced possibly Grok
Does this stop you from using Cursor
No - Cursor works, but with this issue