Cursor Cracks Down on App Stability

Cursor has dramatically improved app stability, slashing OOM errors by 80% through advanced diagnostics and focused engineering efforts.

3 min read
Abstract visualization of code and data flow representing app stability
Abstract representation of data flow and stability in the Cursor application.· Cursor Blog

For users who spend their entire workday in the Cursor application, even infrequent crashes can be a major disruption. As the platform adds features like subagents and instant grep, maintaining stability becomes increasingly complex. The primary culprit for these crashes has been out-of-memory (OOM) errors. Over recent months, Cursor has rolled out new systems for crash observability, memory pressure monitoring, and high-confidence fixes, leading to an 80% drop in OOM-per-session rates since its late-February peak. This post details the engineering efforts behind these improvements, as reported by Cursor Blog.

Detecting and Measuring Instability

Built on Visual Studio Code and Electron, Cursor's multi-process architecture means crashes can originate in renderer processes (editor, agents) or utility processes (extensions, storage). Renderer crashes are most severe, often tied to V8 memory limits. Extension crashes can disrupt functionality but typically recover.

Every fatal crash is automatically reported via telemetry, including process details, crash type, device metadata, and stack traces. These events feed into dashboards that track metrics like OOM-per-session and OOM-per-request, allowing rapid detection of regressions after new versions ship.

Dual Debugging Strategies

Cursor employs a two-pronged approach to tackle crashes and memory issues.

Related startups

Top-Down Investigation

This method focuses on memory-intensive features. By linking crash metrics to feature flags, the team can A/B test their impact. Proxy metrics, such as oversized message payloads between processes, also serve as early indicators of memory problems.

To reconstruct crash events, metadata logs, termed 'breadcrumbs', are attached to features like parallel agent usage and terminals, providing a history of preceding activity.

Bottom-Up Investigation

Here, individual crash events are traced to their source. A crash watcher service uses the Chrome DevTools Protocol to capture OOM errors and real-time crash stacks. Patches to Electron enable stack capture without heavy CDP machinery.

Automated analysis of these stacks daily identifies high-confidence fixes, with PRs generated for optimizations. To understand memory accumulation, heap snapshots are prompted from users when memory usage spikes. These opt-in snapshots are vital for pinpointing memory pressure sources.

Continuous heap allocation profiling across the user base provides a bird's-eye view of memory usage patterns, enabling version-over-version comparisons to identify performance improvements or regressions.

Targeted Mitigations

Crashes generally fall into two categories: acute OOMs, characterized by sudden memory spikes, and slow-and-steady OOMs, where memory gradually increases. Acute OOMs often stem from loading too much data at once, especially with large user workspaces. Mitigations include kill switches and chunked processing for large data blobs.

Slow-and-steady OOMs are typically due to unmanaged state or resource leaks. These are addressed by tracking down retainers and cleaning up object lifecycles. Cursor has contributed several leak fixes upstream to VSCode.

Extension crashes are partially mitigated by running extensions in isolated processes, preventing one extension's issues from impacting others, akin to Chrome's tab isolation. This approach enhances Electron app performance optimization but uses slightly more memory.

Preventing Regressions, Staying Fast

Preventing new crashes requires embedding stability awareness into the development process. Cursor is investing in developer tooling and process improvements, including automated checks for common crash types and skills for stress-testing the application.

Efforts to eliminate common pitfalls, such as replacing manual resource management with garbage collection, are ongoing. Traditional automated performance tests run after every code change, and automated rollbacks are triggered by metric regressions, aligning with the principles discussed in Preventing regressions in software development and AI is Massively Deflationary Sam Altman on Shifting Value, Agent Bottlenecks, and the Future of the Stack.

Building high-quality software is more critical than ever, especially with the rise of agentic development.

© 2026 StartupHub.ai. All rights reserved. Do not enter, scrape, copy, reproduce, or republish this article in whole or in part. Use as input to AI training, fine-tuning, retrieval-augmented generation, or any machine-learning system is prohibited without written license. Substantially-similar derivative works will be pursued to the fullest extent of applicable copyright, database, and computer-misuse laws. See our terms.