[macOS 26] SQLite WAL write storm — Cursor writes 2.1 GB in 9 minutes, process killed by macOS disk write throttle

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Description
A Cursor process was throttled and killed by macOS for writing 2.14 GB of data in approximately 9 minutes, far exceeding the macOS limit of 24.86 KB/sec sustained write rate.

Crash Report Details
Incident Date 2026-05-14 07:41:05 +0200
Cursor Version 3.3.30
PID 65415
Write Volume 2,147.50 MB over 556 seconds
Write Rate 3,864 KB/sec average (limit: 24.86 KB/sec)
Duration ~9 minutes 16 seconds
macOS Action Process throttled / killed

Stack Trace
The heaviest stack identified in the diagnostic report:
sqlite3_exec → sqlite3_step → sqlite3VdbeExec → sqlite3VdbeHalt
→ vdbeCommit → pagerWalFrames → walWriteOneFrame → pwrite
The write-heavy thread was executing SQLite WAL (Write-Ahead Log) frame commits via vscode-sqlite3.node, the native SQLite module used for Cursor’s local agent storage, chat history, and workspace indexing databases.

Impact
• Process killed by macOS after exceeding disk write budget
• Potential data corruption risk if SQLite commits are interrupted mid-transaction
• Abnormal write amplification: 155× the allowed sustained write rate

Steps to Reproduce

Install Cursor 3.3.30 on macOS 26.3.1, Apple Silicon (arm64)
Use Cursor normally with Remote-SSH connections to Linux servers
Run agent tasks over an extended session
(No specific action triggered it — the write storm started spontaneously)

Observed: macOS killed the process after detecting sustained writes of 3,864 KB/sec over 556 seconds (limit: 24.86 KB/sec)
I cannot provide a deterministic repro. The write storm was detected via a macOS diagnostic report (Cursor_2026-05-14-075022_Mac-mini-de-KC.diag), which I can attach. The Cursor team mentioned this is tied to unbounded growth of state.vscdb (cursorDiskKV) — this may be the underlying cause rather than a specific user action.

Operating System

MacOS

Version Information

Cursor Version3.3.30 (at time of incident)Electron Framework39.8.1vscode-sqlite3bundled (vscode-sqlite3.node)OSmacOS 26.3.1 (Build 25D2128)Architecturearm64e (Apple Silicon)HardwareMac Mini (Mac14,12) — 10 cores, 32 GB RAMFree Disk Space644.79 GB / 926.35 GB
The incident occurred on Cursor 3.3.30. I have since updated to 3.4.17 — I cannot confirm whether the issue is fixed in the newer version as no write storm has recurred since the update. The diagnostic report (Cursor_2026-05-14-075022_Mac-mini-de-KC.diag) is attached for reference.

Additional Information

Date/Time: 2026-05-14 07:41:05.791 +0200
End time: 2026-05-14 07:50:21.542 +0200
OS Version: macOS 26.3.1 (Build 25D2128)
Architecture: arm64e
Report Version: 67
Incident Identifier: 4F688E36-88CF-4098-B334-92386658B2AF

Data Source: Microstackshots
Shared Cache: 674DB25A-34B2-3C56-8BD4-7D78005B2F2E slid base address 0x19f0bc000, slide 0x1f0bc000

Command: Cursor
Path: /Applications/Cursor.app/Contents/MacOS/Cursor
Identifier: com.todesktop.230313mzl4w4u92
Version: 3.3.30 (3.3.30)
Team ID: VDXQ22DGB9
Is First Party: No
Beta Identifier: EEB24752-9920-53D2-8712-611B3342DABE
Resource Coalition: “com.todesktop.230313mzl4w4u92”(6735)
Architecture: arm64
PID: 65415

Event: disk writes
Action taken: none
Writes: 2147.50 MB of file backed memory dirtied over 556 seconds (3864.14 KB per second average), exceeding limit of 24.86 KB per second over 86400 seconds
Writes limit: 2147.48 MB
Limit duration: 86400s
Writes caused: 2147.50 MB
Writes duration: 556s
Duration: 555.75s
Duration Sampled: 549.05s (event starts 6.70s before samples)
Steps: 202 (10.49 MB/step)

Hardware model: Mac14,12
Active cpus: 10
Memory size: 32 GB
HW page size: 16384
VM page size: 16384
Shared cache residency: 23.66% (1270.36 MB / 5369.62 MB)

Time Since Boot: 120270s
Time Awake Since Boot: 56480s
Time Since Wake: 598s

Total CPU Time: 1.389s
Advisory levels: Battery → 2, User → 2, ThermalPressure → 0, Combined → 2
Free disk space: 644.79 GB/926.35 GB, low space threshold 3072 MB
Vnodes Available: 70.68% (185994/263168)
Models: none

Preferred User Language: fr-FR
Country Code: FR
OS Cryptex File Extents: 1

Heaviest stack for the target process:
202 thread_start + 8 (libsystem_pthread.dylib + 7080) [0x19f592ba8]
202 _pthread_start + 136 (libsystem_pthread.dylib + 27656) [0x19f597c08]
202 uv_cancel + 548 (Electron Framework + 38782356) [0x10f04c594]
200 uv__fs_post + 2432 (Electron Framework + 38809052) [0x10f052ddc]
200 write + 8 (libsystem_kernel.dylib + 18464) [0x19f558820]

