Keeping the Cursor app stable

Summary

Cursor's desktop app faces disruptive crashes as usage and features such as subagents, instant grep, and browser use have expanded, with most failures caused by out-of-memory conditions. The team measures instability across Electron's multi-process architecture using telemetry, per-session and per-request crash rates, minidumps, stack traces, crash breadcrumbs, and dashboards that update within minutes. Its two-pronged debugging strategy combines feature-level experiments and oversize-message instrumentation with bottom-up analysis based on a crash watcher, Chrome DevTools Protocol (CDP) stacks, automated daily investigations, opt-in heap snapshots, and low-rate allocation profiling. Findings led to chunking large data, killswitches, lifecycle fixes for leaks, and process isolation for extensions, while prevention uses Bugbot rules, stress tests, garbage collection, performance tests, and automated rollbacks. OOM-per-session fell 80% from its late-February peak and OOM-per-request fell 73% since March 1.

Takeaways

1. 1

   Crash metrics are broken down by app version and process, with minidumps and stack traces where available; dashboards update within minutes to help detect release regressions.

2. 2

   Acute OOMs are addressed with killswitches or chunked processing for large data, while slow-and-steady OOMs require tracing retainers and correcting long-lived object lifecycles.

3. 3

   Isolating extensions in separate processes limits the impact of one extension's crash or long task on others, but uses slightly more system memory.