# Hundreds of files truncated to 0 bytes after update! **URL:** \ **Category:** Bug Reports\ **Tags:** installation, macos\ **Created:** [August 7, 2026, 6:19pm UTC](https://forum.cursor.com/t/hundreds-of-files-truncated-to-0-bytes-after-update/167720 "2026-08-07T18:19:34Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![josephcrawfordSRH](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/josephcrawfordsrh/32/98822_2.png) [@josephcrawfordSRH](https://forum.cursor.com/u/josephcrawfordSRH)\ **Post date:** [August 7, 2026, 6:19pm UTC](https://forum.cursor.com/t/hundreds-of-files-truncated-to-0-bytes-after-update/167720/1 "2026-08-07T18:19:34Z")
### 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.mode` not 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 with `open(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//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-table` migration** — 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//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 ![Screenshot 2026-08-07 at 2.18.46 PM.png](https://us1.discourse-cdn.com/cursor1/original/3X/4/3/437741fc60967d88f24559c945f525f78c620309.png) ### 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 ---
**Author:** ![kevinn](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/kevinn/32/101206_2.png) [@kevinn](https://forum.cursor.com/u/kevinn)\ **Post date:** [August 7, 2026, 11:43pm UTC](https://forum.cursor.com/t/hundreds-of-files-truncated-to-0-bytes-after-update/167720/7 "2026-08-07T23:43:08Z")
Hi @josephcrawfordSRH Thank you for the post. What you’re seeing is not expected behavior, and we’re tracking it. Until this is resolved, these steps should reduce the risk of it recurring: - Before quitting or updating Cursor, open Review Changes and resolve every pending Agent change with Keep All or Undo All, as appropriate. Wait until the list is clear before quitting. - If you have already restored an affected file and Cursor still shows it as pending, first verify that the recovered content is visible in the editor, then choose Keep, not Undo. This clears the pending state without reverting the recovered file. I’ll post here when I have an update to share. ---
**Author:** ![kevinn](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/kevinn/32/101206_2.png) [@kevinn](https://forum.cursor.com/u/kevinn)\ **Post date:** [August 11, 2026, 11:26pm UTC](https://forum.cursor.com/t/hundreds-of-files-truncated-to-0-bytes-after-update/167720/10 "2026-08-11T23:26:23Z")
Hi @josephcrawfordSRH, just wanted to offer a quick follow-up. A related startup issue has been addressed, but that change does not cover the exact zero-byte situation you reported, so this remains unresolved. We’re continuing to track it separately, and I’ll keep this thread updated as we make additional progress. ---
**Author:** ![josephcrawfordSRH](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/josephcrawfordsrh/32/98822_2.png) [@josephcrawfordSRH](https://forum.cursor.com/u/josephcrawfordSRH)\ **Post date:** [August 12, 2026, 1:01pm UTC](https://forum.cursor.com/t/hundreds-of-files-truncated-to-0-bytes-after-update/167720/11 "2026-08-12T13:01:41Z")
For the time being i have just disabled auto updates and have not seen the issue again. I am refraining from any updates until I hear this is resolved. ---
**Author:** ![hanna](https://avatars.discourse-cdn.com/v4/letter/h/b3f665/32.png) [@hanna](https://forum.cursor.com/u/hanna)\ **Post date:** [August 12, 2026, 5:51pm UTC](https://forum.cursor.com/t/hundreds-of-files-truncated-to-0-bytes-after-update/167720/12 "2026-08-12T17:51:43Z")
I can’t really help a lot, but I will say I closed cursor a few days ago and two of my rust files got wiped out to empty, noticed when I reopened today but the log said it happened earlier based on date stamp of the file. Luckily I was able to restore from git. I’m not sure if its the same bug, but it’s odd and a horrible data loss bug if that’s what it is. I’m on Windows though, mixed with WSL for what its worth. Edit, I just updated but before I was on 3.15.6 ---
**Author:** ![skaro](https://avatars.discourse-cdn.com/v4/letter/s/49beb7/32.png) [@skaro](https://forum.cursor.com/u/skaro)\ **Post date:** [August 30, 2026, 6:19pm UTC](https://forum.cursor.com/t/hundreds-of-files-truncated-to-0-bytes-after-update/167720/13 "2026-08-30T18:19:19Z")
I had this crash delete a weeks work 2 days ago and costed me at least 100-200 USD in credits to get back to speed, I would have never been able to come back after that without AI @kevinn. And today it happened again much less this time since I learned from the mistake but I was still in the process of cleaning up pretty much. I created tooling to restore files that this happened to. Is it of interest to someone? I think its related to having autosave turned on and then experiencing the crash. Something collides with it saving files with 0 bytes before cursor restores them or something. The idea behidn the script is that all affected files get their agentic changes replayed from HEAD up till the crash. Since all agents store StrReplace, Write, Edit etc the changes can be replayed in the exact order they happened if script is written correctly. I understand this is fixed in newer versions right? As I just updated. But the reality is it had a real economical impact and also hours of work. ---
**Author:** ![kevinn](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/kevinn/32/101206_2.png) [@kevinn](https://forum.cursor.com/u/kevinn)\ **Post date:** [August 31, 2026, 5:37pm UTC](https://forum.cursor.com/t/hundreds-of-files-truncated-to-0-bytes-after-update/167720/14 "2026-08-31T17:37:47Z")
Hi @skaro, I’m sorry this happened, and that it happened a second time. This is still an issue we are tracking, and it is not resolved. Updating to a newer version does not fix this. We are continuing to work on it. I’ll post here when I have an update. Until then: - Before you quit or update Cursor, open Review Changes and resolve every pending Agent change with Keep All or Undo All. Wait until that list is empty before you quit or update. - If you already restored an affected file and Cursor still shows it as pending, first confirm the recovered content is visible in the editor, then choose Keep, not Undo. @josephcrawfordSRH this is the same situation as before. Holding updates remains a reasonable precaution until we have a confirmed fix to share. ---
**Author:** ![josephcrawfordSRH](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/josephcrawfordsrh/32/98822_2.png) [@josephcrawfordSRH](https://forum.cursor.com/u/josephcrawfordSRH)\ **Post date:** [September 2, 2026, 12:42pm UTC](https://forum.cursor.com/t/hundreds-of-files-truncated-to-0-bytes-after-update/167720/15 "2026-09-02T12:42:20Z")
Thanks for the update, I have not encountered any issues since I have turned off auto-update but look forward to being able to upgrade when this issue is resolved. ---
**Author:** ![josephcrawfordSRH](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/josephcrawfordsrh/32/98822_2.png) [@josephcrawfordSRH](https://forum.cursor.com/u/josephcrawfordSRH)\ **Post date:** [October 13, 2026, 12:51pm UTC](https://forum.cursor.com/t/hundreds-of-files-truncated-to-0-bytes-after-update/167720/19 "2026-10-13T12:51:08Z")
It has been 2 months, I just wanted to reach out to see if this has been addressed and if I can re-enable auto updates or not. ---
**Author:** ![josephcrawfordSRH](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/josephcrawfordsrh/32/98822_2.png) [@josephcrawfordSRH](https://forum.cursor.com/u/josephcrawfordSRH)\ **Post date:** [October 27, 2026, 12:19pm UTC](https://forum.cursor.com/t/hundreds-of-files-truncated-to-0-bytes-after-update/167720/20 "2026-10-27T12:19:51Z")
I see there is a forced update before 12/31/2026, I have manually upgraded but will continue to keep auto updates turned off until this has been confirmed to have been resolved.