Powerstats for: Cursor [65415]
UUID: 4C4C4492-5555-3144-A1A8-5F0D2C2A6582
Path: /Applications/Cursor.app/Contents/MacOS/Cursor
Identifier: com.todesktop.230313mzl4w4u92
Version: 3.3.30 (3.3.30)
Team ID: VDXQ22DGB9
Is First Party: No
Beta Identifier: EEB24752-9920-53D2-8712-611B3342DABE
Resource Coalition: 202 samples “com.todesktop.230313mzl4w4u92”(6735)
Architecture: arm64
Footprint: 108.52 MB → 121.86 MB (+13.34 MB) (max 128.75 MB )
Pageins: 17 pages
Start time: 2026-05-14 07:41:12.487 +0200
End time: 2026-05-14 07:50:21.540 +0200
Num samples: 202 (100%)
Num threads: 2
Primary state: 200 samples Non-Frontmost App, Non-Suppressed, Kernel mode, Effective Thread QoS Default, Requested Thread QoS Default, Override Thread QoS Unspecified, p-core
User Activity: 0 samples Idle, 202 samples Active
Power Source: 0 samples on Battery, 202 samples on AC
202 thread_start + 8 (libsystem_pthread.dylib + 7080) [0x19f592ba8]
202 _pthread_start + 136 (libsystem_pthread.dylib + 27656) [0x19f597c08]
202 uv_cancel + 548 (Electron Framework + 38782356) [0x10f04c594]
200 uv__fs_post + 2432 (Electron Framework + 38809052) [0x10f052ddc]
200 write + 8 (libsystem_kernel.dylib + 18464) [0x19f558820]
1
1 write + 8 (libsystem_kernel.dylib + 18464) [0x19f558820]
1 <Frontmost App, e-core>
1 node::ThreadPoolWork::ScheduleWork()::‘lambda’(uv_work_s*)::invoke(uv_work_s*) + 52 (Electron Framework + 41839596) [0x10f336bec]
1 node_sqlite3::Database::Work_Exec(napi_env, void) + 72 (vscode-sqlite3.node + 74568) [0x144e26348]
1 sqlite3_exec + 1892 (vscode-sqlite3.node + 268432) [0x144e55890]
1 sqlite3_step + 568 (vscode-sqlite3.node + 210532) [0x144e47664]
1 sqlite3VdbeExec + 42956 (vscode-sqlite3.node + 491472) [0x144e8bfd0]
1 sqlite3VdbeHalt + 1644 (vscode-sqlite3.node + 429632) [0x144e7ce40]
1 vdbeCommit + 720 (vscode-sqlite3.node + 432140) [0x144e7d80c]
1 sqlite3BtreeCommitPhaseOne + 164 (vscode-sqlite3.node + 231360) [0x144e4c7c0]
1 sqlite3PagerCommitPhaseOne + 376 (vscode-sqlite3.node + 230240) [0x144e4c360]
1 pagerWalFrames + 824 (vscode-sqlite3.node + 362848) [0x144e6c960]
1 walWriteOneFrame + 128 (vscode-sqlite3.node + 369304) [0x144e6e298]
1 pwrite + 8 (libsystem_kernel.dylib + 17436) [0x19f55841c]
1

Binary Images:
0x102138000 - ??? com.todesktop.230313mzl4w4u92 3.3.30 (3.3.30) <4C4C4492-5555-3144-A1A8-5F0D2C2A6582> /Applications/Cursor.app/Contents/MacOS/Cursor
0x10cb50000 - 0x116f17fff com.github.Electron.framework (39.8.1) <4C4C4414-5555-3144-A1EA-B777C6849AD4> /Applications/Cursor.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework
0x144e14000 - 0x144fbbfff vscode-sqlite3.node (0) <3FADE508-EA91-35D5-89AF-943C3BBB04F0> /Applications/Cursor.app/Contents/Resources/app/node_modules/@vscode/sqlite3/build/Release/vscode-sqlite3.node
0x19f554000 - 0x19f59049f libsystem_kernel.dylib (12377.91.3) <78EC33A6-6330-3836-8900-EB90836936E8> /usr/lib/system/libsystem_kernel.dylib
0x19f591000 - 0x19f59dacb libsystem_pthread.dylib (539.80.3) <0596A7B6-BCE2-3F06-A2E8-3EAAB5371ED8> /usr/lib/system/libsystem_pthread.dylib

Does this stop you from using Cursor

Yes - Cursor is unusable

5

Hey, thanks for the detailed report. The crash stack is very clear. This looks like a known issue where state.vscdb grows without bounds in the cursorDiskKV table. What’s unique in your case is that the DB got so large that macOS detected a sustained write rate and killed the process due to disk write throttling. The stack trace being 100% in SQLite WAL frame commits via vscode-sqlite3.node matches that.

We’re tracking this on our side, but I can’t share an ETA for a fix yet. The root cause is that key prefixes like agentKv, bubbleId, aiCodeTrackingLines, and composer.composerHeaders keep accumulating with no retention or GC.

What you can do right now:

  1. Check the size of ~/Library/Application Support/Cursor/User/globalStorage/state.vscdb. If it’s multiple GB, close Cursor and delete the file. Also delete state.vscdb.backup next to it. After you restart, Cursor will recreate the DB from scratch. Downside: you’ll lose local chat and composer history. Upside: the write storm should stop until the DB grows again.
  2. After updating to 3.4.17, it looks like your DB effectively reset back down, so things are quiet for now. It’s still worth checking the file size from time to time.

Related threads with workarounds:

I’ll link this thread to our internal tracker as extra evidence. The macOS throttle and kill scenario is a very useful signal. If it happens again on 3.4.17, reply here with the new state.vscdb size and the incident time window.