The crashing behavior persists, I used Codex to profile memory and record high-res logs whilst Cursor went through 10-15 minute crash cycles, here are the findings.
Hopefully you can fix it soon, Cursor is unusable for me right now for any non-trivial agentic work, given it crashes within 15 minutes.
The Codex transcript is below, I have also attached the log files which record the failure scenario playing out. Let me know if I can provide any other supporting files!
Codex - GPT 5.3 Extra High analysis
cursor-crash-forum-logs-20260306.zip (137.2 KB)
I collected high-resolution logs/metrics and found a consistent crash signature that points to Cursor retrieval indexing (not DB size) as the immediate cause.
Environment
- Version: 2.6.11
VSCode Version: 1.105.1
Commit: 8c95649f251a168cc4bb34c89531fae7db4bd990
Date: 2026-03-03T18:57:48.001Z
Build Type: Stable
Release Track: Default
Electron: 39.6.0
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Darwin arm64 25.0.0- Date of measured crashes: 2026-03-05
- global state DB was already reduced; at crash time metrics show state_db_mb=22.7 (so this is not a “24 GB DB” event anymore)
Crash signature (repeats)
- Renderer crash: “CodeWindow: renderer process gone (reason: crashed, code: 5)”
- Example crashes:
- /Users/rifont/Library/Application Support/Cursor/logs/20260305T231731/main.log:8 (23:27:36.836)
- /Users/rifont/Library/Application Support/Cursor/logs/20260305T231731/main.log:16 (23:52:41.187)
Pre-crash process surge (from vitals monitor CSV)
- /Users/rifont/Library/Application Support/Cursor/vitals-monitor/metrics.csv
- Crash @ 23:27:36:
- retrieval-always-local host (pid 63435): 393.8 MB @ 23:27:31 → 1451.2 MB @ 23:27:36, CPU ~142% just before jump
- lines: 4007, 4021
- renderer (pid 62909): 878.9 MB @ 23:27:31 → 1748.4 MB @ 23:27:36
- lines: 4005, 4019
- Crash @ 23:52:41:
- retrieval-always-local host (pid 84051): 307.9 MB → 1493.2 MB with CPU 127.5%
- line: 6172 (23:52:38)
- then renderer crashes ~3s later (main.log line 16)
Needle in haystack (likely trigger patterns)
- Huge watcher/event expansion in retrieval grep service
- /Users/rifont/Library/Application Support/Cursor/logs/20260305T162948/window8/exthost/anysphere.cursor-retrieval/Cursor Grep Service.log
- “expanded 1 directories into 1007872 file events” (line 29)
- then “found 9637 pending documents; triggering a reset” (line 34)
- then “FORCE resetting index” (line 36)
- Path-normalization/hash retry storm in retrieval indexing
- /Users/rifont/Library/Application Support/Cursor/logs/20260305T162948/window9/exthost/anysphere.cursor-retrieval/Cursor Indexing & Retrieval.log
- hundreds of repeated:
- fatal: could not open ‘/Users/rifont/git/tau/vscode/settings.json’
- command repeatedly runs
git hash-object ... /vscode/settings.json ...(missing leading dot)- starts around line 33 and continues through line 216
- similar malformed-path misses also seen for oxlintrc.json / github/workflows/ci.yml in other windows (missing leading dot variants)
- HEAD-change correlation right before crash
- /Users/rifont/Library/Application Support/Cursor/logs/20260305T231731/window1/exthost/anysphere.cursor-retrieval/Cursor Grep Service.log
- 23:27:34.986 “git head changed …”
- crash at 23:27:36.836 (~2s later)
Why I think this is the bug
- The largest immediate RSS spike is consistently in
retrieval-always-localextension host.- Renderer memory then spikes and dies with code 5.
- This still happens after state.vscdb was shrunk, so current crash is runtime indexing/watcher pressure, not DB file bloat.
Useful fix directions
- Instrument/limit retrieval host memory + pending event queue.
- Add hard backpressure/guardrails when watcher expansion is huge.
- Fix path normalization (
.vscode/settings.jsonvsvscode/settings.json, same for.oxlintrc.json,.github/...).- Prevent retry storms for repeatedly missing files.
- Consider excluding
.git/*internals from retrieval sync/hash churn.