macOS: state.vscdb grew to 12.4 GB and state.vscdb.backup grew to 12.2 GB on a 256 GB MacBook Air; seeking safe remediation guidance

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor remains functional, but its global state databases have grown to an unexpectedly large size on macOS.

I investigated local storage pressure and found that almost all Cursor storage on this machine is concentrated in the global database pair rather than per-workspace storage. I have intentionally not deleted, vacuumed, renamed, or otherwise modified these databases because related forum posts suggest that deleting the global state.vscdb can break chat loading. I am trying to identify the supported remediation path before taking any action.

Environment:

  • Cursor version: 3.7.12
  • Commit: b887a26c4f70bd8136bfffeda812b24194ec9ce0
  • macOS 26.5.1 (25F80)
  • MacBookAir10,1
  • Apple M1
  • 16 GB RAM
  • 256 GB SSD

Current measurements:

  • ~/Library/Application Support/Cursor/User/globalStorage/state.vscdb: 13,297,373,184 bytes (~12.38 GB)
  • ~/Library/Application Support/Cursor/User/globalStorage/state.vscdb.backup: 13,076,074,496 bytes (~12.18 GB)
  • ~/Library/Application Support/Cursor/User/globalStorage: ~24.66 GB
  • ~/Library/Application Support/Cursor/User/workspaceStorage: ~63 MB
  • Cursor logs: ~90 MB

Database findings:

  • PRAGMA integrity_check returned ok
  • dbstat shows approximately 13.22 GB of the database is concentrated in cursorDiskKV, while ItemTable is only about 6.86 MB
  • The database is overwhelmingly dominated by cursorDiskKV growth

Growth indicators:

  • state.vscdb was modified recently
  • An active WAL file is present for the main DB (~5.1 MB)
  • The backup DB is not currently showing the same active growth pattern

Observed impact:

  • The global database pair alone consumes about 24.56 GB
  • This is materially affecting normal development use on a 256 GB MacBook Air
  • This appears similar to prior forum reports about cursorDiskKV / global state.vscdb growth, but at a materially larger size

Steps to Reproduce

  1. Use Cursor normally on macOS over time with chat / agent usage.
  2. Periodically inspect:
    • ~/Library/Application Support/Cursor/User/globalStorage/state.vscdb
    • ~/Library/Application Support/Cursor/User/globalStorage/state.vscdb.backup
  3. Observe continued growth in the global DB pair while workspaceStorage remains comparatively small.

I do not have exact deterministic reproduction steps yet, but this is the repeatable pattern I can report.

Expected Behavior

I would expect Cursor’s global state database to remain at a reasonable size for editor / chat state storage, or for Cursor to provide a supported cleanup / compaction path if retained chat / agent history grows too large. I would also expect a safe, documented remediation path that does not risk breaking chat loading or losing chat history.

Operating System

MacOS

Version Information

Version: 3.7.12
Commit: b887a26c4f70bd8136bfffeda812b24194ec9ce0
OS: macOS 26.5.1 (25F80)
Architecture: arm64

Additional Information

A prior inspection found cursor.storage.disableSqliteStorageBackup=true stored in the database, yet a state.vscdb.backup file of approximately 12.18 GB still exists.

I am unsure whether this backup is expected to remain in that state, whether it is considered stale, or whether it may be related to the storage growth issue.

Does this stop you from using Cursor

No - Cursor works, but with this issue